1

After a lot of reading I'm a tad confused as to what the best practices are around managing the version held in assemblyinfo.cs. There seem to be varying approaches, and some seem quite out of date. All I want is to be able to set something like this:

1.0.$BUILD_VERSION.0

after which the build translates to something like:

1.0.142.0.

How is everyone else doing it? I'm using Jenkins for CI, specifically the Jenkinsfile approach which is stored in my Git repository. I got close to something using a .BAT file but then hit a brick wall as I couldn't pull in environment variables from a windows bat file for use in Jenkins.

Stefan
  • 17,448
  • 11
  • 60
  • 79
Sulphy
  • 766
  • 2
  • 9
  • 29
  • https://github.com/marooou/change-assembly-version-plugin Tons of others on Google. – Lex Li Jul 24 '18 at 15:26
  • Thanks @LexLi - I had used that in the past but it doesn't seem to work with the multi branch pipeline/Jenkinsfile, unless you have different experience? – Sulphy Jul 24 '18 at 18:24

2 Answers2

1

If it suits you, you can use the automatic build numbering in the assemblyinfo.cs

Note: you must remove the AssemblyFileVersion attribute:

// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.3.*.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")] not used

It automatically creates build numbers for you, related to the time of build.

Here is more on this subject: AssemblyInfo version information asterisks

Stefan
  • 17,448
  • 11
  • 60
  • 79
  • Thanks Stefan, are you using this with a build server like Jenkins, or just building locally? I had discounted this approach previously as thought it wouldn't really work in a team setup where people are committing changes. – Sulphy Jul 24 '18 at 14:42
  • 1
    Hi, to be fair; I haven't tried it with a build server. But, as far as I know MSbuild should interpreter this correctly. If you don't mind the "randomness" of the build numbers it's worth a try. In the past I wrote a build step to accomplish something similar with the build server of TFS to make sure the build numbers where actual incremental build numbers: in the end: no one cared about it and it wasn't worth the effort ;-) – Stefan Jul 24 '18 at 14:47
  • By the way; the nature of the numbering (time related) should avoid any build number collisions and should work across the team with multiple check-ins. – Stefan Jul 24 '18 at 14:52
1

Personally I would steer away from Jenkins-specific tools but rely on something more generic like environment variables, that will keep on working if you'd ever switch CI's plus is easy to test locally on the command line without any CI at all.

Surely Jenkins, like other CI, sets an environment variable containing a build number. So all you have to do is get that into your AssemblyInfo.cs. If you search around for 'update AssemblyInfo.c programmatically' you'll find a myriad of answers.

We use an msbuild-only solution by just instructing the CI to run a particular msbuild file before the actual build and using the FileUpdate task because that is fairly simple. But e.g. a PowerShell script could do it just as well. It looks similar to:

<ItemGroup>
  <AsmInfoFiles Include="$(ProjectRoot)\**\AssemblyInfo.cs"/>
<ItemGroup>

<PropertyGroup>
  <NewVersion>$(VersionMaj).$(VersionMin).$(VersionBuild).0</NewVersion>
<PropertyGroup>

<Target Name="UpdateVersion">
  <FileUpdate Files="@(AsminfoFiles)" Encoding="utf-8"
     Regex="\[assembly:\s*AssemblyVersion\(.*\)\]"
     ReplacementText="[assembly: AssemblyVersion(&quot;$(NewVersion)&quot;)]"/>
</Target>

The version numbers are published by the CI as environment variables.

stijn
  • 34,664
  • 13
  • 111
  • 163