Skip to main content

NuGet - Transitive pinning in Central Package Management

I'm a big fan of the Central Package Management feature of NuGet. This allows to manage your NuGet package versions centrally instead of at the project level. Why is this important? It helps to avoid that multiple versions of the same packages are used inside your solution. This could lead to strange behavior and unexpected bugs.

Central Package Management solves this problem by managing all package versions at the solution level in (one or more) Directory.Packages.props files:

Transitive dependencies

By default only direct/top level dependencies are managed through Central Package Management. But you also have transitive dependencies. Transitive dependencies refer to the indirect dependencies that a package brings into your project. When you install a NuGet package, it might depend on other packages, which in turn might have their own dependencies. These chains of dependencies create a dependency graph that can go several levels deep.

Here's a breakdown of how it works:

  1. Direct/Top level dependencies: These are the packages you explicitly install in your project.
  2. Transitive dependencies: These are the packages that your direct dependencies rely on.

For example, if you install Package A, which depends on Package B, and Package B depends on Package C, then Package B is a direct dependency of Package A, and Package C is a transitive dependency of Package A.

NuGet handles these dependencies automatically, ensuring that all necessary packages are installed and compatible with each other.

Transitive pinning

As NuGet handles the transitive dependencies automatically, you don’t have direct control over the package version that will be used. This can be a problem for example when a vulnerability is found in one of the transitive dependencies that you are using. One way to solve is to promote that package to a direct/top level dependency but a better solution is to use Transitive pinning.

This allows you to manage the package version using central package management without promoting it to a top level dependency. This feature is not enabled automatically but you can enable by setting the MSBuild property CentralPackageTransitivePinningEnabled to true in a project or in a Directory.Packages.props or Directory.Build.props import file:

More information

NuGet Central Package Management

Convert a project to use centralised package management

.NET Upgrade Assistant now supports upgrading to Centralized Package Management

NuGet Package Dependency Resolution | Microsoft Learn

Central Package Management | Microsoft Learn

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...