How to auto-increment assembly version for release

Recently we needed to implement the increment versioning for a common dll with strong type reference replacement in the dependent projects.

I found a graceful way to do it. But first, let's check the msdn out regarding auto-increment:

Using Auto-Increment Version Numbers

An auto-increment version number is established by adopting the default "1.0.*" pattern for the AssemblyVersion attribute.

The UI in vs.net doesn't support it, you have to edit the 'My Project>AssemblyInfo.vb' file directly.

Advantages

Using auto-increment version numbers has the following advantages:

• The build and revision numbers are handled automatically by Visual Studio .NET and do not have to be handled by the build script or build coordinator.
• You guarantee never to have different builds of an assembly with the same version number.

Disadvantages

Using auto-increment version numbers has the following disadvantages:

• The internal assembly build number does not match your system build number, which means there is no easy way to correlate a particular assembly with the build that generated it. This may be particularly problematic when you need to support your system in a production environment.
• Build and revision numbers are not increased by one but are based on the time an assembly is built.
• A new version of an assembly is generated each time it is built regardless of whether any changes have been made to the assembly. For strongly named assemblies, this means that all clients of that assembly must also be rebuilt to point to the correct version. However, if the build process rebuilds the whole system this should not be an issue.

Using Static Version Numbers

With this approach, you use a static version number, for example "1.0.1001.1", and update the major or minor numbers only when a new version is shipped with your next system release.

Advantages

Using static version numbers has the following advantages:

• You have complete control over the exact version number.
• Assembly build numbers can be synchronized with the system build number.

Disadvantages

Using static version numbers has the following disadvantages:

• The version numbers must be manually updated by the build coordinator or by the build script.
• If the version is not incremented with every build, you may end up with multiple builds of the same assembly with the same strong name. This is undesirable and can be problematic for assemblies that are installed in the Global Assembly Cache (GAC).

Important   If you do not change the version of a strongly named assembly and attempt to install it into the GAC using the Microsoft Windows® operating system Installer, the latest dynamic-link library (DLL) does not install if a previous version exists in the GAC with the same version number.

If you use Gacutil.exe instead of Windows Installer to install the assembly, the updated DLL is installed even if the assembly version number is the same.

Since we have 2 options with their own minuses and pluses, I have come up with a hybrid approach:
  With this approach the  increment version is generated by a custom tool which runs when the build  is Release. That eases up the life of developers, they use the fix version of common library and they don't need to change the strong name reference as long as they build in Debug mode.
   Once the build is ready for Production, the build server starts the Release build and the custom tool increments the common library version with the automated replacement of the strong type common reference in every project.
  Sounds perfect! The custom tool for assembly incrementation is on codeproject: "Autoincrement Version in Visual Studio". Regarding the autoreplacement of strong type common library  in the dependent project - I can't help you guys. I have only the exe file and the copyright is not mine.
But as yon can figured out from the Autoincrement source code - it's fairly easy to write own tool with a regex inside to find and replace the reference.

 Happy Building!