We would like to thank the following external contributors for their significant contributions to NuGet 2.7:
NuGet 2.7 introduces a new approach to package restore, and also overcomes a major hurdle: Package restore consent is now on by default! The combination of the new approach and the implicit consent will drastically simplify package restore scenarios.
With NuGet versions 2.0, 2.1, 2.2, 2.5, and 2.6, users needed to explicitly allow NuGet to download missing packages during build. If this consent had not been explicitly given, then solutions that had enabled package restore would fail to build until the user had granted consent.
Starting with NuGet 2.7, package restore consent is ON by default while allowing users to explicitly opt out of package restore if desired, using the checkbox in NuGet's settings in Visual Studio. This change for implicit consent affects NuGet in the following environments:
Starting with NuGet 2.7, NuGet will automatically download missing packages during build in Visual Studio, even if package restore hasn't been explicitly enabled for the solution. This automatic package restore happens in Visual Studio when you build a project or the solution, but before MSBuild is invoked. This yields a few significant benefits:
In order to use Automatic Package Restore in Visual Studio, you only need to take one (in)action:
While all users are implicitly opted into automatic package restore consent, you can easily opt out through the Package Manager settings in Visual Studio.
NuGet 2.7 introduces a new feature for nuget.exe:
This new Restore command allows you to easily restore all packages for a solution with a single command, by accepting a solution file or folder as an argument. Furthermore, that argument is implied when there's only a single solution in the current folder. That means the following all work from a folder that contains a single solution file (MySolution.sln):
The Restore command will open the solution file and find all projects within the solution. From there, it will find the packages.config files for each of the projects and restore all of the packages found. It also restores solution-level packages found in the .nuget\packages.config file. More information about the new Restore command can be found in the Command-Line Reference.
We are excited about these changes to Package Restore, as it introduces a new workflow. If you want to omit your packages from source control you simply don't commit the
packages folder. Visual Studio users who open and build the solution will see the packages automatically restored. For command-line builds, simply invoke
nuget.exe restore before invoking
msbuild. You'll no longer need to remember to use the "Enable NuGet Package Restore" gesture on your solution, and we'll no longer need to modify your projects to alter the build. And this also yields a much improved experience for packages that include MSBuild imports, especially for imports added through NuGet's recent feature for automatically importing props/targets files from the \build folder.
In addition to the work we've done ourselves, we're also working with some important partners to round this new approach out. We don't have concrete timelines for any of these yet, but each partner is as excited as we are about the new approach.
nuget.exe restoreinto the default build scenarios.
nuget.exe restorecalled before your web site is built.
nuget.exe restorecalled before your solution is build.
With each of the partners above, they would use their own copy of nuget.exe and you would not need to carry nuget.exe in your solution.
There were two known issues with nuget.exe restore with the initial 2.7 release, but they were fixed on 9/6/2013 with an update to the NuGet.CommandLine package. This update is also available on the NuGet 2.7 download page on CodePlex. Running
nuget.exe update -self will update to the latest release.
The fixed were:
There is also a known issue with the new package restore workflow whereby automatic package restore does not work for projects under a solution folder. This issue was fixed in NuGet 2.7.1.
Many times after retargeting or upgrading your project, you find that some NuGet packages aren't functioning properly. Unfortunately, there is no indication of this and then there's no guidance on how to address it. With NuGet 2.7, we now use some Visual Studio events to recognize when you've retargeted or upgraded your project in a way that affects your installed NuGet packages.
If we detect that any of your packages were affected by the retargeting or upgrade, we'll produce immediate build errors to let you know. In addition to the immediate build error, we also persist a
requireReinstallation="true" flag in your packages.config file for all packages that were affected by the retargeting, and each subsequent build in Visual Studio will raise a build warnings for those packages.
While NuGet cannot take automatic action to reinstall affected packages, we hope this indication and warning will guide help you discover when you need to reinstall packages. We are also working on package reinstallation guidance documentation that these error messages direct you to.
Many companies are using NuGet internally, but have had a hard time guiding their developers to use internal package sources instead of nuget.org. NuGet 2.7 introduces a Configuration Defaults feature that allows machine-wide defaults to be specified for:
Each of these can now be configured within a file located at %ProgramData%\NuGet\NuGetDefaults.config. If this config file specifies package sources, then the default nuget.org package source will not be registered automatically, and the ones in NuGetDefaults.config will be registered instead.
While not required to use this feature, we expect companies to deploy NuGetDefaults.config files using Group Policy.
Note that this feature will never cause a package source to be removed from a developer's NuGet settings. That means if the developer has already used NuGet and therefore has the nuget.org package source registered, it won't be removed after the creation of a NuGetDefaults.config file.
See NuGet Configuration Defaults for more information about this feature.
NuGet has always registered a default package source called "NuGet official package source" that points to nuget.org. That name was verbose and it also didn't specify where it was actually pointing. To address those two issues, we've renamed this package source to simply "nuget.org" in the UI. The URL for the package source was also changed to include the "www." prefix. After using NuGet 2.7, your existing "NuGet official package source" will automatically be updated to "nuget.org" as its name and "https://www.nuget.org/api/v2/" as its URL.
We made some performance improvement in 2.7 which will yield smaller memory footprint, less disk usage and faster package installation. We also made smarter queries to OData-based feeds which will reduce the overall payload.
We added some new APIs to our extensibility services to fill the gap of missing functionalities in previous releases.
// Checks if a NuGet package with the specified Id and version is installed in the specified project. bool IsPackageInstalledEx(Project project, string id, string versionString); // Get the list of NuGet packages installed in the specified project. IEnumerable<IVsPackageMetadata> GetInstalledPackages(Project project);
// Installs one or more packages that exist on disk in a folder defined in the registry. void InstallPackagesFromRegistryRepository(string keyName, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions); // Installs one or more packages that are embedded in a Visual Studio Extension Package. void InstallPackagesFromVSExtensionRepository(string extensionId, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);
This feature was contributed by Adam Ralph and it allows package authors to declare dependencies that were only used at development time and don't require package dependencies. By adding a
developmentDependency="true" attribute to a package in packages.config, nuget.exe pack will no longer include that package as a dependency.
The new package restore model in 2.7 is implemented by a new VSPackage which is different from the main NuGet VSPackage. Due to a technical issue, this new VSPackage doesn’t work correctly in the Visual Studio 2010 Express for Windows Phone SKU as we share the same code base with other supported Visual Studio SKUs. Therefore, starting with NuGet 2.7, we are dropping support for Visual Studio 2010 Express for Windows Phone from the published extension. Support for Visual Studio 2010 Express for Web is still included in the primary extension published to the Visual Studio Extension Gallery.
Since we are unsure how many developers are still using NuGet in that version/edition of Visual Studio, we are publishing a separate Visual Studio extension specifically for those users and publishing it on CodePlex (rather than the Visual Studio Extension Gallery). We don't plan to continue to maintain that extension, but if this affects you please let us know by filing an issue on CodePlex.
To download the NuGet Package Manager (for Visual Studio 2010 Express for Windows Phone), visit the NuGet 2.7 Downloads page.
In addition to these features, this release of NuGet also includes many other bug fixes. There were 97 total issues addressed in the release. For a full list of work items fixed in NuGet 2.7, please view the NuGet Issue Tracker for this release.