How to automatically increase the build version if there are changes in the code?

Question

Is there a way to increase the number of build versions automatically if the build changes after the build is complete?

I tried with events after the build, but then you increase the number of versions in each build, and not just if the build process compiled something because of the changes.

Thanks in advance.

EDIT: I want to do this to automatically increase the version number of assemblies where I change the code every time I make a “Build Solution” to avoid it manually. Thus, I can be sure that 2 assemblies with the same version ALWAYS have the same code.

Answer 1

Yes, you can get an automatic version increase by using * in the [AssemblyVersion] attribute. Unfortunately, this is rarely the case. What Microsoft was supposed to do was provide the ability to [AssemblyFileVersion]. They did not do this.

[AssemblyVersion] is a very important attribute used by the CLR to verify that the assembled assembly is compatible with the assembly used to compile the code. “Compatible” means: the assembly will work purely with client code, no changes were made to the source code of the assembly, which could make it work incorrectly if the client was not recompiled. Using this definition, updating bug fixes is very compatible. An update that reorganizes the internal implementation of classes in an assembly can also be very compatible. Changes to public classes or members are probably not compatible. Although the JIT compiler is very well versed in the fact that the changes were grossly incompatible (for example, removing a previously public member).

Using * in an attribute essentially means: it is always incompatible. Even if you have not changed the code at all, the assembly will be incompatible after it is built. This is pretty useless in most scenarios, unless you always build the assembly with your client code. And relocate them together. This works, but then the concept of having a version number generally becomes useless.

In short: IMO, you must manage the build version yourself. Change it when you break a change in the public interface of the assembly. This is definitely the approach Microsoft is taking. .NET 2.0 assemblies are still marked as version 2.0.0.0 in the .NET 3.5 SP1 environment. Even if they are no longer compatible, WaitHandle.WaitOne (int) is added later. Otherwise, they did a stellar job of maintaining compatibility over the past 5 years, which would not be easy.

Note that this does not apply to [AssemblyFileVersion], automatically increasing it for each assembly.

Answer 2

If my understanding of the process is correct, when you build your solution, only the changed assemblies (or those in which the related assemblies are connected) are restored.

If the assembly has not changed at all, it will not be recompiled (unless you use the rebuild all command)

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

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

And that makes me use different version numbers for my builds.

Answer 3

If you want to automatically increase the number that is updated each time the compilation is performed, you can use VersionUpdater from the pre-build event. This has the advantage of more control than the default numbering mechanism described in MSDN.