NuGet 1.4 introduces a lot of improvements to the Update-Package command making it easier to keep packages at the same version across multiple projects in a solution. For example, when upgrading a package to the latest version, it's very common to want all projects with that package installed to be updated to the same verision.
Update-Package command now makes it easier to:
Update-Package -Project MvcApplication1
-Safe flag constrains upgrades to only versions with the same Major and Minor version component. For example,
if version 1.0.0 of a package is installed, and versions 1.0.1, 1.0.2, and 1.1 are available in the feed, the
flag updates the package to 1.0.2. Upgrading without the
-Safe flag would upgrade the package to the latest version,
Prior to NuGet 1.4, installing a package into multiple projects was cumbersome using the dialog. It required launching the dialog once per project.
NuGet 1.4 adds support for installing/uninstalling/updating packages in multiple projects at the same time. Simply launch the by right clicking the Solution and selecting the Manage NuGet Packages menu option.
Notice that in the title bar of the dialog, the name of the solution is displayed, not the name of a project. Package operations now provide a list of checkboxes with the list of projects the operation should apply to.
For more details, see the topic on Managing Packages for the Solution.
By default, when running the
Update-Package command on a package (or updating the package using dialog), it will be
updated to the latest version in the feed. With the new support for updating all packages, there may be cases in which
you want to lock a package to a specific version range. For example, you may know in advance that your application will
only work with version 2.* of a package, but not 3.0 and above. In order to prevent accidentally updating the package to
3, NuGet 1.4 adds support for constraining the range of versions that packages can be upgraded to by hand editing the
packages.config file using the new
For example, the following example shows how to lock the
SomePackage package the version range 2.0 - 3.0 (exclusive).
allowedVersions attribute accepts values using the version range format.
<?xml version="1.0" encoding="utf-8"?> <packages> <package id="SomePackage" version="2.1.0" allowedVersions="[2.0, 3.0)" /> </packages>
Note that in 1.4, locking a package to a specific version range must be hand-edited. In NuGet 1.5 we plan to add support for placing this
range via the
The new package visualizer, launched via the Tools -> Library Package Manager -> Package Visualizer menu option, enables you to easily visualize all the projects and their package dependencies within a solution.
Important Note: This feature takes advantage of the DGML support in Visual Studio. Creating the visualization is only supported in Visual Studio Ultimate. Viewing a DGML diagram is only supported in Visual Studio Premium or Higher.
See the documentation on the Package Visualizer for more details.
Some versions of NuGet introduce new features expressed via the NuSpec file which are not understood by older versions of the NuGet dialog. One example is the introduction in NuGet 1.4 for specifying framework assemblies. Because of this, it's important to use the latest version of NuGet to ensure you can use packages taking advantage of the latest features. To make updates to NuGet more visible, the NuGet dialog contains logic to highlight when a newer version is available.
Note: The check is only made if the Online tab has been selected in the current session.
To turn off the automatic check for updates, go to the NuGet settings dialog and uncheck Automatically check for updates.
This feature was actually added in NuGet 1.3, but would not be visible, of course, until an update to 1.3, such as NuGet 1.4, was made available.
-Symbolsflag can be applied to a normal convention based folder structure creating a symbols package by only including the source and pdb files within the folder.
NuGet installcommand supports specifying multiple sources using semi-colons as a delimiter or by specifying
-Selfflag is now required for NuGet.exe to update itself.
NuGet.exe Updatenow takes in a path to the
packages.configfile and will attempt to update packages. Note that this update is limited in that it will not: * Update, add, remove content in the project file. * Run Powershell scripts within the package.
NuGet includes a simple way to host a lightweight web based NuGet repository
NuGet.Server NuGet package. With NuGet 1.4, the lightweight server supports pushing and deleting packages using NuGet.exe.
The latest version of
NuGet.Server adds a new
apiKey. When the key is omitted or left blank, pushing packages
to the feed is disabled. Setting the apiKey to a value (ideally a strong password) enables pushing packages using NuGet.exe.
<appSettings> <!-- Set the value here to allow people to push/delete packages from the server. NOTE: This is a shared key (password) for all users. --> <add key="apiKey" value="" /> </appSettings>
NuGet is now supported in the release candidate version of Windows Phone Tools for Mango. Currently, Windows Phone Tools does not have support for the Visual Studio Extension manager so to install NuGet for Windows Phone Tools, you may need to download and run the VSIX manually.
To uninstall NuGet for Windows Phone Tools, run the following command.
NuGet 1.4 had a total of 88 work items fixed. 71 of those were marked as bugs.
For a full list of work items fixed in NuGet 1.4, please view the NuGet Issue Tracker for this release.
NuGet Pack SomeProject.csprojto post-build event no longer causes an infinite loop.
-Sourceflag supports relative paths.
Shortly after the release of NuGet 1.4, we found a couple of issues that were important to fix. The specific version number of this update to 1.4 is 1.4.20615.9020.