We have a nightly build process that automatically versions all C++ projecs. Here’s how it works. There’s a common header file VersionNumber.h that has a specific #define for the version number. The nighly build checks this file out, increments the integer behind that #define and checks it in. All Visual C++ projects #include that header into their resource files and use that define for specifying the version (version is smth like 1.0.3.ThatNumber).
So far so good. Now I’d like to have the same for the C# class libraries built in the same daily build. Currently they all have
[assembly: AssemblyVersion("1.0.*")]
in the AssemblyInfo.cs files and libraries end up with 1.0.HorribleNumber.AnotherHorribleNumber as the version and the two numbers don’t correlate to the number used by C++ projects.
How do I have the same determenistic automatic version numbering in my C# projects with minimal effort?
Firstly you can specify the full version as follows:
Secondly, a common approach to make this a little more straightforward (and echoes your C++ approach) is to have a single Version.cs file (name unimportant) that sits in a common location that has the version attributes in it. You can then add this file as a link to all your cs projects, remembering to remove the version attributes from your AssemblyInfo.cs files. In this way you only have a single file to update (before running your build). You can also put other common assembly attributes in your Version.cs file such as: NeutralResourcesLanguage or CLSCompliant.
If you do not use a single “Version.cs” approach, then you can work recursively through your source code directory structure, and update AssemblyInfo files individually (before running your build).
It may not be relevant to you, but the version numbers (in AssemblyVersion) have a maximum range of 16bit. I have seen this become an issue where dates have been used for these numbers. If you wish to have more latitude then AssemblyFileVersion does not have these restriction, but is purely for informational purposes only in .Net, rather than part of the assembly’s identity. It is common to set AssemblyVersion and AssemblyFileVersion to the same values as some tools display combinations of these.
See the following for more on AssemblyVersion vs AssemblyFileVersion:
What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?