In the NuGet 2.5 release, we added the MinClientVersion property to the package manifest schema to allow for a package to demand the minimum version of the NuGet client that can install it.
Because this feature was added in version 2.5, older versions of NuGet won’t be able to recognize it. Therefore, older clients will always refuse to install packages with the MinClientVersion property set, even if you set it to a value smaller than the version of the client.
For example, if you set MinClientVersion to 1.8, and the user tries to install your package with NuGet 2.2, the installation will fail even though 1.8 < 2.2. The user will see the following error message:
The schema version of ‘MyPackage’ is incompatible with version 126.96.36.199 of NuGet. Please upgrade NuGet to the latest version from http://go.microsoft.com/fwlink/?LinkId=213942.
In sum, this feature will grow in its utility over future NuGet iterations, starting with version 2.6
In the NuGet 2.5 release notes, we called out that NuGet now has support for native projects. We wanted to explain exactly what “support for native projects” means.
Visual Studio Support
Until NuGet 2.5, if you were working in a Visual C++ project, the ‘Manage NuGet Packages’ context menu would not show up for the project; with NuGet 2.5, we now light this up. Any time we start supporting a new project type, we have to test to ensure all operations are working as expected. Each project system has slightly different behavior and this proved to be true with Visual C++ as well. We made the changes necessary to get NuGet install/update/uninstall operations working.
C++ projects tend to have many different configurations–more than what NuGet is able to handle. To address NuGet’s configuration limitations, we are relying heavily on MSBuild properties and targets for native packages. These MSBuild properties and targets do the heavy lifting of providing references at build time, based on your project’s configuration.
To make MSBuild integration better, NuGet has created a new convention for automatically importing MSBuild properties and targets from a NuGet package. Alongside the existing \content, \lib, and \tools folders, NuGet now recognizes a new top-level folder: \build.
Within the \build folder, you can provide a “.props” file and/or a “.targets” file that will be automatically imported into the project. For this convention, the file name must match your package id with either a “.props” or “.targets” extension. For example, the ’cpprestsdk’ package includes a ‘cpprestsdk.targets’ file in its \build folder. Files with the “.props” extension will be imported at the top of the project file, and files with the “.targets” extension will be imported at the bottom of the project file.
Note that this \build folder can be used for all NuGet packages and not just native packages. The \build folder respects target frameworks just like the \content, \lib, and \tools folders do. This means you can create a \build\net40 folder and a \build\net45 folder and NuGet will import the appropriate props and targets files into the project. You no longer need to write PowerShell install.ps1/uninstall.ps1 scripts to import MSBuild targets files!
Native Target Framework
When targeting native projects, a new target framework name is now recognized: native. There is no versioning within the ‘native’ target framework; NuGet treats all C++ projects the same.
We expect that most native packages will be produced using the \build\native folder, with at least a targets file and then a props file if needed. The ‘native’ target framework is also recognized for the \content and \tools folders, but because NuGet cannot directly add references to native projects, the ‘native’ target framework is not recognized within the \lib folder.
Creating Native Packages
If you’re interested in publishing your native libraries via NuGet, you can choose to create the NuGet packages manually. However, there’s an easier way–the CoApp project volunteered to write C++ oriented tools to create NuGet packages, and they have released a beta version of their tools. These tools simplify the process of generating the MSBuild files and NuGet packages from existing header and library files–you just need to create a configuration script to describe the contents of the package and then run the tools to generate the NuGet package.
There are tutorials, reference documentation, and a video on how to use the tools to create NuGet packages. The CoApp project organizers also plan to create and publish packages for several open source libraries into the NuGet Gallery over the next several weeks.
We’re encouraging people to publish packages with the “native” tag to make it easier to find packages you can use in C++ projects. You can search the NuGet Gallery using “tag:native” to find packages tagged with “native”. This works from both nuget.org and within Visual Studio. Note that not all packages tagged with “native” are actually C++ projects though.
The CoApp and Openness@Microsoft blogs have additional information about this project.
Please leave us feedback here on the blog–we’d love to hear your experiences trying out NuGet in your C++ projects, and whether there are additional features we could add to make this work even better for you. This is just the start of C++ integration in NuGet and we need your input on where we should take this in the future to make working with C++ libraries in Visual Studio easier.
Download it now
NuGet was included in all editions of Visual Studio 2012 and it’s also available for Visual Studio 2010 through the Visual Studio Extension Manager. To get the latest version of NuGet installed in Visual Studio, either check for updates in the extension manager or download the latest version directly.
We would like to thank the following external contributors for their significant contributions to NuGet 2.5:
- Daniel Plaisted (dsplaisted) - Add MonoAndroid, MonoTouch, and MonoMac to the list of known target framework identifiers. #2847
- Andres G. Aragoneses (knocte) - Fix spelling of NuGet.targets for a case-sensitive OS #2865
- David Fowler (dfowler) - Make the solution build on Mono.
- Andrew Theken (atheken) - Fix unit tests failing on Mono.
- Olivier Dagenais (OliIsCool) - nuget.exe pack command does not propagate Properties to msbuild #2920
- Miroslav Bajtos (MiroslavBajtos) - Modified XML handling code to preserve formatting. #1511
- Adam Ralph (adamralph) - Added recognized words to custom dictionary to allow build.cmd to succeed.
- Bruno Roggeri (broggeri) - Fix unit tests when running in localized VS.
- Gareth Evans (garethevans) - Extracted interface from PackageService
- Maxime Brugidou (brugidou) - Handle project dependencies when packing #936
- Xavier Decoster (XavierDecoster) - Support Clear Text Password when storing package source credentials in nuget.cofig files #2991, #3164
We also appreciate the following individuals for finding bugs with NuGet 2.5 Beta/RC that were approved and fixed before the final release:
- Tony Wall (CodeChief) - MSTest broken with lastest NuGet 2.4 and 2.5 builds #3200
What’s Included in NuGet 2.5
This release was so big, we felt compelled to skip versions 2.3 and 2.4! To date, this is the largest release we’ve had for NuGet, with 169 work items in the release.
For details about what’s in the release, the release notes are published on docs.nuget.org.
Here are the most notable features:
- Allow users to overwrite content files that already exist
- Automatic import of msbuild targets and props files
- Specify different references per platform using element
- Update All button to allow updating all packages at once
- Improved project reference support for NuGet.exe Pack
- Add a ‘Minimum NuGet Version’ property to packages
- Dependencies are no longer unnecessarily updated during package installation
- NuGet.exe outputs http requests with detailed verbosity
- NuGet.exe push now supports UNC and directory sources
- NuGet.exe supports explicitly-specified Config files
- Support for Native projects
We’ve outgrown NuGet’s current description. According to nuget.org, we have the following description and slogan:
Jump Start Your Projects with NuGet
NuGet is a Visual Studio extension that makes it easy to install and update third-party libraries and tools in Visual Studio.
So install NuGet and get a jump on your next project!
We have come up with a new description for NuGet:
NuGet is the package manager for the Microsoft development platform including .NET. The NuGet client tools provide the ability to produce and consume packages. The NuGet Gallery (nuget.org) is the central package repository used by all package authors and consumers.
You can expect the home page at nuget.org to reflect this new description soon.