Saturday, April 27, 2013

Nuget 2.5 Released This Week!

Microsoft finally released Nuget 2.5 this week (Apr 25, 2013). It is a very big release with 160 work items. In February, we discussed about some of the challenges introducing Nugets in an enterprise world. They included using nuget packages in an enterprise world and hosting internal nuget feeds. The release is a good news for native developers as the realase added support for C \ C++ projects. You can see the announcement on CoApp site where they announced CoApp power shell tools for Nuget 2.5. The tool was also released yesterday.

A new version of Nuget Package Explorer has also been released yesterday. The click once download is available here:

The new version of the explorer is released to be compatible with this release of Nuget [2.5]. There are still some features which are still not supported in the explorer including .net framework version specific references.

We can easily divide the released features as the improvements for packages clients and authors. There are various improvements for packages clients. The most obvious improvement which you would notice is the ability to update all packages which are already installed. Please notice the Update All button in the dialog to manage nuget packages.

As a package author, we can now enforce Nuget version on client machines before they install your package. This would make sure that clients have enough support for the features our packages are based on. Obviously this feature would be usable by the nuget clients 2.5 and above as the earlier clients don't know how to handle this metadata attribute. The attribute can be added as follows:

Installing Nuget package with requirement for higher version of Nuget would result in an error. In Visual Studio, it would show you the option to upgrade Nuget version. This would open the dialog for extension and updates in Visual Studio listing the available updates.

If you have earlier version of Nuget supporting previous versions of Nuspec, the package is shown in Manage Nuget Package dialog as follows:

The similar error message is available when package list is requested using Package Manager console (Get-Package -ListAvailable).

We cannot install such a package using Manage Nuget Pacakge Dialog.Installing such a package using Package Manager Console would also result in the following error message:

In the previous versions of Nuget, we could limit the assemblies to be added to target project's assembly references. The filtered list must be part of the assemblies in the lib folder or one of its framework specific sub-folder. Let's assume we had these two libraries in v4.5 folder for our package.

By default, if a client is adding this package, both of these assemblies would be referenced by the client project. If we need to reference only a filtered set of assemblies from the source set we can include the list in the nugetspec for the package. This would still copy all the assemblies to the packages folder.

This should allow you to include the assemblies that are dependent on some other assemblies where you don't want the types from these assemblies to be directly used by the client code.

Nuget 2.5 allows to define this filter based on the client's target project. This has been provided by including framework specific groups in the nuspec. We can also include a framework independent group as a fallback mechanism when our package is referenced by an unidentified framework version.

File Overwrite Option for Package Installation
A new option has been added for package installation to give the user an option to overwrite an existing file or keep the copy of the content already present. Please notice FileConflictAction with Install-Pacakge command. Here we are installing MyPackage while selecting to overwrite contents already present. The options are Overwrite and Ignore.

Installing package with Manage Nuget Packages dialog would give you an option to overwrite or ignore the content.

Import for MSBuild targets and props files
A new build folder is now supported at the root level in a package. The folder supports framework specific sub-folders. The build folder contains targets and props files. When a package is added to a target project, it would add <Import> in project file.

Please notice how these <Import> elements are added to the project definition. The element for build is added to the top of the project file.

The element for props file is added to the top of project definition as follows:

You can find further details about it from the release documentation available here:

No comments: