Earlier we looked at the automated building and packaging of Kerberos.NET using VS Online. At this point the only thing we get out of it in this state is knowing the code compiles and any tests pass — which I suppose is actually quite a feat on it’s own considering I had no indicator of either when I started. We can, of course, do better! The last piece we need is automated publishing of the final nuget package to the feed for others to consume.

As it turns out this is relatively straightforward to do. The process is:

1. Defining artifacts to keep after build succeeds
2. Create a On-Release task that uploads the package to nuget

Defining the build artifacts is easy. All you need to do is specify that the output of the build should go to the staging directory, which is the variable $(Build.ArtifactStagingDirectory). You can also explicitly set the Version here too, if you happen to be using the build system to increment build versions.

Now all you need to do is publish the collected artifacts to nuget. To do that you first need to configure the nuget service, similar to how you configured Github. First go to the settings via the gear icon and select Services. Add a new service and find the nuget option. This’ll prompt for connection details:

The Feed URL for nuget.org is https://api.nuget.org/v3/index.json. The ApiKey can be found in your Nuget account API Keys. If you don’t have an API Key, go ahead and create one, setting the expiration to 365 days. Oh, and be sure to set a reminder for 365 days from now to tell you the key needs regenerating. *grumble*

Lastly verify the connection and hit Ok. Once your service is configured you can go back to your build and select the Releases tab. Hit the + icon to add a new release definition. Create an empty template and give the environment a name. Click into the environment and add a new task to the Agent Phase. Add the Nuget task. Set the command to push, configure the path to the packages. In this case we used $(System.DefaultWorkingDirectory)/Kerberos.NET CI/drop/*.nupkg. Then of course, select the Nuget service you created earlier.

Now that we have a release task, we can kick off a new build, or just work with an existing build that has the artifacts. At the top of the build details screen is a Release button. This brings up the release dialog that lets us kick off the process.

Go ahead and kick off the release. It’ll take a few seconds to kick off, but once it’s done and if all things went well you should see the new package available in nuget (yes, the version numbers are different — I don’t want to kick off a new package without any changes).

Now I don’t have to worry about manually futzing with generating and upload package files — if I’m happy with the given build all I need to do is tell it to release.

These days most developers won’t even consider third party libraries unless they’re available through nuget packages. I say this from experience — I will prefer a nuget’ed library over one where I have to manage the assembly manually. It saddens me a bit when I have to commit binaries to source control.

Naturally this great new project of mine should therefore have it’s own nuget package! How do you use it? It’s quite easy; just pop open the Package Manager Console and add it!

Package Manager Console Host Version 3.4.4.1321

Type 'get-help NuGet' to see all available NuGet commands.

PM> install-package kerberos.net

Alternatively you can search for it through UI, though it’ll take some time to index.