Guardrails / dotnet

Package versions are managed centrally

dotnet/central-package-management@v1

One Directory.Packages.props decides the version of every package, rather than each project file deciding its own.

Id	dotnet/central-package-management
Version	v1
Category	dotnet
Default severity	warning
Interpreter	python3
Timeout	30 seconds
Violations tolerated	0
Collects	dotnet

Collectors

This guardrail gathers nothing itself. It depends on the collectors below, which the CLI runs once per build before any check, and reads what they found out of GUARDRAIL_FACTS. A collector that collects nothing skips this guardrail rather than failing it.

Collector	Gathers	Inputs it is given
dotnet	The .NET build in the project directory: the SDK it pins, every project file and the frameworks each targets, the packages they reference and which of them are pinned or supplied centrally, and the lock files beside them.	projectDir

The inputs above are this guardrail's own, passed straight through. Configuring one in buildnote.json changes what is collected, and two guardrails configured the same way share the one collection.

Configuration

{
  "guardrails": {
      "failOn": "error",
      "comment": true,
      "checks": [
          {
              "use": "dotnet/central-package-management@v1",
              "severity": "warning",
              "with": {
                  "projectDir": "."
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

Input	Description	Default	Environment variable
projectDir	Directory holding the project, relative to the directory the CLI runs in.	.	GUARDRAIL_INPUT_PROJECTDIR

How to fix

Turn central package management on in a Directory.Packages.props beside the solution, and drop the Version attributes from the project files:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Serilog" Version="4.0.0" />
  </ItemGroup>
</Project>

With a version in every project file instead, two projects in the same solution restore different versions of the same package, and an upgrade lands only in the project files somebody remembered to edit.

More in dotnet

• dotnet/dependencies-versioned. Every PackageReference names a version itself or takes one from a central PackageVersion.
• dotnet/sdk-pinned. global.json names the SDK the build uses and holds it there, rather than letting a newer one on the runner take over.
• dotnet/target-framework-floor. Every net<major>.<minor> framework a project targets is no older than the configured floor.

All 4 dotnet guardrails