RDK0003 — Split lockstep family

Severity: error · Where: redecker check, and every build via Redecker.MSBuild

A set of packages that must all carry the same version does not.

Not the same thing as a framework band

These are easy to conflate and the distinction matters:

• A band constraint says a package must match the target framework. net8.0 wants the 8.x line.
• A lockstep constraint says a set of packages must match each other, whatever version that happens to be.

EF Core states the second one explicitly in its package documentation:

Make sure to install the same version of all EF Core packages shipped by Microsoft. For example, if version 5.0.3 of Microsoft.EntityFrameworkCore.SqlServer is installed, then all other Microsoft.EntityFrameworkCore.* packages must also be at 5.0.3.

Why an automatic updater causes this

This is not a mistake people make by hand. It is what a per-package updater produces: it bumps whichever family members happen to have newer releases, splits the set, opens a pull request, and restore succeeds. The failure surfaces later as a missing type or a provider that does not match its core package.

Example

$ redecker check Directory.Packages.props
error RDK0003: Microsoft.EntityFrameworkCore* packages are split across 2 versions: 9.0.0, 9.0.5

What it ignores

A PackageReference carrying no version is governed by central package management — the PackageVersion item holds the constraint, and reporting the reference too would be a false positive.

Configuring families

The default policy covers Microsoft.EntityFrameworkCore. In MSBuild, add your own with RedeckerLockstepPrefix; see MSBuild integration.

Related

Providers that must track another family's version — an EF Core provider following EF Core's major — are a cross-family constraint that Redecker does not model yet. Tracked in issue #1.