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 ..

Answer 1

Nant fits your needs ! Check this : NAnt tasks reference

It's easy to use and combine with a git repository :-)

Answer 2

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.

Answer 3

If you don't have the capability to use a build server, that's probably the best way to do it manually. However, if you've got the time, I highly recommend getting some type of build server in place. We've had a lot of success with TeamCity. If you have it set up to track your repository, there are ways to do assembly info patching, tagging and post-build deployment (there are a bunch of possible links for those, I recommend just hitting up the documentation).

I found this post pretty helpful when setting up our versioning; you can pretty much exclude the NuGet bits and it should have some decent information. As far as setting up TeamCity goes, just do a quick search for "TeamCity Setup Tutorial" and you should have a ton of resources. Good luck!

Answer 4

I have successfully used the following steps to accomplish something similar to:

• Push new commits to a shared git repo
• TeamCity server checks out code, runs tests and builds the project
• If successful, TeamCity also moves/deletes/packages files for a deployment package
• Then it FTPs the zip to a deployment staging area, where it can be manually deployed (this could be fully automated, but our setup was weird)

You could use a post-commit hook to tag your branch and push to your TeamCity server.

Answer 5

I use Makefiles for everything after the commit.

Depending on how your build system works, you might be able to add a target "release" which tags the current branch and pushes this tag. You would also add a "package" target that depends on the "build" and "release" targets.

If that doesn't work, just create your own Makefile. You might or might not have to name your "Makefile" differently.