Audit sample projects for stale/inconsistent NuGet package pins and NU1903 vulnerability warnings

[adrianhall]

Summary

While fixing #477 (samples/datasync-server), the sample's build was found to be broken on main due to package version drift: the sample explicitly pinned Microsoft.AspNetCore.OpenApi/Microsoft.EntityFrameworkCore.SqlServer/Microsoft.EntityFrameworkCore.Tools at 10.0.3, while the repo's centrally-managed DotNetVersion (Directory.Packages.props) had since moved to 10.0.9. Resolving that surfaced a further transitive assembly-version conflict on Microsoft.OData.Core/Microsoft.OData.Edm (needed pinning to 8.4.3 to match ODataVersion/the existing Microsoft.Spatial pin in CommunityToolkit.Datasync.Server.Abstractions). See #488 for the fix applied to that one sample.

Since samples/Directory.Packages.props turns off Central Package Management for all samples (ManagePackageVersionsCentrally=false), each sample pins its own package versions independently and can silently drift out of sync with the rest of the repo (and with each other) whenever Directory.Packages.props bumps a shared version like DotNetVersion or ODataVersion. A couple of other examples spotted during a quick pass (not exhaustive):

• samples/todoapp-mvc/TodoApp.Service/TodoApp.Service.csproj: CommunityToolkit.Datasync.Server* is pinned at 10.1.0, but Microsoft.EntityFrameworkCore.SqlServer is still pinned at 10.0.3.
• samples/todoapp-blazor-wasm/TodoApp.BlazorWasm.Server/TodoApp.BlazorWasm.Server.csproj: still references CommunityToolkit.Datasync.Server(.EntityFrameworkCore) 10.0.0 (predates the UnsafeEntityLogging option added in 10.1.0/SECURITY: Add TableOptions flag for unsafe entity logging #446) and pins EF Core / ASP.NET Core packages at 10.0.3.

Ask

1. Audit every sample project under samples/ (datasync-server, datasync-server-cosmosdb-singlecontainer, todoapp, todoapp-mvc, todoapp-tutorial, todoapp-blazor-wasm, and any client platform samples) for:
   • Explicit PackageReference versions that have drifted from the repo's centrally-managed versions (DotNetVersion, ODataVersion in root Directory.Packages.props) or from the latest published CommunityToolkit.Datasync.* NuGet versions.
   • Any sample that fails to restore/build cleanly as a result (dotnet build per sample).
2. Decide on (and document) a strategy to prevent this drift going forward — e.g. a scheduled CI job that builds every sample on a cadence, re-enabling Central Package Management for samples with an explicit override list, or a lightweight script/CI check that diffs sample package versions against Directory.Packages.props.
3. Separately, identify and action the NU1903 high-severity vulnerability advisory warnings currently emitted during restore across src/tests (and likely some samples):
   • Microsoft.OpenApi 2.0.0 — GHSA-v5pm-xwqc-g5wc (pulled in transitively, likely via NSwag/Swashbuckle/OpenApi tooling).
   • SQLitePCLRaw.lib.e_sqlite3 2.1.11 — GHSA-2m69-gcr7-jv3q (pulled in transitively, likely via the LiteDb/SQLite test dependencies).
     For each, determine whether a newer, non-vulnerable version is available and pin/upgrade it (directly or via a transitive pinning override in Directory.Packages.props), or document why the warning is a false positive / acceptable risk for this repo.

Acceptance criteria

• Every sample project builds cleanly (dotnet build) against the current Directory.Packages.props versions and the latest published CommunityToolkit.Datasync.* packages.
• A documented mechanism (CI check, script, or process) exists to catch future version drift in samples before it reaches main.
• The NU1903 advisories for Microsoft.OpenApi and SQLitePCLRaw.lib.e_sqlite3 are resolved (upgraded/pinned) or explicitly triaged and documented as accepted risk.

Related

• Examples: Review datasync-server sample for UnsafeEntityLogging secure default (#446) #477 / docs: document secure UnsafeEntityLogging default in datasync-server sample (#477) #488 — fixed this drift for samples/datasync-server specifically.
• Examples: Review todoapp-mvc server for UnsafeEntityLogging secure default (#446) #480/docs: document secure UnsafeEntityLogging default in todoapp-mvc sample #485, Examples: Demonstrate UnsafeEntityLogging in the todoapp-tutorial server walkthrough (#446) #476/docs: demonstrate UnsafeEntityLogging in todoapp-tutorial server walkthrough (#476) #487 — related sample updates for UnsafeEntityLogging (SECURITY: Add TableOptions flag for unsafe entity logging #446) that did not touch this broader package-drift problem.