Announcing NuGet 6.4 – Signed, Central, Delivered

Jon Douglas

Nikolche Kolev

November 8th, 202214 2

NuGet 6.4 is included in Visual Studio 2022 and .NET 7.0 out of the box. You can also download NuGet 6.4 for Windows, macOS, and Linux as a standalone executable.

NuGet 6.4 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.4 Highlights

There are many new features in NuGet 6.4:

Central Package Management is production ready

Earlier this year, we announced Central Package Management which is a feature to help you manage dependencies for multi-project solutions. Over the last couple releases, we’ve been busy fixing bugs preventing you from using it and adding features that improve your experience using it. This feature is now considered production ready and we’ve removed all mention of the feature being in a “preview” status.

To learn more, check out our docs on Central Package Management.

Use a single PackageReference everywhere with GlobalPackageReference

A new feature to central package management is <GlobalPackageReference>. A global package reference is used to specify that a package will be used by every project in a repository. This includes packages that do versioning, extend your build, or any other package that is needed by all projects. Global package references are added to the <PackageReference> item group with the following metadata implicitly:

  • IncludeAssets="Runtime;Build;Native;contentFiles;Analyzers" – This ensures that the package is only used as a development dependency and prevents any compile-time assembly references.
  • PrivateAssets="All" – This prevents global package references from being picked up by downstream dependencies.

<GlobalPackageReference> items should be placed in your Directory.Packages.props file to be used by every project in a repository:

<Project>
  <ItemGroup>
    <GlobalPackageReference Include="Nerdbank.GitVersioning" Version="3.5.109" />
  </ItemGroup>
</Project>

To learn more about this feature, see the documentation on Global Package References.

Improved performance while loading packages in all tabs in Visual Studio

For each of the tabs in the Visual Studio Package Management UI, we’ve improved the performance it takes to fully load each item and its metadata by almost 66%. A huge thanks to @mjolka for contributing this performance improvement to NuGet by increasing HttpClientHandler.MaxConnectionsPerServer to a higher value.

NuGet signed package verification

NuGet package signatures are based on X.509 certificates, and a prerequisite for signed package verification is a certificate root store that’s valid for both code signing and timestamping.

Starting with .NET 7, NuGet uses fallback certificate bundles included in the .NET SDK to verify signed packages where a suitable system root store is not available. These bundles are sourced from the Microsoft Trusted Root Program and contain the same code signing and timestamping certificates as the root store on Windows.

Some NuGet commands, such as sign and verify, always perform signed package verification.

For more information on this topic and the behavior on specific operating systems, see NuGet Signed Package Verification.

Authentication improvements in Visual Studio

One major issue we hear from you is the NuGet authentication experience in Visual Studio. Over the last release, we’ve been engaged in reducing the amount of times you are prompted to authenticate to your private sources while also providing context to the authentication windows so you know whether or not a prompt is to authenticate to a NuGet feed or a Visual Studio service.

In this release, we added context to each window to let you know when NuGet needs your attention.

Image VisualStudioAuth

NuGet.exe localization

NuGet.exe commands have been enhanced further with localization in 13 languages: Simplified Chinese, Traditional Chinese, Czech, German, Spanish, French, Italian, Japanese, Korean, Polish, Portuguese, Russian, Turkish.

Closing

NuGet 6.4 is a significant release that should improve many aspects of your daily package management needs. We’ve polished the central package management feature, improved performance of loading packages in Visual Studio, added fallback certificate bundles in the .NET SDK for signed packaged verficiation, and added contextual improvements to authentication prompts in Visual Studio.

We’re excited to see you use NuGet 6.4 & include it in your toolset for building amazing things with .NET.

For more details on NuGet 6.4, 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

Discussion is closed. Login to edit/delete existing comments.

  • Alexey Leonovich 0

    Hello.
    What is estimated timeframe for finally fixing package applicability in NuGet package manager. It suggests latest packages for TFMs that doesn’t support it. It’s a real pain if TFM is .netcore 3.1, .net5.0 and today .net6.0.

    • Jon DouglasMicrosoft employee 2

      We are currently working on the backend portion of this work that might be completed later this year. Then we can use those APIs to help search only for TFMs applicable to your project’s TFM.

  • P S 0

    When 6.4 version will be available through winget?

    • Jon DouglasMicrosoft employee 0

      The binaries are live and we give 2 weeks to bless our release to ensure no major bugs break builds. WinGet I think uses the latest in the feed, so that will be about 2 weeks until 6.4 is promoted.

  • Mariusz 0

    What’s the purpose of “”? Can’t we already have “” in Directory.Build.props? Is this only about different defaults for “IncludeAssets” and “PrivateAssets”? And why you actually think this defaults are better that the defaults used in “”?

    • Jon DouglasMicrosoft employee 0

      I only see “” marks and not what you’re referring to. Maybe the editor cut those off. I’d love to help answer your question however if you can reply with what was meant in those quotes.

      • Mariusz 0

        :/… thanks for replying anyway, here’s what I wanted to write (slightly edited), hope you can answer this 🙂

        What’s the purpose of “GlobalPackageReference”? Can’t we already have “PackageReference” in Directory.Build.props? Is this only about different defaults for “IncludeAssets” and “PrivateAssets” and possibility to have this entries in Directory.Packages.props file instead of Directory.Build.props file? And why you actually think this defaults are better that the defaults used in “PackageReference”?

  • Rehan Saeed 0

    When I added the following Directory.Packages.props file, the analyzers stopped working and Minver stopped assigning assembly versions. I’m using the latest preview of VS and .NET 7. What am I missing?

    <Project>
      <ItemGroup Label="Global Package References">
        <GlobalPackageReference Include="Microsoft.VisualStudio.Threading.Analyzers" Version="17.4.27" />
        <GlobalPackageReference Include="MinVer" Version="4.2.0" />
        <GlobalPackageReference Include="StyleCop.Analyzers" Version="1.2.0-beta.435" />
      </ItemGroup>
    </Project>

    • anonymous 0

      This comment has been deleted.

      • anonymous 0

        this comment has been deleted.

    • Amadeusz Sadowski 0

      I believe you need to add ManagePackageVersionsCentrally=true.

      <Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
...
</Project>
  • lazoli 0

    I have Visual Studio 2022 v17.4, NuGet version 6.4.0.111 and .NET Framework 4.8. «Directory.Packages.props» is located in the repository root folder. Unfortunately, the GlobalPackageReference doesn’t work – but PackageVersion works.

    My «Directory.Packages.props»:

    <?xml version="1.0" encoding="utf-8"?>
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <GlobalPackageReference Include="log4net" Version="2.0.15" />
    <GlobalPackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="6.0.0" />
  </ItemGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.1" />
  </ItemGroup>
</Project>

    The packages “log4net” and “Microsoft.CodeAnalysis.NetAnalyzer” should be automatically referenced in every project, right?
    An example from the .csproj file:

      <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
  </ItemGroup>

    What is still missing?

    • lazoli 0

      The issue is. If I have both GlobalPackageReference and PackageVersion references in the project (.csproj), then the GlobalPackageReference packages are not referenced. But if I have a project (.csproj) without a PackageReference, then the GlobalPackageReference packages are there. What can be missing – bug?

      • Eli Black 0

        Are you using .NET SDK 7? It took me a while to figure out that isn’t supported by .NET SDK 6 ‘-_-

Feedback usabilla icon