Import Packages.props so central package versions actually apply

[Kaegun]

Problem

Building the solution (or consuming the published Microsoft.PowerPlatform.Dataverse.Client package) pulls in very old, vulnerable transitive package versions — e.g. Newtonsoft.Json 3.5.8, Azure.Identity 1.0.0 (deprecated), System.Formats.Asn1 5.0.0, Microsoft.Rest.ClientRuntime 0.9.4 (deprecated). Visual Studio's NuGet "Show only vulnerable" view lists them, and dotnet restore reports NU1903/NU1902 security advisories plus many NU1604/NU1602 "does not contain an inclusive lower bound" warnings.

Root cause

src/Packages.props defines the central PackageVersion_* properties, but no build file imports it. Neither Directory.Build.props (root or src/) nor the Build.Common.* props import it. Consequently every <PackageReference Version="$(PackageVersion_XXX)" /> evaluates to an empty version string, so NuGet treats it as having no lower bound and resolves the oldest version available on the feed.

The same empty values feed the nuspec version="[$PackageVersion_XXX$,)" tokens, producing dependencies with no lower bound ([,)) in the published packages — which is why downstream consumers also pull the ancient versions.

Fix

Import Packages.props from src/Directory.Build.props (auto-imported by every project under src/), so the intended, non-vulnerable pinned versions take effect:

<Import Project="$(MSBuildThisFileDirectory)Packages.props" />

Also bump global.json SDK 6.0.406 → 8.0.100 (rollForward: latestFeature) so the net8.0 targets restore on a supported SDK (.NET 6 is EOL).

Verification

dotnet restore of DataverseClient.sln, before vs after:

Signal	Before	After
NU1903/NU1902 (vulnerable package)	many	0
NU1604/NU1602 (no lower bound)	many	0
ServiceClientConverter (public deps only)	old/broken resolution	restores clean
Remaining	—	only NU1102 for internal Microsoft.Xrm.Sdk 9.2.x-master (expected; not on public feed)

Notes / caveats

• The two internal-only pins (Microsoft.Xrm.Sdk, Microsoft.Crm.Sdk.Proxy at 9.2.x-master) are untouched; they resolve on Microsoft's internal feed.
• This fixes the source build. The already-published packages still carry the loose dependency bounds and would need a republish built from this corrected source to fix downstream consumers.
• If Microsoft's internal build already injects Packages.props via a file not present in the public repo, this import is a harmless duplicate (same property values). If a different wiring is preferred, happy to adjust.

Attribution

This investigation and fix were developed with the assistance of Claude Code (Anthropic). The root cause was diagnosed by reproducing the restore, correlating the NU1604/NU1903 warnings with the orphaned Packages.props, and verifying the fix removes all vulnerable-version resolutions.

🤖 Generated with Claude Code