Back to the basics: version numbers
It still amazes me how so many people don’t understand (or even care about) the version number of an assembly. A version number is composed of four parts: major number, minor number, build number and revision number. For instance, here’s a valid version number:
The first two (major and minor) define what is know as the “public version” of an assembly (notice that this number is used whenever you export an assembly – ex.: COM Interop). The third number defines the build of an assembly. Suppose, for instance, that you work for a company which produces a daily build of an assembly. In this case, this number should be incremented for each day’s main build. Finally, the last part is called the revision number. You’ll change its value whenever you need to perform an “extra build” to solve a pending issue (ex.: a bug which has been found after the daily build).
Now, that we all understand version numbers, I guess I should mention that you’ll encounter several “types” of version numbers. An assembly is always associated with three version numbers:
- AssemblyFileVersion: used for information purposes only. It’s the number you see when you access the properties of an assembly in Windows Explorer;
- AssemblyInformationalVersion: again, this is used for informational purposes. It indicates the version of the product that includes this assembly.
- AssemblyVersion: this version number is stored on the metadata and it’s used by the CLR when binding to strongly named assemblies.
And I guess this sums it up for assembly versions…