{"id":16776,"date":"2016-05-26T21:20:39","date_gmt":"2016-05-26T14:20:39","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/?p=16776"},"modified":"2019-02-14T17:33:59","modified_gmt":"2019-02-15T01:33:59","slug":"versioning-nuget-packages-cd-3","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/versioning-nuget-packages-cd-3\/","title":{"rendered":"Versioning NuGet packages in a continuous delivery world: part 3"},"content":{"rendered":"

This is the third and final post in a series covering strategies for versioning a NuGet package. If you missed part 1<\/a> or part 2<\/a>, you should read those first. Today\u2019s post walks through a specific workflow that Git users could adopt, using a really powerful tool called GitVersion. GitVersion comes with some expectations about the layout of your branches, so it may not be for everyone.<\/p>\n

Let\u2019s walk through using Package Management, Team Build, and GitVersion to manage version numbers. Because it\u2019s more complicated than previous walkthroughs, I\u2019ve chosen to be more verbose and detailed in my explanation.<\/p>\n

I\u2019ve decided that I\u2019ll follow the GitFlow<\/a> branching model for this project. There\u2019s a great tool called GitVersion<\/a> which lets me translate<\/a> GitFlow branches and tags directly into semantic versions. For brevity, I\u2019m omitting a lot of experimentation and dead-ends I went down before finally settling on this flow. I encourage you to play around with GitFlow and GitVersion yourself.<\/p>\n

Start by creating a new class library called MyComponent in Visual Studio. Let\u00a0Visual Studio create a new Git repo for you.<\/p>\n

Right-click the project and choose Manage NuGet Packages. From NuGet.org, add GitVersionTask.<\/p>\n

\"NuGet<\/a><\/p>\n

Next, edit AssemblyInfo.cs to comment out the explicit assembly versioning. GitVersionTask will take care of versioning the assembly.<\/p>\n

\"Edit<\/a><\/p>\n

The last thing to do on the client side before building is to set up GitVersion\u2019s config file. While the defaults are great for most people, I personally prefer the continuous deployment<\/a> style of versioning. In the solution folder, add a file GitVersionConfig.yaml with the following contents:<\/p>\n

mode: ContinuousDeployment\nbranches: {}\n<\/code><\/div>\n

Commit the changes and build the solution. Look at the properties of the built DLL and notice all the GitVersion magic represented in the Product version field.<\/p>\n

\"DLL<\/a><\/p>\n

Next, push your code to a Git repo on Visual Studio Team Services. Everything we do from here on out will support creating and versioning a NuGet package using the tools VSTS provides plus the GitVersion extension<\/a>. Go ahead and install GitVersion from the Marketplace into your VSTS account. This will introduce a new build step that we\u2019ll need later. Also, if you haven\u2019t installed Package Management<\/a> in your account, do that as well.<\/p>\n

In the Code hub, click the \u201cbuild: setup now\u201d badge.<\/p>\n

\"Build:<\/a><\/p>\n

Leave the defaults to create a new Visual Studio build. Then, make the following changes to your newly-created build:<\/p>\n