NuGet 6.3 is included in Visual Studio 2022 and .NET 6.0 out of the box. You can also download NuGet 6.3 for Windows, macOS, and Linux as a standalone executable.
NuGet 6.3 is one of many releases in our .NET unification journey. Our NuGet tooling helps developers discover new .NET packages to use for their .NET applications, while making package management easier during your daily development.
NuGet 6.3 Highlights
There are many new features in NuGet 6.3:
- Consume pdbs from packages in PackageReference.
- View transitive dependencies in Visual Studio.
- New warnings when duplicate
PackageReference
,PackageVersion
, orPackageDownload
are found. - Install packages with custom floating versions in Visual Studio.
- Re-enable signed package verification on Linux by default.
- HTTPS everywhere.
Consume pdbs from packages in PackageReference
For any given assembly under lib
and runtime
folder from a <PackageReference>
, if there are files next to it that differ only by the extension, NuGet will now add a related
property underneath the assembly in the targets section of the assets file, listing the extensions of these files, separated by ;
.
"lib/netstandard2.0/Newtonsoft.Json.dll": {
"related": [".pdb", ".xml"]
}
This feature allows you and the .NET SDK to consume .pdb
and .xml
files alongside the assembly for <PackageReference>
for scenarios like debugging and API documentation. While the work is completed in the 6.3 release, you will likely not see any benefit until the .NET SDK becomes aware of this functionality in a future release.
View transitive dependencies in Visual Studio
There is now a new dependency section labeled “transitive packages” that you can optionally collapse or expand depending on your daily use.
You can click on the dependencies like you would your top-level dependencies and even promote any transitive dependency to a top-level dependency at any time. One such reason might be overriding a resolved version to an unaffected version of a library that has a known vulnerability until a patch has been released.
Lastly, you can hover over any transitive dependency to understand the top-level dependencies that brought it into your project.
This is currently an experiment in Visual Studio 17.3 where you can read more about the feature in our blog Introducing Transitive Dependencies in Visual Studio.
New warnings when duplicate PackageReference
, PackageVersion
, or PackageDownload
are found
Whenever you include a duplicate PackageReference
, PackageVersion
, or PackageDownload
item, you will be provided a new NuGet warning such as:
NU1504
– Duplicate ‘PackageReference’ items found. Remove the duplicate items or use the Update functionality to ensure a consistent restore behavior. The duplicate ‘PackageReference’ items are: X 1.0.0, X 2.0.0.NU1505
– Duplicate ‘PackageDownload’ items found. Remove the duplicate items or use the Update functionality to ensure a consistent restore behavior. The duplicate ‘PackageDownload’ items are: X [1.0.0], X [2.0.0].NU1506
– Duplicate ‘PackageVersion’ items found. Remove the duplicate items or use the Update functionality to ensure a consistent restore behavior. The duplicate ‘PackageVersion’ items are: X [1.0.0], X [2.0.0].
Install packages with custom floating versions in Visual Studio
You can now install custom versions of packages with floating version syntax.
Re-enable signed package verification on Linux by default
Signed NuGet package verification will be enabled by default in .NET 7 SDK Linux builds, starting with RC1.
It is opt-in for .NET 7 Preview 7 and .NET 6 SDK (6.0.400) builds. However, we have enabled it (via an environment variable) with .NET 6 SDK container images with .NET SDK 6.0.400 (released August 9th, 2022). It will be enabled for .NET 7 SDK container images with .NET 7 RC1.
You can opt-in to the feature with the following environment variable, set to true
:
DOTNET_NUGET_SIGNATURE_VERIFICATION=true
With .NET 7 RC1+, you can use the same environment variable to opt-out. We have not decided how long we will retain the ability to opt-out. If you need to use it, we would appreciate feedback on why you needed to do that. It might be an issue we need to address.
For more information on this topic, see Signed NuGet Package Verification Re-enabled for Linux
HTTPS everywhere
As an ongoing effort to make HTTPS everywhere a reality for NuGet, we have taken a number of steps to help protect your everyday package management experiences.
We have introduced a new NU1803 warning that will let you know that you’re using a non-HTTPS source.
For more information about this topic, see our blog HTTPS everywhere
Closing
NuGet 6.3 is a big release that should improve many aspects of your daily package management needs. We’ve added a few new features to Visual Studio to help you manage and install dependencies, improved warning experiences of duplicate items, and re-enabled package verification on Linux.
We’re excited to see you use NuGet 6.3 & include it in your toolset for building amazing things with .NET.
For more details on NuGet 6.3, see our official release notes.
Feedback
Your feedback is important to us. If there are any problems with this release, check our GitHub Issues and Visual Studio Developer Community for existing issues. For new issues within NuGet, please report a GitHub Issue. For general NuGet experience issues, let us know via the Report a Problem option found in your favorite IDE under Help > Report a Problem
.
To be honest "re-enable signed package verification on Linux by default" is a terrible thing to suddenly inflict on the unsuspecting developer, especially in a not-major version release. I just spend an entire day trying to figure out why my CI pipeline suddenly went from taking less than two minutes to restore packages to timing out after an hour.
My setup is as follows:
I figure the reason for the overall failure is, that for each package...
How about multi target framework support? If I target both net framework and net I cannot update nugets that support net at higher version and that are consumed in framework up to lower version of that nuget.
But why?
I’m confused about “Consume pdbs from packages in PackageReference”. What is exactly is benefit? .xml and .pdb files are copied from nuget packages if they exist to for debugging/documentation. Can someone explain what this new feature is?
You can read more about this issue here:
https://github.com/NuGet/Home/issues/5926
I am really surprised, I did not realize this was an issue. I can see now pdb files are not copied to bin folder like I thought. Also confirmed symbol loader was not able to find symbols. Seems like this would have been documented somewhere. Not sure if issue also exist for snupkg. I'm guessing embedded pdb works. symbol server works for sure. so basically any nuget package...
I don’t know that the link really clarifies what this means though. Currently because of the SDK “bug” we have to use an additional NuGet package
SourceLink.CopyPdbFiles
to get the PDBs into the NuGet package so they can be used by consumers. Does this fix eliminate the need for that or what?We don’t want floating support, we want allowedVersions from packages.config in “PackageReference Include”
PackageReference has version ranges & floating versions you can use:
https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#references-in-project-files-packagereference
How can we make this better?
this picks automatically newer versions in the range, I want to specify the version on my own. I always test nuget updates and commit them on my own to avoid broken builds. There is already a github ticket where several users requested it. In a dotnet 3.1 app I only want 3.1 nugets, but VS PM UI always shows me 6.0.x updates, so I have to use text editor to search & replace nuget versions
this is main reason I want this to. For 3.1 apps to maintain 3.1.x extension packages. soon will have issue with .net6 wanting to pull net7 packages once released. should be way to keep these in sync
Same here. I still see lots of incompatible 6.0.x package updates for my net5.0 app in VS PM UI. Fix this finally, please.
yes and later this year same happens with .net 7. We ship updates to migrate our apps from 3.1 to 6.0 in October. Here updating will be pain again as PM UI now shows 7.0.x nuget updates in November when 7.0 is final. We only build against LTS versions and ignore 7, we only do test branches to fix breaking changes compared to last LTS and later migrate to .net 8 as next LTS.
That would be nice feature.