使用程序集属性的最佳实践是什么？

Question

I have a solution with multiple project. I am trying to optimize AssemblyInfo.cs files by linking one solution wide assembly info file. What are the best practices for doing this? Which attributes should be in solution wide file and which are project/assembly specific?

---

Edit: If you are interested there is a follow up question What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

Answer 1

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-Button by clicking on that little down-arrow on the right hand
• Select "Add As Link" in the buttons drop down list

Answer 2

In my case, we're building a product for which we have a Visual Studio solution, with various components in their own projects. The common attributes go. In the solution, there are about 35 projects, and a common assembly info (CommonAssemblyInfo.cs), which has the following attributes:

[assembly: AssemblyCompany("Company")]
[assembly: AssemblyProduct("Product Name")]
[assembly: AssemblyCopyright("Copyright © 2007 Company")]
[assembly: AssemblyTrademark("Company")]

//This shows up as Product Version in Windows Explorer
//We make this the same for all files in a particular product version. And increment it globally for all projects.
//We then use this as the Product Version in installers as well (for example built using Wix).
[assembly: AssemblyInformationalVersion("0.9.2.0")]

The other attributes such as AssemblyTitle, AssemblyVersion etc, we supply on a per-assembly basis. When building an assembly both AssemblyInfo.cs and CommonAssemblyInfo.cs are built into each assembly. This gives us the best of both worlds where you may want to have some common attributes for all projects and specific values for some others.

Hope that helps.

Answer 3

The solution presented by @JRoppert is almost the same as what I do. The only difference is that I put the following lines in the local AssemblyInfo.cs file as they can vary with each assembly:

#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")]
[assembly: CLSCompliant(true)]

I also (generally) use one common assembly info per solution, with the assumption that one solution is a single product line/releasable product. The common assembly info file also has:

[assembly: AssemblyInformationalVersion("0.9.2.0")]

Which will set the "ProductVersion" value displayed by Windows Explorer.

Answer 4

MSBuild Community Tasks contains a custom task called AssemblyInfo which you can use to generate your assemblyinfo.cs. It requires a little hand-editing of your csproj files to use, but is worthwhile.

Answer 5

In my opinion using a GlobalAssemblyInfo.cs is more trouble than it's worth, because you need to modify every project file and remember to modify every new project, whereas you get an AssemblyInfo.cs by default.

For changes to global values (ie Company, Product etc) the changes are usually so infrequent and simple to manage I don't think DRY should be a consideration. Just run the following MSBuild script (dependent on the MSBuild Extension Pack ) when you want to manually change the values in all projects as a one-off:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="UpdateAssemblyInfo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <ItemGroup>
        <AllAssemblyInfoFiles Include="..\**\AssemblyInfo.cs" />
    </ItemGroup>

    <Import Project="MSBuild.ExtensionPack.tasks" />

  <Target Name="UpdateAssemblyInfo">
    <Message Text="%(AllAssemblyInfoFiles.FullPath)" />
    <MSBuild.ExtensionPack.Framework.AssemblyInfo 
        AssemblyInfoFiles="@(AllAssemblyInfoFiles)"
        AssemblyCompany="Company"
        AssemblyProduct="Product"
        AssemblyCopyright="Copyright"
        ... etc ...
        />
  </Target>

</Project>

Answer 6

To share a file between multiple projects you can add an existing file as a link.

To do this, add an existing file, and click on "Add as Link" in the file selector.
_{(source: free.fr )}

As for what to put in the shared file, I would suggest putting things that would be shared across assemblies. Things like copyright, company, perhaps version.

Answer 7

One thing I have found useful is to generate the AssemblyVersion elements (etc) by applying token-substitution in the pre-build phase.

I use TortoiseSvn, and it is easy to use its SubWCRev.exe to turn a template AssemblyInfo.wcrev into AssemblyInfo.cs . The relevant line in the template might look something like this:

[assembly: AssemblyVersion("2.3.$WCREV$.$WCMODS?1:0$$WCUNVER?1:0$")]

The third element is then the revision number. I use the fourth element to check I haven't forgotten to commit any new or changed files (the fourth element is 00 if it is all OK).

By the way, add AssemblyInfo.wcrev to your version control and ignore AssemblyInfo.cs if you use this.

Answer 8

Using a single AseemblyInfo.cs file for multiple projects is not recommended. The AssemblyInfo file includes information that might be relevant only for that specific assembly. The two most obvious pieces of information are the AssemblyTitle and AssemblyVersion .

A better solution might be to use targets file, which are handled by the MSBuild, in order to "inject" assembly attributes to more than one project.