3

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?

Community
  • 1
  • 1
Jeff Cyr
  • 4,774
  • 1
  • 28
  • 42

4 Answers4

3

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
  • 19,739
  • 7
  • 52
  • 88
  • seems to me this would only work if you don't try using any activities in build templates or ps scripts that increment for you. which most CIs will have. So not really useful? – user1161137 Sep 23 '15 at 13:56
  • @user1161137: what hinders you to set the `Version.Mask` string to something like `3.2.1.*` ? – Doc Brown Sep 23 '15 at 14:22
  • i've only recently been playing with custom build templates, and it seems it's just a regex search on literals in the actual file. it doesn't seem to have the ability to interpret what versionmask would resolve to. so how would that work? – user1161137 Sep 23 '15 at 14:31
  • @user1161137: my suggestion just aims at using the [standard mechanism](https://msdn.microsoft.com/library/system.reflection.assemblyversionattribute.assemblyversionattribute%28v=vs.110%29.aspx) MS provides for including build and revision number. Of course, that does not solve the problem if one wants to use a different, custom mechanism. However, if a CI tool can increment a version number automatically in a set of `AssemblyInfo.cs` files (as described by the OP), it can surely increment that version number in only one central file. – Doc Brown Sep 23 '15 at 14:46
2

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 discriminative when the assembly is stored in the GAC. Preferably 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 can always 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.

For comparison, 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. That these changes were always compatible is however a pretty tough act to follow.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

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
  • 189,189
  • 101
  • 473
  • 713
0

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
  • 14,077
  • 14
  • 61
  • 82