Visual Studio 2017 comes with NuGet 4.0 which adds support for .NET Core, has a bunch of quality fixes and improves performance. This release also brings several improvements like support for PackageReference, NuGet commands as MSBuild targets, background package restores, and more.
NuGet.exe 4.0 is also available for download as a separate component, here.
NuGet Package Manager Extension in Visual Studio 2017
Starting with NuGet 4.0 in Visual Studio 2017, the NuGet Package Manager will be shipped as a part of Visual Studio, and newer versions will not be available for download from the VS extensions gallery. NuGet updates will be pulled in automatically along with other Visual Studio updates.
The NuGet 4.0 Package Manager Extension is currently not available for Visual Studio 2015 (Visual Studio 2015 comes with NuGet 3.4.4, and NuGet 3.5.0 is available as an explicit download for Visual Studio 2015 as well). NuGet 4.0 builds upon several new features and bug fixes available only in Visual Studio 2017, and hence the newer NuGet experiences will not be available in Visual Studio 2015. At the same time, we want packages to work seamlessly across Visual Studio versions. We will be monitoring feedback to determine what experiences we want to enable in Visual Studio 2015 in a future release (for example, the introduction of newer TFMs).
PackageReference will become the standard way to manage NuGet dependencies across all project types. With NuGet 4.0, PackageReference is fully supported for .NET Core projects. This allows you to use MSBuild conditions to choose package references per target framework, configuration, platform, or other pivots. It also allows for fine-grained control over dependencies and content flow. Here is an example of how you would add a PackageReference in your MSBuild-based project file:
<ItemGroup> ... <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0"/> ... </ItemGroup>
You can also try PackageReference with other project types such as WinForms, Windows Presentation Foundation(WPF), and Universal Windows Platform (UWP). More details about usage and known limitations of using PackageReference in non-.NET Core projects will be available on this blog soon.
First class MSBuild citizen
In the past, it was a little tricky to make NuGet work with MSBuild. In this release, we are shipping Restore and Pack as first class MSBuild targets. This will allow you to easily work with NuGet as you would with any task or target in MSBuild.
You can now produce packages directly from a project. For example, you can do
msbuild /t:pack in a project directory which would generate a NuGet package using the properties and metadata declared in the csproj file of the project.
In CI systems, you no longer need to download
nuget.exe and run
nuget restore to restore packages. You can now use
msbuild /t:restore to restore packages.
Background Package Restore
In the past, you had to perform a build or an explicit restore to restore NuGet packages. With NuGet 4.0, background package restore automatically downloads and adds or removes NuGet packages as you edit PackageReference and save your project files.
New commands in the .NET CLI
We have added new commands for the .NET CLI -
dotnet nuget locals,
dotnet nuget push, and
dotnet nuget delete.
dotnet nuget locals allows you to manipulate and work with the nuget caches on your machine.
dotnet nuget push / delete – enables pushing packages to or deleting packages from NuGet servers. Additionally,
dotnet restore and
dotnet pack now have the same behavior as MSBuild restore and MSBuild pack providing a consistent and reliable experience.
dotnet restore == msbuild /t:restore dotnet pack == msbuild /t:pack
The following are some performance improvements that you might notice with NuGet 4.0:
nuget update for UWP, WPF and other project.json based projects is now much faster. In our sample solution with 20 UWP projects, updating packages is 6 times faster than before. For
packages.config based projects,
nuget update is now about 20% faster.
nuget restore for UWP, WPF and other project.json based projects has been improved. In one of our sample projects, restore times have been reduced from about 3800ms to about 400ms.
nuget update/install for packages that have deep dependencies is now faster by an order of magnitude. For a sample scenario with 5 targets each having 20-30 deep dependency chains,
nuget update/install used to take about 10 mins to complete, compared to about 30ms now.
In .NET Core, tool restores have been optimized so that tool references are restored only once per solution instead of once for every project.
Default Location for the machine-wide NuGet.config
In Visual Studio 2017 and above, the machine-wide NuGet.config is located at
%ProgramFiles(x86)%\NuGet\Config\. Going forward, nuget.exe v4.0.0+ will also treat this as the new location for the machine-wide configuration. The primary driver for the change is to improve security in a multi-user scenario. Previously we would write to the
%ProgramData% folders which don’t require Admin privileges to modify.
%ProgramFiles(x86)% folders are protected and only users with Administrative privileges, or those granted permissions by an administrator can change their contents.
%ProgramData%\NuGet\Config\ will no longer be implicitly referenced or considered for hierarchical merging of
NuGet.config. This is only applicable if you were previously using machine-wide NuGet configuration files.
Solution - You must manually migrate existing config files from
We want to hear your feedback!
We want NuGet to meet the evolving needs of our community. If you would like to share your pain points, and your current or future needs, hit us up at email@example.com. You can also leave a comment below, and as always, if you run into any issues or have an idea, open an issue on GitHub.