{"id":18449,"date":"2013-08-27T17:17:00","date_gmt":"2013-08-27T17:17:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2013\/08\/27\/nuget-package-restore-with-team-foundation-build\/"},"modified":"2021-09-30T17:23:43","modified_gmt":"2021-10-01T00:23:43","slug":"nuget-package-restore-with-team-foundation-build","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/nuget-package-restore-with-team-foundation-build\/","title":{"rendered":"NuGet Package Restore with Team Foundation Build"},"content":{"rendered":"

Note: <\/strong>This post is now also part of the official NuGet documentation<\/span><\/a>.<\/em><\/span><\/p>\n

In this post, I\u2019ll provide a walkthrough on how to use package restore with Team Foundation Build<\/a> with both, git<\/a> as well TF version control<\/a>.<\/p>\n

In our previous blog post on how we improved package restore<\/a>, I showed that NuGet 2.7<\/a> and Microsoft.Bcl.Build<\/strong> made restoring packages a lot easier. However, I didn\u2019t explain in great detail on how you can restore packages during the build. In this post, I\u2019ll close that gap by providing a more detailed walkthrough.<\/p>\n

Although this walkthrough is specific for the scenario of using Team Foundation Service<\/a>, the concepts also apply to other version control- and build systems.<\/p>\n

The General Approach<\/h2>\n

An advantage of using a package manager like NuGet is that you can use it to avoid checking in binaries to your version control system.<\/p>\n

This is especially interesting if you are using a distributed version control system<\/a> like git because developers need to clone the entire repository, including the full history, before they can start working locally. Checking in binaries can cause significant repository bloat as binary files are typically stored without delta compression.<\/p>\n

NuGet has supported restoring packages<\/a> as part of the build for a long time now. The previous implementation had a chicken-and-egg problem for packages that want to extend the build process because NuGet restored packages while building the project. However, MSBuild doesn\u2019t allow extending the build during the build; one could argue that this an issue in MSBuild but I would argue that this an inherent problem. Depending on which aspect you need to extend it might be too late to register by the time your package is restored.<\/p>\n

The cure to this problem is making sure that packages are restored as the first step in the build process. NuGet 2.7 makes this super easy via a simplified command line<\/a>. In order to restore packages for an entire solution all you need is to execute a command line like this:<\/p>\n

nuget.exe restore pathtosolution.sln<\/code><\/pre>\n
When your build process restores packages before building the code, you don\u2019t need to check-in .targets<\/strong> files.<\/p>\n
Note:<\/strong> Packages must be authored to allow loading in Visual Studio (our packages<\/a> now all behave like this). Otherwise, you may still want to check in .targets<\/strong> files so that other developers can simply open the solution without having to restore packages first.<\/em><\/p>\n
The following demo project shows how to set up the build in such a way that the packages folders and .targets files don\u2019t need to be checked-in. Finally, I\u2019ll show how you can setup an automated build on the Team Foundation Service<\/a> for this sample project.<\/p>\n
Repository Structure<\/h2>\n
Our demo project is a simple command line tool that uses the command line argument to query Bing. It targets the .NET Framework 4 and uses many of our packages<\/a> (Microsoft.Net.Http<\/a>, Microsoft.Bcl<\/a>, Microsoft.Bcl.Async<\/a>, and Microsoft.Bcl.Build<\/a>).<\/p>\n
The structure of the repository looks as follows:<\/p>\n
<Project><\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 .gitignore<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 .tfignore<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 build.proj<\/span>\n\u00a0\u00a0\u00a0 \u2502<\/span>\n\u00a0\u00a0\u00a0 \u251c\u2500\u2500\u2500src<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 BingSearcher.sln<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500\u2500BingSearcher<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 App.config<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 BingSearcher.csproj<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 packages.config<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0 Program.cs<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2502<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2514\u2500\u2500\u2500Properties<\/span>\n\u00a0\u00a0\u00a0 \u2502\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AssemblyInfo.cs<\/span>\n\u00a0\u00a0\u00a0 \u2502<\/span>\n\u00a0\u00a0\u00a0 \u2514\u2500\u2500\u2500tools<\/span>\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u2514\u2500\u2500\u2500NuGet<\/span>\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 NuGet.exe<\/span><\/p>\n
You can see that we haven\u2019t checked-in the packages<\/code> folder nor any .targets<\/strong> files.<\/p>\n
We have, however, checked-in the nuget.exe<\/code> as it\u2019s needed during the build. Following widely used conventions we\u2019ve checked it in under a shared tools<\/code> folder.<\/p>\n
The source code is under the src<\/code> folder. Although our demo only uses a single solution, you can easily imagine that this folder contains more than one solution.<\/p>\n
In order to communicate to the version control that we don\u2019t intent to check-in the packages<\/code> folders, we\u2019ve also added ignore files for both git (.gitignore<\/code>) as well as TF version control (.tfignore<\/code>). These files describes patterns of files you don\u2019t want to check-in.<\/p>\n
The .gitignore<\/code> file looks as follows:<\/p>\n
syntax: glob<\/span>\n*.user<\/span>\n*.suo<\/span>\nbin<\/span>\nobj<\/span>\npackages<\/span><\/p>\n
The .gitignore<\/code> file is quite powerful<\/a>. For example, if you want to generally not check-in the contents of the packages<\/code> folder but want to go with our previous guidance of checking in the .targets<\/strong> files you could have the following rule instead:<\/p>\n
packages<\/span>\n!packages\/**\/*.targets<\/span><\/p>\n
This will exclude all packages<\/code> folders but will re-include all contained .targets<\/strong> files. By the way, you can find a template for .gitignore<\/code> files that is specifically tailored for the needs of Visual Studio developers here<\/a>.<\/p>\n
TF version control supports a very similar mechanism via the .tfignore file<\/a>. The syntax is virtually the same:<\/p>\n
*.user<\/span>\n*.suo<\/span>\nbin<\/span>\nobj<\/span>\npackages<\/span><\/p>\n
build.proj<\/h2>\n
For our demo, we keep the build process fairly simple. We\u2019ll create an MSBuild project that builds all solutions while making sure that packages are restored before building the solutions.<\/p>\n
This project will have the three conventional targets Clean<\/code>, Build<\/code> and Rebuild<\/code> as well as a new target RestorePackages<\/code>.<\/p>\n