Announcing NuGet 4.0 RC

NuGet 4.0 RC for Visual Studio 2017 is focused on adding support for .NET Core scenarios, addressing key customer feedback and improving performance in a variety of scenarios. This release brings several improvements like support for PackageReference, NuGet commands as MSBuild targets, background package restore, and more.

This post gives an overview of the new features and improvements available in NuGet 4.0 RC.

Downloads

NuGet.exe 4.0 RC will be available for download very soon. This blog post will be updated and we’ll tweet about it at that time.

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.

NuGet has grown to be a core part of the Visual Studio environment, and going forward, we want to treat NuGet just like any other platform component and maintain a high bar for quality and compatibility. With rapid Visual Studio releases, we will continue to bring new experiences and improvements to you quickly. You can continue to get Preview builds of NuGet if you have opted into the NuGet beta channel.

The NuGet 4.0 Package Manager Extension is currently not available for Visual Studio 2015. We will send out an update when it is made available. Since NuGet 4.0 builds upon several new features and bug fixes in Visual Studio 2017, not all NuGet 4.0 features will be available in Visual Studio 2015.

New Features

PackageReference

PackageReference will be the standard way to manage NuGet dependencies across all project types. With NuGet 4.0 RC, PackageReference is fully supported for .NET Core. 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</Version>
    </PackageReference>
...
</ItemGroup>

In NuGet 4.0 RTM that will coincide with Visual Studio 2017 RTM, we aim to fully support PackageReference for other project types such as WinForms, Windows Presentation Foundation (WPF), and Universal Windows Platform (UWP).

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 build 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

Performance Improvements

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, it now takes about 1.2 mins for updating packages, where previously it would have taken about 7.5 mins to update 3 packages. 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, 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.

Breaking Changes

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.

  • Impact - NuGet.config in %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 %ProgramData% to %ProgramFiles(x86)%

Release Notes

4.0 RC

Issues List

Issues fixed in 4.0 RC can be found here and here

What’s Next

The team is going to focus on finalizing .NET Core support, enabling PackageReference support for all project types, and making further improvements to the performance and quality of the product.

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 feedback@nuget.org. 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.

Published November 21, 2016 by Karan Nandwani

Announcing NuGet 3.5 RTM

NuGet 3.5 RTM for Visual Studio 2015 and nuget.exe provide quality improvements, performance improvements, features and new target frameworks like netstandard and netcoreapp.

Downloads

All NuGet downloads are available on https://nuget.org/downloads. NuGet.exe 3.5 RTM is not marked as the latest yet in the download page or uploaded as a package, so your version of NuGet.exe will not update to 3.5 RTM if you are using the update -self switch. Over the next few weeks once we get some more real world usage of the tools, we will make this change. This blog post will be updated and tweet will be sent out at that time.

Note: nuget.exe /update -self will not work for a few more days until we push nuget.commandline to nuget.org

No Auto Update

Going forward, for the near future, we will not be automatically updating the NuGet Package Manager Extension in Visual Studio 2015. Instead users will have to download the extension from our downloads page to update their NuGet extension. This maintains stability and consistent behavior in stable versions of Visual Studio 2015.

You can opt in to auto update or notifications from the gallery by using the beta channel, see details here.

New Features

Support for new Target Frameworks

.NET Standard and Net Core App TFM support is now available in 3.5 (since RC) and supports netstandard1.6 TFM for Visual Studio 2015 users. .NET Standard provides a more concrete guarantee of binary portability to future .NET-capable platforms with an easier-to-understand platform versioning plan.

PackageType

We have started to lay the groundwork to support a new PackageType property in the nuspec. This property allows package authors to classify their packages (E.g Dependencies, Tools etc..). More information on this is available in the PackageType spec here.

MinClientVersion support in project.json

Project.json now supports MinClientVersion. Packages.config scenarios allowed a package to define a required min version of client it can work with. This now works in project.json scenarios as well. You can now version packages that depend on newer NuGet versions so that you can prevent users from running into issues while trying to install packages using older versions of NuGet.

Performance Improvements

The key performance scenarios we have improved are Restore, Package Manager Console Load and Updating packages.

Here are a few examples:

  • Restore times in portable apps deployed through Kudu was reduced from over 15 secs to 3 secs.

  • Package Manager Console Load in large solutions are now much faster. In one of our sample projects it reduced from over 132s to 10s.

  • Package Updates in Visual Studio with ReSharper installed has been significantly improved. In our tests we have seen it drop from over 140 secs to 68 secs. We working together with the resharper team on further improvements that require code changes on both sides.

Better Mono Compatibility

The team has invested in improving compatibility of NuGet.exe and packages with Mono by rolling out a new CI pipeline dedicated to verifying our changes and builds on Mono. We have fixed several issues that were identified during our testing and continue to investigate and fix remaining issues in the next versions of NuGet and Mono.

SemVer 2.0.0 Client Support

You can now create and publish SemVer 2.0.0 compatible packages using the NuGet Client. This enables the community to create and publish SemVer 2.0.0 compliant packages to their own repositories. We are working on adding support for SemVer 2.0.0 to NuGet.Server and NuGet.org, and this will be made available in a future release.

Release Notes

3.5 RTM

Issues List

3.5 RTM

What’s Next

The team is continuning to focus on transitioning .NET CLI from project.json into MSBuild and and further investments in performance and quality of the product.

We want to hear your feedback!

We want NuGet to meet the evolving needs of our community. If you would like share your pain points and your current and future needs, hit us up at feedback@nuget.org. 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.

Published October 27, 2016 by Harikrishna Menon

New experience for NuGet Documentation

Last month, we launched a preview of the revamped Nuget docs experience. We made a number of improvements:

  1. New quick-starts for creating and consuming packages.
  2. End to end guides for new platforms such as .NET Standard and UWP.
  3. A simpler and more intuitive organization of topics.
  4. Left pane of contents serves as an index and allows you to glance at all topics.
  5. Cross-references with links to recommended reading, related topics and reference docs.
  6. A modern look and feel to the docs site.

We would like to thank you for trying out the preview and giving us valuable feedback. We have incorporated your feedback and ironed out some wrinkles we found along the way. Today, we are going live with the new experience on docs.nuget.org.

Will my existing references to documentation break?

Existing references should still work. We have updated the old docs with permanent redirects which will redirect you to the new page. If you find a broken reference, please open an issue on our GitHub repo and we’ll work to get it fixed.

How can I contribute?

Every page that allows contribution has an obvious “Edit in Github” link at the top. This link will you take you to the md file. Feel free to make changes and create a PR from your branch. The NuGet team will review the change and work with you to get it merged.

If you would like to raise a request for new docs or changes to existing docs, feel free to open a new issue.

What’s next?

Over the next few weeks, we will continue to make more improvements to the docs with respect to content and organization. In addition, we are considering starting our docs migration into docs.microsoft.com in the coming months. Since NuGet is an integral part of the .NET Ecosystem, this move will make it easier to find and navigate our documentation. Moreover, we’ll have a consistent way to get feedback and enable contributions to docs from our users.

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 and future needs, use the calendly link to set up a quick 15-30 min call with us. If you would like to send us an email instead, hit us up at feedback@nuget.org.

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.

Published September 20, 2016 by Karan Nandwani

Older Posts