Freigeben über

Shared Assembly Info in Visual Studio Projects

  • Artikel

Yesterday I introduced the concept of linked files in Visual Studio solutions with a follow-up on my recommendation for configuring a custom dictionary to eliminate CA1704 code analysis warnings.

Another practical application of linked files is what I refer to as "shared assembly info" -- referring to the assembly attributes that should be the same across all projects in the solution, such as AssemblyCompanyAttribute.

To implement this, create a file in the solution folder named SharedAssemblyInfo.cs and then add a link in each project to SharedAssemblyInfo.cs. You can also move the linked SharedAssemblyInfo.cs into the Properties folder so that it sits side-by-side with the AssemblyInfo.cs that is specific to each project in the solution, as shown below.

Figure 1: Linked SharedAssemblyInfo.cs files in a Visual Studio solution

See full-sized image.

I recommend placing the following assembly attributes in SharedAssemblyInfo.cs (and, of course, removing them as necessary from the project-specific AssemblyInfo.cs files):

  • AssemblyCompany
  • AssemblyProduct
  • AssemblyCopyright
  • AssemblyTrademark
  • AssemblyConfiguration
  • AssemblyDescription
  • CLSCompliant
  • ComVisible
  • AssemblyVersion
  • AssemblyInformationalVersion

The AssemblyInfo.cs files typically have the following assembly attributes:

  • AssemblyTitle
  • AssemblyCulture
  • Guid

Here is a sample SharedAssemblyInfo.cs file:

 using System;
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

// General Information about an assembly is controlled through the following 
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyCompany("Fabrikam Technologies")]
[assembly: AssemblyProduct("Demo")]
[assembly: AssemblyCopyright("Copyright ? Fabrikam Technologies 2009")]
[assembly: AssemblyTrademark("")]

// Make it easy to distinguish Debug and Release (i.e. Retail) builds;
// for example, through the file properties window.
#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
[assembly: AssemblyDescription("Flavor=Debug")] // a.k.a. "Comments"
#else
[assembly: AssemblyConfiguration("Retail")]
[assembly: AssemblyDescription("Flavor=Retail")] // a.k.a. "Comments"
#endif

[assembly: CLSCompliant(true)]

// Setting ComVisible to false makes the types in this assembly not visible 
// to COM components.  If you need to access a type in this assembly from 
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]

// Note that the assembly version does not get incremented for every build
// to avoid problems with assembly binding (or requiring a policy or
// <bindingRedirect> in the config file).
//
// The AssemblyFileVersionAttribute is incremented with every build in order
// to distinguish one build from another. AssemblyFileVersion is specified
// in AssemblyVersionInfo.cs so that it can be easily incremented by the
// automated build process.
[assembly: AssemblyVersion("1.0.0.0")]

// By default, the "Product version" shown in the file properties window is
// the same as the value specified for AssemblyFileVersionAttribute.
// Set AssemblyInformationalVersionAttribute to be the same as
// AssemblyVersionAttribute so that the "Product version" in the file
// properties window matches the version displayed in the GAC shell extension.
[assembly: AssemblyInformationalVersion("1.0.0.0")] // a.k.a. "Product version"

Note how the AssemblyConfigurationAttribute and AssemblyDescriptionAttribute are set based on conditional compilation constants (in order to easily distinguish Debug and Release builds).

Here is a sample AssemblyInfo.cs file:

 using System.Reflection;
using System.Runtime.InteropServices;

// Note: Shared assembly information is specified in SharedAssemblyInfo.cs

// General Information about an assembly is controlled through the following 
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("Fabrikam.Demo.CoreServices")]
[assembly: AssemblyCulture("")]

// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("88d50bdd-34bc-414a-98d6-6fefe701d41b")]

In my next post, I'll discuss assembly versioning in more detail.

Comments

  • Anonymous
    April 03, 2009
    Whenever a new .NET assembly project is created in Visual Studio, a file named AssemblyInfo is created

  • Anonymous
    March 10, 2010
    I have a question, if a project has one assemblyinfo.cs and one linked assemblyinfo.cs, how to build the project, and what's the order. Dose it like this: first build self-assemblyinfo.cs and then build linked-assemblyinfo.cs? Expecting for your reply, thank you~

  • Anonymous
    March 10, 2010
    The AssemblyInfo.cs files shown in the above screenshot are not linked files. In other words, each project has its own copy of AssemblyInfo.cs. The SharedAssemblyInfo.cs files shown in the above screenshot are linked files. In other words, there is only one copy of the SharedAssemblyInfo.cs file. When each project is compiled, the linked files are compiled just like every other file in the project. You don't have to do anything special to build the project.

  • Anonymous
    March 14, 2010
    Thank you~~, do you mind I reference this essay in my blog?

  • Anonymous
    March 14, 2010
    No...by all means, reference away.

  • Anonymous
    November 26, 2010
    Where is the AssemblyVersionInfo.cs and its source code?

  • Anonymous
    November 29, 2010
    The comment has been removed

  • Anonymous
    October 09, 2011
    Has someone gotten this to work with VBNet?  The IDE works slightly different and cannot put the shared file in the right folder.