在版本控制时将Git与.NET结合的最佳方法

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 xyz 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 2

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.

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

Nant fits your needs ! Check this : NAnt tasks reference

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