How to increment automatically the version of an assembly if there are changes on the code?

Question

Hello,

there is a way of incrementing the version number of an assembly automatically if the assembly has changed after doing a build of the solution?

I've tried with post-build events but then you increment the version on each build, not only if the build process has compiled anything due to changes.

Thanks in advance.

EDIT: What I want to do is to automatically increment the version number of the assemblies where I change code each time that I do a "Build Solution" to avoid changing it by hand. This way I can be sure that 2 assemblies with the same version ALWAYS have the same code.

Answer 1

If my understanding of the process is correct, when you do a build of your solution, only the assemblies that have changed (or those where linked assemblies have changed) are rebuilt.

If an assembly didn't change at all, it won't be recompiled (unless you use "rebuild all" command)

So in my projects, inside AssemblyInfo.cs of each project, I have this line:

[assembly: AssemblyVersion("1.0.*")]

And this prodcuces me different version numbers for my assemblies.

Answer 2

Yes, you can get automatic version incrementing by using * in the [AssemblyVersion] attribute. Unfortunately, that is rarely correct. What Microsoft should have done is give the [AssemblyFileVersion] that capability. They didn't.

[AssemblyVersion] is a very important attribute, used by the CLR to verify that the assembly that got loaded is compatible with the assembly that was used when the code was compiled. "Compatible" means: the assembly is going to work cleanly with the client code, no changes were made to the assembly source code that could make it fail to work correctly if the client wasn't recompiled. Using that definition, a bug fix update is very compatible. An update that reorganized the internal implementation of the classes in the assembly could be very compatible as well. Changes to publicly visible classes or members is likely to not be compatible. Although the JIT compiler is very good at detecting when the changes were grossly incompatible (like removing a previously public member).

Using * in the attribute essentially means: it is always incompatible. Even if you didn't change any code at all, the assembly will be incompatible after it is built again. That's pretty useless in most any scenario, except if you always build the assembly together with its client code. And redeploy them together. That works, but then the notion of having a version number at all becomes fairly useless.

Long story short: IMO you should manage the assembly version yourself. Change it when you make a breaking change in the public interface of the assembly. That's certainly the approach that Microsoft takes. .NET 2.0 assemblies are still marked as version 2.0.0.0 in the .NET 3.5 SP1 framework. Even though they are not actually compatible anymore, WaitHandle.WaitOne(int) got added later. They did otherwise a stellar job of maintaining compatibility for the past 5 years, it couldn't have been easy.

Note that none of this applies to [AssemblyFileVersion], auto incrementing it for every build is very appropriate.

Answer 3

If you want an auto incrementing number that updates each time a compilation is done, you can use VersionUpdater from a pre-build event. This has the advantage of more control than the default numbering mechanism described on MSDN.