Multiple projects under one solution share a AssemblyInfo

Http://stackoverflow.com/questions/18963750/add-file-as-a-link-on-visual-studio-debug-vs-publish

Http://stackoverflow.com/questions/2593612/visual-studio-add-item-add-as-link-rather-than-just-add

Http://blogs.msdn.com/b/jjameson/archive/2009/04/02/linked-files-in-visual-studio-solutions.aspx

Http://blogs.msdn.com/b/jjameson/archive/2009/04/03/shared-assembly-info-in-visual-studio-projects.aspx

Note that there is a file named GlobalAssemblyInfo.cs, this file is added by adding a link to the project

Add the method: Right-click on the item, add, existing item, last selected file, after the Add button has a small arrow, click, Come Out menu, choose Add as Link

A couple of years ago, I wrote a post introducing my system for structuring Visual Studio solutions. However, I apparently forgot to post a follow-up providing additional details, such as configuring Assembly versioning and What do I like to call "shared assembly information."

Before I can cover these details, I need to first ensure that is familiar with the concept of linking files in Visual Studio Solutions, why the is a powerful feature, and if to use it.

If you are ever used Visual SourceSafe (VSS), you likely used it feature for sharing files across multiple projects. For example, you could check-in a file at the root of your solution, and then drag-and-drop it to other projects (i.e. " Subfolders ") in your solution. Thus, whenever a change is made to the file (regardless of which particular VSS project The change is made in), the next Time you "got latest" the change would is reflected in all locations. This is a common, for example, has all of your. NET assemblies in the same Visual Studio solution specify the S AME assembly version.

Note that the Team Foundation Server (TFS) does not provide an equivalent "Share file" feature. Fortunately, however, you no longer need such a feature.

Back in the days of the original Visual Studio. NET and the following version, Visual Studio. NET 2003, whenever you added An existing file to a project, it copied the "file into the" the corresponding location in the project.

However, in Visual Studio 2005, the Add Existing Item feature provided the ability-choose to either add 1> the item or ADD as Link (via the little down arrow on the button in the dialog box).

In other words, once-upgraded to Visual Studio 2005, it is no longer necessary to rely on any "sharing" features of Y Our source control system on order to has multiple projects always reference the latest version of a file.

Note that if you Add a item in Visual Studio 2005 or Visual Studio, the behavior is the same as earlier V Ersions (meaning the file is copied to the corresponding location within the project). When you choose to Add as Link, however, you simply reference the file In-place. [Don ' t worry, relative paths ensure that everyone on your team are free to choose whatever root folder they wish for their Individual workspaces.]

To illustrate the concept, I quickly built out a "demo" solution, as shown below.

In Windows Explorer, the corresponding folder structure looks like this:

The corresponding folder structure on disk resembles the following:

• Fabrikam
  • Demo
    • dev  (branch)
      • lab1  (BR Anch)
        • AssemblyVersionInfo.cs
        • customdictionary.xml
        • Fabri Kam. Demo.sln
        • Fabrikam.Demo.snk
        • SharedAssemblyInfo.cs
        • adminconsole
          • adminconsole.csproj
          • Program.cs
          • Properties
            • AssemblyInfo.cs
        • coreservices
          • coreservices.csproj
          • Logging
            • Logger.cs
          • Properties
            • AssemblyInfo.cs

Note that AssemblyVersionInfo.cs, customdictionary.xml, Fabrikam.Demo.snk, and SharedAssemblyInfo.csreside in the same folder as the Visual Studio solution file and is subsequently "linked into" The Visual C # projects. Thus whenever a change are made to one of the these files, and the next build of each project would reflect the change.

With the This foundation on place, I'll explain some other recommended best practices over a series of follow-up posts, includ Ing:

• Using custom dictionaries in Visual Studio
• Shared Assembly info in Visual Studio projects
• Best practices for. NET Assembly Versioning

Stay tuned!

It is important to note that:

GlobalAssemblyInfo.cs files need to be stored separately with a single folder SolutionItems, this folder and other items under the solution

Multiple projects under one solution share a AssemblyInfo