views:

167

answers:

4

At my job, the assembly version of each project in the source control is kept to 1.0.0.0. When the build machine make a new daily build, it has a task to update the assembly version but does not check in the updated assemblyinfo.cs. So on our dev machines, the assembly version of the dlls we are compiling are always set to 1.0.0.0.

Is it best practice to keep the assembly version up to date in the source control or are we doing the right thing already?

What are the pros and cons of each possibilities?

Thanks


Related or Duplicate:
Should AssemblyInfo.cs be placed in version control?

+3  A: 

Con:

  • you cannot debug or test any code that depends on the correct assembly version (if you have such code)

By the way, there is an easier way to make sure all of your assembly versions are in sync: define a public const string "VersionMask" in a public class VersionInfo in a top level assembly that is referenced by all other assemblies and put

[assembly: AssemblyVersion(VersionInfo.VersionMask)]

in every AssemblyInfo.cs file (provided you ar using C#), for VB.NET it is

<Assembly: AssemblyVersion(VersionInfo.VersionMask)>
Doc Brown
A: 

My approach has always been, you should be able to build the thing just by having access to the source control system. So, if the script that updates the assemblyinfo.cs is in source control, then no problem.

Cheeso
A: 

I guess its better to store the version in assemblyinfo.cs, so that anyone can checkout and build the correct version. Having Assembly version same on Dev env. also create issue while debugging a particular version. Also .NET assembly version is important, as which without proper version dll, the assembly won't load, and this will help you in debugging also.

Priyank Bolia
+1  A: 

This is not correct, you should not automatically update [AssemblyVersion]. That attribute plays a very important role in the assembly resolution process when the CLR is looking for the correct version of an assembly to load. Albeit that this is only checked when the assembly is stored in the GAC. It should only be changed when a developer makes a breaking change in the public interface of the assembly, one that would make it unusable in an app that isn't otherwise recompiled with an updated reference assembly.

You should update [AssemblyFileVersion]. That's also the version that's visible in Explorer when you look at the Version property tab. Now you also no longer care that much that the file gets checked-in.

The same thing was done with the .NET assemblies from .NET 2.0 through .NET 3.5 SP1. All the standard assemblies stayed at assembly version 2.0.0.0, the file version has been changed thousands of times.

Hans Passant