2.5 Feature details:
The ability to specify different references per platform using <References/> element in .nuspec file
Before 2.5, in .nuspec file, user can only specify the reference files, to be added for all framework. Now with this new feature in 2.5, user can author the <reference/> element for each of the supported platform, for example:
<reference file="a.dll" />
<reference file="b.dll" />
<reference file="c.dll" />
And here is the flow how NuGet add references to projects based on the .nuspec file:
- Find the lib folder that is appropriate for the target framework and get the list of assemblies from that folder
- Separately find the references group that is appropriate for the target framework and get the list of assemblies from that group. Reference group without target framework specified is the fallback group.
- Find the intersection of the two lists, and use that as the references to add
This new feature will allow package authors to use the References feature to apply subsets of assemblies to different frameworks when they would otherwise need to carry duplicate assemblies in multiple lib folders.
Note: you would have to use NuGet.exe pack to use this feature, NuGetPackageExplorer pre-release version might not support it yet.
Enable package to import .targets or .props file into project & enable support for Native packages
Sample package dependency
Following are details from dotnetjunly on how this works:
2.5 adds the ability for NuGet to import MSBuild-based .targets and .props files into the project.
For this feature, new top-level folder is introduced, build, in addition to content, lib and tools. Under this folder, you can place two files with fixed names, <package id>.targets or <package id>.props. These two files can be either directly under
\build or under framework-specific folders just like the other folders. The rule for picking the best-matched framework folder is exactly the same as in those.
When NuGet installs a package with \build content, it will add an <Import> element in the project file pointing to the .targets and .props files. The .props file is added at the top, whereas the .targets file is added to the bottom.
Added Update All button in the dialog to allow updating all packages with one click
Update all feature now allows you to update all the available updates in single shot.
1. Create new mvc application
2. Launch manage NuGet package dialog by right clicking the project or the solution
3. Select updates and click update all
When building a package from a project, when -IncludeReferencedProjects is specified, projects referenced by the project are either added as a dependency of the package, if nuspec file exists, or are added into the package if nuspec file doesn't exist.
Now nuget.exe pack command processes referenced projects with the following rules:
- if the referenced project has corresponding nuspec file, e.g. there is a file called proj1.nuspec in the same directory as proj1.csproj, then this project is added as a dependency to the package, using the id and version read from the nuspec file.
- Otherwise, the files of the referenced project are added to the package. Then projects referenced by this project will be processed using the sames rules recursively.
- All dlls/pdb/exe files are added.
- All other content files are added.
- All dependencies are merged.
So basically, a referenced project is treated as a dependency if there is nuspec file, otherwise, it becomes part of the package.
More details here http://nuget.codeplex.com/workitem/936
Add the 'minClientVersion' attribute to manifest schema to allow packages to require minimum version of NuGet & added -minClientVersion argument to the nuget.exe pack command
This feature helps package author to specify that his/her package would work only after a particular version of NuGet.
For example, portable library support was added in NuGet 2.2 If you want to specify that my package would only install if the user has NuGet version >= 2.2, you can specify it in nuspec file like this
You can also pass minClientVersion to NuGet.exe pack command to have it added in the resultant nupkg file.
NuGet won't update a dependency package if the installed version already satisfies the constraint of dependency version
Following are details from @dotnetjunky
The source repository contains package B with version 1.0.0 and 1.0.2. It also contains package A which has a dependency on B (>= 1.0.0).
Assume that the current project already has package B version 1.0.0 installed. Now you want to install package A.
In NuGet 2.2 and before:
When installing package A, NuGet will auto-update B to 1.0.2, even though the existing version 1.0.0 already satisfies the dependency version constraint, which is >= 1.0.0.
From NuGet 2.5
From 2.5, NuGet will no longer update B, because it detects that the existing version 1.0.0 satisfies the dependency version constraint.
Here's the bug which prompted this design change http://nuget.codeplex.com/workitem/1681. We believe this will result in less undesired situations in which upgraded packages cause incompatibilities with other packages in the same project.
Discussion thread here http://nuget.codeplex.com/discussions/436712
Nuget.exe outputs the http requests it is making when -Verbosity is set to detailed
Nuget.exe outputs the http requests it is making when -Verbosity is set to detailed.
Add support for UNC and directory path as source for push and delete commands
NuGet.exe now supports push to UNC
NuGet.exe push -Source \\mycompany\repo\ mypackage.nupkg
Allow users to overwrite files if there's a file conflict in package and project
NuGet Visual Studio Extension, NuGet.exe and Powershell Console now prompts you for overwriting file
NuGet.exe update and Install-Package now has a new option -FileConflictAction to set some defaults from commandline for CI scenarios.
Set default action when a file from a package already exists i n the target project. Set to Overwrite to always overwrite files. Set to Ignore to skip files. If not specified, it will prompt for each conflicting file.
Add to all commands new option -ConfigFile, which enables user to use his/her own config file instead of the default one %AppData%\nuget\nuget.config
nuget.exe sources add -name test -source http://test -ConfigFile c:\.nuget\nuget.config
You can try out NuGet Gallery features on NuGet
List of NuGet Gallery features added for the next release can be found
Click here to go Back to Community testing initiative page