Your official information source from the .NET Web Development and Tools group at Microsoft.
Since the release of NuGet 2.7 with Automatic Package Restore and implicit consent, many developers have adopted the new approach and provided some great feedback on their experiences. Based on that feedback, we have collected a set of tips to help you start using the new restore features.
Even though package restore consent is on by default, users still need to choose to omit their packages from source control before package restore is engaged. By default, source control systems will include the packages folder in your repository, and you need to take action to omit the packages from source control.
Use the .gitignore file to ignore the packages folder. Adding a line that simply has "packages" on it will do the trick.
*.user*.suobinobjpackages
Use a .nuget\NuGet.Config file to disable source control integration for the solution, as explained on the NuGet Config Settings document under the "Source control integration" section. Using this approach, rather than cloaking the packages folder or otherwise ignoring it, NuGet knows to completely skip the call into Visual Studio to pend changes to the packages folder.
Here is what your .nuget\NuGet.Config file should look like to disable this integration. Note that you won't be able to create the .nuget folder using File Explorer because it prevents the creation of folders that begin with a dot. You will need to create the folder from a command prompt.
<?xml version="1.0" encoding="utf-8"?><configuration> <solution> <add key="disableSourceControlIntegration" value="true" /> </solution></configuration>
If you have a solution that has previously enabled the MSBuild-Integrated Package Restore approach and you would like to migrate to use Automatic Package Restore, there are just a few steps you can take to smoothly make the switch. The full walk-through is documented on the NuGet Docs site and it explains how to remove the unnecessary files from your solution and how to clean up your project files.
Whether you're using TFS on-premises or you're using the Team Foundation Service, you can configure your Team Foundation Build to automatically restore packages as part of the build. This can work with either Git or TF version control.
The documentation for how to configure your build can be found here: http://docs.nuget.org/docs/reference/package-restore-with-team-build
Some users reported that they were still seeing build errors indicating that package restore consent had not been given. When we made the package restore changes in NuGet 2.7, we identified one scenario where this would happen but determined we couldn't implement a fix and would rather have to document the scenario, cause and solution.
In order to hit this problem, there’s a specific scenario you must be in. The scenario isn't extremely common, but we have already heard reports of it.
In this scenario, the solution contains a .nuget folder that has nuget.exe version 2.6 or earlier. In those versions of nuget.exe, package restore consent was OFF by default (hard-coded to false when not present in nuget.config). When building this solution in Visual Studio, NuGet identifies that the MSBuild-integrated package restore is enabled and therefore automatic package restore is skipped. Then the old nuget.exe kicks in for the package restore and it does not find package restore consent to be given, yielding the following build error:
Package restore is disabled by default. To give consent, open the Visual Studio Options dialog, click on Package Manager node and check ‘Allow NuGet to download missing packages during build.’ You can also give consent by setting the environment variable ‘EnableNuGetPackageRestore’ to ‘true’.
As explained on the Package Restore documentation, there are three ways to address this situation.
nuget.exe update -self
Now we need a solution to replace Microsoft.Bcl.Build's .targets file, and we can fully leave the packages folder out of source control.
Hi Cory,
With the new automatic package restore, along with an update to the Microsoft.Bcl.Build package, that issues should be fully addressed too!
Here is a blog post by the .NET Framework team where they cover it in more detail:
blogs.msdn.com/.../improved-package-restore.aspx
Thanks for commenting on this; I should have thought to cover it in the post.
Jeff Handley
Great work.
Is there anything in the works regarding Blend? There is a severe problems using it with package restore. See: nuget.codeplex.com/.../2858
Thanks in advance