Best way to combine Git with .NET when versioning

Question

I'm currently working on a project (just me), and I already know how to handle versioning on it. I'm using the classic <major>.<minor>.<build or patch>.

The problem I have is that I want to have tags in some of my commits pointing to the corresponding versions, but I don't want to do it manually.

Now I'm currently doing:

• If I'm going to release the v0.2.13, I change the AssemblyInfo.cs and set that version
• Commit the changes on Git
• Add tag v0.2.13 (manually) on Git
• Build the project
• Create a .zip file (not all time time) and name it like ProjectName v0.2.13

Am I doing it wrong?

I could easily create an script to do the last step automatically, but I'm wondering if there is a good practice about automating the other part?

Answer 1

I have a build script in MSBuild that automatically retrieves the git commit currently checked out, and then adds an attribute like this at build time to the assembly:

[assembly: AssemblyInformationalVersion("0.2.13+e3a6f2c1")] [assembly: AssemblyVersion("0.2")] [assembly: AssemblyFileVersion("0.2.13")] 

The numerical part of the version comes from a version.txt file that my build script reads.

The assembly version lacks the 3rd octet because it avoids binding redirect requirements when you increment the build number. The AssemblyFileVersion includes all the data allowed by that attribute, and AssemblyInformationVersion can be any string you want, so using semantic versioning to include the git commit id allows you to indicate exactly which source version built this project.

Then after a build is successful, you can add a v0.2.13 tag if you wish. Personally, as soon as I build a final release, I increment the version.txt file so that all subsequent builds have the next higher version number. Each build after that will have that until I release that version, tagging the commit, increment the version.txt file again, and repeat.

By the way, the AssemblyInformationalVersion string appears in file properties from Windows Explorer, so this provides a guaranteed way to go from an arbitrary built binary to the matching original source code. Also, unfortunately this approach causes csc.exe to report an AL???? warning on builds because the semantic version format doesn't conform to x.y.z syntax. It doesn't mean anything is broken though, and I just ignore the warning.

I never explicitly zip up sources because that is redundant with source control's responsibility. At least if your source is hosted by some online service (even on your private intranet), most git hosts offer on-the-fly download-as-zip capability for a given commit id already.