一个解决方案下的多个项目共享一个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

需要注意的是，有一个文件名为GlobalAssemblyInfo.cs的文件，这个文件是通过添加链接的方式加入项目的

添加方法为：在项目上右键，添加，现有项，最后选中文件，之后的添加按钮有一个小箭头，点一下，出来菜单，选择添加为链接

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 I like to call “shared assembly information.”

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

If you ever used Visual SourceSafe (VSS), you likely used its 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 into other projects (i.e. “subfolders”) in your solution. Thus, whenever a change was made to the file (regardless of which particular VSS project the change was made in), the next time you “got latest” the change would be reflected in all locations. This was a common way of, for example, having all of your .NET assemblies in the same Visual Studio solution specify the same assembly version.

Note that 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 corresponding location in the project.

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

In other words, once you upgraded to Visual Studio 2005, it was no longer necessary to rely on any “sharing” features of your source control system in order to have multiple projects always reference the latest version of a file.

Note that when you Add an item in Visual Studio 2005 or Visual Studio 2008, the behavior is the same as earlier versions (meaning the file is copied into 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 is free to choose whatever root folder they wish for their individual workspaces.]

To illustrate this 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 (branch)
        • AssemblyVersionInfo.cs
        • CustomDictionary.xml
        • Fabrikam.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 are subsequently “linked into” the two Visual C# projects. Thus whenever a change is made to one of these files, the next build of each project will reflect that change.

With this foundation in place, I’ll explain some other recommended best practices over a series of follow-up posts, including:

• Using custom dictionaries in Visual Studio
• Shared assembly info in Visual Studio projects
• Best practices for .NET assembly versioning

Stay tuned!

需要注意的是：

GlobalAssemblyInfo.cs文件需要单独用一个文件夹SolutionItems来存放，此文件夹和解决方案下的其他项目平级

2015年07月03日，发现了新的资源

What are the best practices for using Assembly Attributes?

We’re using a global file called GlobalAssemblyInfo.cs and a local one called AssemblyInfo.cs. The global file contains the following attributes:

[assembly: AssemblyProduct("Your Product Name")][assembly: AssemblyCompany("Your Company")]
[assembly: AssemblyCopyright("Copyright © 2008 ...")]
[assembly: AssemblyTrademark("Your Trademark - if applicable")]#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif[assembly: AssemblyVersion("This is set by build process")]
[assembly: AssemblyFileVersion("This is set by build process")]

The local AssemblyInfo.cs contains the following attributes:

[assembly: AssemblyTitle("Your assembly title")]
[assembly: AssemblyDescription("Your assembly description")]
[assembly: AssemblyCulture("The culture - if not neutral")][assembly: ComVisible(true/false)]// unique id per assembly
[assembly: Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")]

You can add the GlobalAssemblyInfo.cs using the following procedure:

• Select Add/Existing Item… in the context menu of the project
• Select GlobalAssemblyInfo.cs
• Expand the Add-Buton by clicking on that little down-arrow on the right hand
• Select “Add As Link” in the buttons drop down list