Build Process Meets NuGet Gallery

The next logical step is integrating your NuGet gallery with your existing build processes. If you don’t have a build process and you’re looking for a little “getting started” guidance with Team Foundation Server (TFS) build processes, check out the Microsoft Visual Studio ALM Rangers Build Customization Guide at rabcg.codeplex.com.

All right: You have a library you want to make available on a gallery, which could be the official NuGet Gallery, a proprietary gallery or even a local file share. No matter which, you’ll have to perform certain tasks to create the NuGet package, and they’re generally the same tasks no matter where the gallery resides.

Through the course of developing your product, you’ll repetitively go through the process of coding, compiling, packaging, pushing and publishing. You’ll also, we hope, include a couple of healthy doses of testing; results from that testing might make you deviate from publishing to the gallery if you find any issues

 

Keeping consumers happy with working software is a good thing, and you’ll have an easier time doing so using a managed process. Remember, though, the managed process can’t be entirely automated; there’s no replacement for human verification. Don’t assume you can publish just because your software passes all the automated tests. You could easily publish a package that isn’t ready and make your consumers angry. Moreover, they won’t be happy if you publish constantly and they can’t keep up with the ever-changing versions. Make publishing a conscious decision.

Use the build process to build, package and push your NuGet library to a gallery where you perform final tests and do that human verification. That way, you can choose continuous integration or a scheduled build to automatically push the package and make it ready for you to test. How might you do that? Here’s an example using TFS and its workflow-based automated build capability.

NuGet.exe is a stand-alone, parameter-driven console application, but it can easily be called by another process, such as TFS Team Build. Team Build executes a workflow; in TFS terms, this is a set of custom activities controlled through a build template and initiated by a build definition. One packaged solution for automating the NuGet development process is the NuGetter project at nugetter.codeplex.com. This project provides an automated shell around the NuGet.exe application. We’ll use this package to show what can be done and things to think about as you work toward automating your own NuGet packages.

The build definition in TFS is where you provide all the necessary information to do the packaging, push and publish. Building a flexible and repeatable build process for NuGet requires several pieces of data and the switches that turn portions of the process on or off. The data is organized into categories that are titled to give you a sense of the order in which the steps are executed.

 

The PrePackaging section is used for complicated or multiframework NuGet packaging that requires some initial preparation. NuGetter can call a Windows PowerShell script (if you desire) to organize the library files to make packaging easier. This step isn’t required, so you can use the flag parameter “Invoke PowerShell Script” to tell the process whether to execute the script.

You can use a .nuspec file directly to define how your package will be created or you can do so indirectly through a .csproj file. It’s up to you; use the approach that better suits your needs.

As you can see, all of the parameters required for packaging are included. Version, base path (source folder for packaging), API Key and gallery location (called Source) are all provided as part of the build definition. However, the security of this information might be of great importance to you. For example, the API Key is what allows you and only you to push NuGet packages to the gallery. If that key becomes public, anyone could push bogus packages in your name. Because of this, NuGetter allows you to provide either the actual API Key or a path to a file that contains the key. If you use a file path, the build process reads the file, extracts the key and uses it without listing the key in the log, and security is maintained. Obviously, the build service ID must have read access to the file for this to work.

Another potential issue for you is managing the version of your package. In Figure 6, the version number is provided in the build definition. But, do you really want to keep changing that number in the build definition? What happens when you have several builds (continuous integration [CI], daily, other scheduled and various manual builds)? NuGetter gives you the choice to enter the version directly or, as with the API Key, you can provide a file path that multiple build definitions can use. They will all use the same version number and you can manage it in just one place.

The Push Destination in the example is the NuGet Gallery, but this is where you provide the build destination even if you’re pushing your package to an internal gallery or to a local file store. This is another case where the build process might need to intervene. NuGet.exe expects a URL as the destination and if you’re pushing to a local store—which won’t be a URL—the process needs to interpret the destination format. In this case, instead of using NuGet.exe to do the pushing, you have the build process do it.

For reasons of completeness and feature parity with NuGet.exe, NuGetter does provide for automated publishing. Just keep in mind our earlier caveats before deciding to use this capability.

Original article