Let us look at some other very important assembly attributes, versioning related, in this article. There are three such attributes, AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion.
They look pretty similar and are easy to be mistaken for each other, but they are actually designed for different purposes.
The AssemblyVersion comes first.
It indicates the real (internal) version of the assembly. The ‘real (internal)’ here means if the version number changes, those assemblies that reference to this assembly through strong names have to update the reference to reflect the change (most commonly needing to rebuild the whole Visual Studio project); otherwise the assembly lookup or load will just fail.
It is composed of four parts, the Major version, Minor version, Build number, and Revision number, being separated with a period from left to right, and each part has to be a non-negative integer as the .NET CLR cares very much about it. So we have to strictly follow its rules.
“All components of the version must be integers greater than or equal to 0. Metadata restricts the major, minor, build, and revision components for an assembly to a maximum value of UInt16.MaxValue - 1. If a component exceeds this value, a compilation error occurs.”
Here is an example:
[assembly: AssemblyVersion("8.2.0.0")]
Do not worry too much about it. Whenever anything is not good there, the compiler will warn us either throng red exclamations in the Error List or the little tiny wave symbols under the particular attribute code line in the AssemblyInfo source.
In addition, the first two numbers indicate the major and minor versions of the assembly and they are more important than the other two. It would be better to leave the other two of the AssemblyVersion attribute always as zero as we have the other two more version attributes to provide further information to the system or users when necessary.
Now, let’s look at the AssemblyFileVersion. It’s mainly used for deployment purposes and by setup programs, from the installation perspective. From bug reporting and troubleshooting perspective, it is also important to match the problematic assembly with the source build.
It is a good practice to use the AssemblyFileVersion attribute to mark assemblies that have the same AssemblyVersion but are generated from different builds. More specifically, the first two numbers of the AssemblyFileVersion had better match the ones of the AssemblyVersion, and the other two (build number and revision number) change with each build either manually or automatically.
Here is an example:
[assembly: AssemblyFileVersion("8.2.345.3")]
The AssemblyFileVersion is not mandatory. If it does not show up in the AssemblyInfo file, its value will be defaulted as the one of the AssemblyVersion. The CLR does not care about the AssemblyFileVersion at all, so theoretically it can hold anything such as an arbitrary string but it s not a good practice. The Properties UI of the Explorer will get confused as it can only show the File version (originated from the AssemblyFileVersion) properly in the four-number format. An arbitrary string may be not convenient to match the deployed assembly with the code stream either.
In fact, we have demonstrated that the AssemblyFileVersion information can be viewed in the file Properties UI of Windows OS in early posts. We did not explicitly mention it at that moment though.
The ‘File version’ property in the UI means it. People may wonder which attribute the Product version property in the UI corresponds to. Is it what the AssemblyVersion attribute tries to deliver?
Do not worry. We will uncover the veil right now. In fact, things are clear though once we bring up the third version attribute, AssemblyInformationalVersion.
The AssemblyInformationalVersion is to specify the product version of the assembly. This is the version for display and open discussion purposes. This version can also be an arbitrary string as '8.2 Alpha2' in that the CLR cares nothing about it either. Being a good practice we’d better name it this way to make the attribute really informational to the audience.
The AssemblyInformationalVersion is optional, and if not given, the AssemblyVersion takes over once again.
Here is a good example:
[assembly: AssemblyInformationalVersion("8.2 Alpha2")]
Now the Properties Details UI looks like:
As a natural result, we do not see the "8.2.0.0" anywhere in the UI as the AssemblyVersion piece information is not what the UI should care about, which is designed mainly for software users instead of developers.
AssemblyInfo Updater of RevitAddinWidget can help review popular assembly information of all available projects in a Visual Studio solution and update the information conveniently and flexibly in a single central place.
Recent Comments