C#中的AssemblyInfo 程序集信息

[VS软件版本号定义、规则和相关的Visual Studio插件](http://blog.csdn.net/cnhk1225/article/details/37500593)

 

[assembly: AssemblyTitle("文件说明")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("公司名称")]
[assembly: AssemblyProduct("产品名称")]
[assembly: AssemblyCopyright("版权")]
[assembly: AssemblyTrademark("合法商标")]
[assembly: AssemblyCulture("")]

 

[assembly: AssemblyVersion("1.0.0")]  文件版本

 

 

 

 

扩展What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

AssemblyVersion

Where other assemblies that reference your assembly will look. If this number changes, other assemblies have to update their references to your assembly! The AssemblyVersion is required.

其他程序集引用你编译的程序集的时候，依赖于AssemblyVersion ;如果AssemblyVersion的版本号变化了，那么其他程序集需要重新引用你的程序集。

I use the format: major.minor. This would result in:

[assembly: AssemblyVersion("1.0")]

AssemblyFileVersion

Used for deployment. You can increase this number for every deployment. It is used by setup programs. Use it to mark assemblies that have the same AssemblyVersion, but are generated from different builds.

部署的时候使用AssemblyFileVersion，在你每一次部署的时候修改这个版本号。被安装程序所使用。用它来使得一系列的程序集有相同的版本号，但是这些程序集是通过不同的方式编译的

In Windows, it can be viewed in the file properties. 在windows操作系统中，可以从文件属性中看到它

If possible, let it be generated by MSBuild. The AssemblyFileVersion is optional. If not given, the AssemblyVersion is used.

如果条件允许的话，让它由MSBuild来生成。AssemblyFileVersion 是可选的，如果没有使用这个属性，那么就会用AssemblyVersion

I use the format: major.minor.revision.build, where I use revision for development stage (Alpha, Beta, RC and RTM), service packs and hot fixes. This would result in:

[assembly: AssemblyFileVersion("1.0.3100.1242")]

AssemblyInformationalVersion

The Product version of the assembly. This is the version you would use when talking to customers or for display on your website. This version can be a string, like '1.0 Release Candidate'.

Unfortunately, when you use a string, it will generate a false warning -- already reported to Microsoft (fixed in VS2010). Also the Code Analysis will complain about it (CA2243) -- reported to Microsoft (not fixed in VS2013).

The AssemblyInformationalVersion is optional. If not given, the AssemblyVersion is used.

I use the format: major.minor [revision as string]. This would result in:

[assembly: AssemblyInformationalVersion("1.0 RC1")]

 

 

Version Properly using AssemblyVersion and AssemblyFileVersion

We talk quite easily about new technologies and things we just learned about, because that's the way geeks work. But for newcomers, this is not always easy.

This is a large recurring debate, but I find that it is good to step back from time to time and talk about good practices for these newcomers.

The AssemblyVersion and AssemblyFileVersion Attributes
When we want to give a version to a .NET assembly, we can choose one of two common ways :

• AssemblyVersion, which is stored in the assembly manifest,
• AssemblyFileVersion, which is stored the PE image resources.

Most of the time, and by default in Visual Studio 2008 templates, we can find the AssemblyInfo.cs file in the Properties section of a project.

This file will generally only contain an AssemblyVersion attribute, which will force the value of the AssemblyFileVersion value to the AssemblyVersion's value.

The AssemblyFileVersion attribute is now added by default in the Visual Studio 2010 C# project templates, and this is a good thing.
It is possible to see the value of the AssemblyFileVersion attribute in file properties window the Windows file explorer, or by adding the "File Version" column, still in the Windows Explorer.
We can also find a automatic numbering provided by the C# compiler, by the use of :
[assembly: AssemblyVersion("1.0.0.*")]

Each new compilation will create a new version.
This feature is enough at first, but when you start having somehow complex projects, you may need to introduce continuous integration that will provide nightly builds. You will want to give a version to the assemblies in such a way it is easy to find which revision has been used in the source control system to compile those assemblies.
You can then modify the Team Build scripts to use tasks such as the AssemblyInfo task of MSBuild Tasks, and generate a new AssemblyInfo.cs file that will contain the proper version.

 

Publishing a new version of an Assembly

To come back to the subject of versionning an assembly properly, we generally want to know quickly, when a project build has been published, which version has been installed on the client's systems. Most of the time, we want to know which version is used because there is an issue, and that we will need to provide an updated assembly that will contain a fix. Particularly when the software cannot be reinstalled completely on those systems.

A somehow real world example

Lets consider that we have a solution with two assemblies signed with a strong name Assembly1 and Assembly2, with Assembly1 that uses types available in Assembly2, and that finally are versioned with an AssemblyVersion set to 1.0.0.458. These assemblies are part of an official build published on the client's systems.

If we want to provide a fix in Assembly2, we will create a branch in the source control from the revision 1.0.0.458, and make the fix in that branch which will give revision 460, so the version 1.0.0.460.

If we let the Build System compile that revision, we will get assemblies that will be marked as 1.0.0.460. If we only take Assembly2, and we place it on the client's systems, the CLR will refuse to load this new version if the assembly, because Assembly1 requires to have Assembly to of the version 1.0.0.458. We can use the bindingRedirect parameter in the configuration file to get around that, but this is not always convenient, particularly when we update a lot of assemblies.

We can also compile this new version with the AssemblyVersion of 1.0.0.460 set to 1.0.0.458 for Assembly2, but this willl have the disadvantage of lying about the actual version of the file, and that will make diagnostics more complex in case of an other issue that could happen later.

Adding AssemblyFileVersion

To avoid having those issues with the resolution of assembly dependencies, it is possible to keep the AssemblyVersion constant, but use the AssemblyFileVersion to provide the actual version of the assembly.

The version specified in the AssemblyFileVersion is not used by the .NET Runtime, but is displayed in the file properties in the Windows Explorer.

We will then have the AssemlyVersion set to the original published version of the application, and set the AssemblyFileVersion to the same version, and later change only the AssemblyFileVersion when we published fixes of these assemblies.

Microsoft uses this technique to version the .NET runtime and BCL assemblies, and we take a look at System.dll for .NET 2.0, we can see that the AssemblyVersion is set to 2.0.0.0, and that the AssemblyFileVersion is set, for instance, to 2.0.50727.4927.

 

 

 

 

 

关于AssemblyCulture  http://stackoverflow.com/questions/9206007/net-assembly-culture

You should use

[assembly: AssemblyCulture("")]

as the compiler suggests.

To define default culture, you should use

[assembly: NeutralResourcesLanguage("en-US")]

 

http://stackoverflow.com/questions/7402206/in-a-c-sharp-class-project-what-is-assemblyculture-used-for

From the documentation:

The attribute is used by compilers to distinguish between a main assembly and a satellite assembly. A main assembly contains code and the neutral culture's resources. A satellite assembly contains only resources for a particular culture, as in [assembly:AssemblyCultureAttribute("de")]. Putting this attribute on an assembly and using something other than the empty string ("") for the culture name will make this assembly look like a satellite assembly, rather than a main assembly that contains executable code. Labeling a traditional code library with this attribute will break it, because no other code will be able to find the library's entry points at runtime.

To summarize: This attribute is used internally by the framework to mark the satellite assemblies automatically created when you add localized resources to your project. You will probably never need to manually set this attribute to anything other than "".