6

I want to change the assembly version number of a C# project at build time by passing it as a property on the MSBuild command line.

AssemblyInfo Task will modify the assembly version inside a AssemblyInfo.cs before compiling. This is nearly what I want. The problem is I don't want AssemblyInfo.cs to be changed because of source control issues. I don't want all these AssemplyInfo.cs files to show as being modified and needing to be checked in every time we do a build.

What I would like is a "thing" that changes the assembly version number after compilation - perhaps using a post build weaving task. Does such a "thing" already exist somewhere either as open source or a retail product? If not, can someone point me to documentation for writing a post build weaver task?

starblue
  • 55,348
  • 14
  • 97
  • 151
Charles
  • 2,642
  • 3
  • 33
  • 53

4 Answers4

7

Since the AssemblyVersion does get cooked into your assembly at compile time, the AssemblyInfo.cs file with the current build number does belong in source control.

If your issue with storing this in source control is because you don't want tons of files that need to be updated, try this.

You can establish links in your solution so that all projects point to a single file, e.g. SharedAssemblyInfo.cs. Here is a page describing this process:

http://blogs.msdn.com/b/jjameson/archive/2009/04/03/shared-assembly-info-in-visual-studio-projects.aspx

You can use the SharedAssemblyInfo.cs file using the AssemblyInfo task that you know about already, and this will be the only file that needs to be checked back into source control.

bentsai
  • 3,063
  • 1
  • 27
  • 29
  • Presumably the build script containing the version number would already be in version control, making the build fully reproducable without having to tweak another file. – Brian Kretzler Mar 16 '11 at 16:43
  • Good answer, and a valuable comment from Spider M9 - I would like to add that while it may be undesirable to have churn in source control relating to version numbering, reproducability is extremely important. I will make the assumption that you are changing the Assembly Version, not just the Assembly File Version... If you are strong-naming your assemblies, the impact of changing a version number of an assembly can significanly affect the behavior of your application. As such, this needs to be tracked in some way - exactly what source control is for. – Adam Jun 19 '11 at 22:08
3

You can use the WriteCodeFragment task to generate with each build a new source file (named perhaps _AssemblyInfo.cs) that is not in source control and that contains only the AssemblyVersion attribute. Add the _AssemblyInfo.cs file to the project normally and generate it in a custom target that executes prior to the Build step. That would be less intrusive than manipulating the assembly after you've built it.

Brian Kretzler
  • 9,748
  • 1
  • 31
  • 28
1

Try setting the AssemblyVersion in your AssemblyInfo.cs file as following: 

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

It should increase your AssemblyVersion with every build, if something changed.

Andrew
  • 5,395
  • 1
  • 27
  • 47
  • Yea. I know about that, but I need the version number to be something specific. Thanks. – Charles Mar 16 '11 at 19:58
  • Also each build would change version while we may want to change the version number only if actual code has changed. Proposed solution also generates different version for Debug and Release, while app funcianality is exactly the same ;) – Pawel Cioch Mar 17 '16 at 14:07
0

It might be best to have another file checked in and create an AssemblyInfo.cs from with http://code.mattgriffith.net/UpdateVersion/ or something like this from Subversion http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html

kenny
  • 21,522
  • 8
  • 49
  • 87