NuGet v3 vs v6 Resolution

Definition

NuGet’s package-resolution algorithm changed between client v3 and v6+. v3’s resolver is more permissive and often picks transitive versions that fail at link time on .NET Framework targets. v6+ adds stricter floor checks and surfaces NU1605 warnings as errors by default in CI.

CRMAPIGenerator specifically

The repo targets .NET Framework 4.6.2 and depends on Microsoft.Xrm.Sdk 9.x. Its transitive graph pulls in System.IdentityModel.Tokens.Jwt and Microsoft.IdentityModel.Tokens at versions that conflict between direct and transitive references. Under NuGet v3, dotnet restore succeeds with a warning; the resulting build hits a MissingMethodException at runtime.

Symptom

warning NU1605: Detected package downgrade: Microsoft.IdentityModel.Tokens from 6.27.0 to 5.6.0

Or, with stricter CI:

error NU1605: Detected package downgrade

Fix

# Inspect current sources:
dotnet nuget list source
 
# Remove v3 if listed:
dotnet nuget remove source <name-of-v3-source>
 
# Add v6+ official feed if missing:
dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org
 
# Force restore:
dotnet restore --force-evaluate

For local Builder runs in the kalamos container, ensure nuget.config (if present in the repo) doesn’t override the agent’s default. Check Directory.Packages.props for centrally-managed package versions that may need bumping.

Anti-pattern: don’t paper over with <NoWarn>

Some agent runs have tried to “fix” NU1605 by adding <NoWarn>$(NoWarn);NU1605</NoWarn> to the csproj. Don’t. This silences a real version-mismatch problem. Hits at runtime instead of build-time, much harder to debug. If you’re tempted, stop and check the transitive graph instead:

dotnet list package --include-transitive
  • [[CSProj-Duplicate-PackageReference-Trap]] — adjacent: dup direct refs vs transitive conflicts
  • [[Microsoft-Xrm-Sdk]] — the SDK whose transitive graph causes most of these