Announcing NuGet 6.3 – Transitive Dependencies, Floating Versions, and Re-enabling Signed Package Verification

Jon Douglas

Nikolche Kolev

August 9th, 202214 0

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

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.

Image TransitiveDependencies

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.

Image TransitiveDependenciesDetails

Lastly, you can hover over any transitive dependency to understand the top-level dependencies that brought it into your project.

Image TransitiveDependenciesHover

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.

Image FloatingVersions

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.

Jon Douglas Principal Program Manager, NuGet

Nikolche Kolev Senior Software Engineer, NuGet

Read next

14 comments

Comments are closed. Login to edit/delete your existing comments

  • André Ziegler 0

    We don’t want floating support, we want allowedVersions from packages.config in “PackageReference Include”

    • Christopher Mire 0

      That would be nice feature.

      • André Ziegler 0

        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

        • Alexey Leonovich 0

          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.

          • André Ziegler 0

            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.

        • Christopher Mire 0

          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

  • Christopher Mire 0

    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?

      • Michael Taylor 0

        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?

      • Christopher Mire 0

        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 included xml or pdb is kind of pointless, unless user manually loads it?

  • Pavel Voronin 0

    Centrally defined floating package versions are not allowed.

    But why?

  • Lior Banai 0

    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.

  • Enenkel, Peter 0

    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:

    • The dotnet restore (and build) is done inside a multistage docker image
      based on the standard .NET SDK image.
    • The pipeline is DevOps based and utilizes self-hosted and network
      isolated agents (i.e. without access to arbitrary internet addresses)
    • Nuget packages are loaded from a custom Azure Artifacts feed (thus the agents only require network access to that)

    I figure the reason for the overall failure is, that for each package an attempt is made to contact the “signature authority”. As this connection is not allowed by the network it times out. Multiply that by a 100 packages and one can easily see how that might blow up the overall time.

    I thought that this kind of setup is not too uncommon in corporate environments.

Feedback usabilla icon