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

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.

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

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         ...