In case you aren’t familiar with NuGet, check out this link: http://www.nuget.org
In short, NuGet allows you not to have to check-in all those binaries that you depend on to build and deploy your application. If you use NuGet, it will simply download all the dependencies at build time.
From the link above or from within Visual Studio, you can install NuGet. This will install a Visual Studio plugin that does all the magic. If you want to know more about the magic of NuGet, check out this post by Phil Haack.
In this example, I will simply create a project that uses a simple NuGet package (ELMAH) and builds it on a standard build machine. I already have TFS installed with a Build Controller and Agent ready to go.
Note: I am using TFS11 Beta, so any screen shots are subject to change before release. However, everything I am doing should work in Visual Studio 2010 as well.
Here are my steps:
static void Main(string args)
Elmah.MemoryErrorLog log = new Elmah.MemoryErrorLog();
log.Log(new Elmah.Error(new Exception("Hello ELMAH!")));
List<Elmah.ErrorLogEntry> list = new List<Elmah.ErrorLogEntry>();
log.GetErrors(0, 100, list);
foreach (Elmah.ErrorLogEntry err in list)
By default, NuGet will add all the files needed to build and run your program to the solution (and source control). If you were to simply check-in everything now, the build would work perfectly and your drop location would include everything you need. However, depending on the NuGet packages that you are using this could lead to a lot of extra files in Source Control that you really don’t want to version. So, how do you avoid checking in all those extra files? It is so simple…
After you finish these steps, you have a solution that can be built on any machine. Simply do a “TF.exe Get” to get the files and then use MSBuild or Visual Studio to build it. Part of the build process will download the package and its dependencies for you!
Simple. The build machine will do the same thing that any of your developers or testers would do, get the files from source control and build them. That’s the beauty of NuGet – it is built into your build system. But, to finish the example, let’s walk through the work you have to do to get this solution to build on your build machine.
This should cause a build to start on your build machine. You can watch the progress of the build from the Builds page or by opening up the build by double clicking on it.
You should notice that it succeeds without any errors. The build machine successfully downloaded the NuGet packages for the build. If you open the drop folder, you can see the evidence of it by the fact that the Elmah.dll assembly is there just as expected. And if you open a command window to this folder, running “SimpleLoggingExample.exe” should work as expected.
Well, that’s it! I was totally surprised by how easy this was to set up and get going. NuGet is definitely changing the way that .net applications are built! And if you are a producer of .net libraries, you may want to consider creating a NuGet package for your library and providing it to the world :)