Repository navigation
Pin the managed SQLitePCLRaw trio at 3.x — the prerequisite half of #3328 - #3342
Conversation
…3328 The platform image's own reference set is internally inconsistent, and that fails EVERY module compile in EVERY satellite with no repo change to blame. Both sides of the conflict are inside /app: error MSB3277: "SQLitePCLRaw.core, Version=2.1.11.2622" vs "…3.0.2.2801" depends on 2.1.11: platform-refs-effective/SQLitePCLRaw.core.dll depends on 3.0.2: platform-refs-effective/Microsoft.CodeAnalysis.Workspaces.dll 🚨 The issue's suggested fix — pin the trio at 2.1.11 — is a NO-OP. Measured: no package in the closure depends on core 3.0.2 (Microsoft.CodeAnalysis.Workspaces.Common declares no SQLitePCLRaw dependency in ANY cached version, and lib.e_sqlite3 3.53.3 has empty dependency groups). The 3.0.2 side is an ASSEMBLY reference baked into Roslyn's metadata — its optional SQLite persistent storage — with `[]` for project items. 2.1.11 is already what resolves and ships, and it is the LOSING side. So the direction is 3.x, which is also the coherent pairing: 3.x managed beside the 3.53.3 native, where 2.1.x-managed-under-3.53.3-native was only ever the CVE workaround for GHSA-2m69-gcr7-jv3q. The issue flagged one open question — "versions to be confirmed against what Microsoft.Data.Sqlite 10.0.10 expects". Settled by experiment, not judgement: a probe referencing Microsoft.Data.Sqlite 10.0.10 with core/provider/bundle 3.0.2 and lib 3.53.3 builds with NO MSB3277, loads SQLitePCLRaw.core 3.0.2.2801, reports engine 3.53.3 and round-trips a query. MeshWeaver.Hosting.Sqlite uses only SqliteConnection/SqliteCommand — no LoadExtension, no native extension — so the probe exercised the same surface the backend does. 🚨 THIS COMMIT IS INERT ON ITS OWN, and the comment says so rather than letting a reader assume otherwise. Under CPM a bare <PackageVersion> does not pin a PURE TRANSITIVE. Measured on this very edit: building MeshWeaver.Plugins' MeshWeaver.Hosting.Sqlite against this tree still resolved core/provider/bundle 2.1.11, while lib.e_sqlite3 took 3.53.3 — that project alone carries an explicit PackageReference for it. The remedy is the narrow one this file already prescribes for DataProtection: a versionless <PackageReference> in the project the package flows through, NOT repo-wide CentralPackageTransitivePinningEnabled. That half lives in MeshWeaver.Plugins and is gated on this commit reaching its MW_PLATFORM_REF — a versionless reference to a package with no PackageVersion in the pinned core is a CPM error. Hence Refs, not Closes. Verified: MeshWeaver.Graph.Contract 0 Error(s) 0 Warning(s) Release -warnaserror (the props file parses and nothing in core resolves differently — nothing in core references SQLite at all). Refs #3328 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🟡 Changes recommended
The new “managed trio” pin set appears incomplete relative to #3328 (missing an explicit SQLitePCLRaw.batteries_v2 pin), which could undermine the intended “pinned as a set” guarantee in the follow-up.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Pins additional SQLitePCLRaw package versions in Directory.Packages.props to prepare for resolving an internal platform-image reference-set conflict (MSB3277) described in #3328, where Roslyn Workspaces is bound to SQLitePCLRaw.core 3.x while the image also carries 2.1.11.
Changes:
- Expands the SQLitePCLRaw pin block comment to document the observed MSB3277 root cause and why this PR alone is not the full fix.
- Adds central
PackageVersionentries forSQLitePCLRaw.core,SQLitePCLRaw.provider.e_sqlite3, andSQLitePCLRaw.bundle_e_sqlite3at3.0.2alongside the existingSQLitePCLRaw.lib.e_sqlite3pin.
File summaries
| File | Description |
|---|---|
| Directory.Packages.props | Adds central pins for additional SQLitePCLRaw packages and documents the platform-image MSB3277 skew motivating the follow-up fix. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| <PackageVersion Include="SQLitePCLRaw.lib.e_sqlite3" Version="3.53.3" /> | ||
| <PackageVersion Include="SQLitePCLRaw.core" Version="3.0.2" /> | ||
| <PackageVersion Include="SQLitePCLRaw.provider.e_sqlite3" Version="3.0.2" /> | ||
| <PackageVersion Include="SQLitePCLRaw.bundle_e_sqlite3" Version="3.0.2" /> |
Test Results (shard 1)475 tests 475 ✅ 41s ⏱️ Results for commit 7e6e77d. |
Test Results (shard 0)251 tests 251 ✅ 2m 24s ⏱️ Results for commit 7e6e77d. |
Test Results (shard 3)369 tests 367 ✅ 53s ⏱️ Results for commit 7e6e77d. |
Test Results (shard 5) 4 files 4 suites 1m 39s ⏱️ Results for commit 7e6e77d. |
Test Results (shard 4)2 316 tests 2 316 ✅ 2m 39s ⏱️ Results for commit 7e6e77d. |
Test Results (shard 2)588 tests 396 ✅ 2m 56s ⏱️ Results for commit 7e6e77d. |
Test Results 15 files 15 suites 11m 13s ⏱️ Results for commit 7e6e77d. |
What this is, and what it is not
The platform image's own reference set is internally inconsistent, which fails every module
compile in every satellite with no repo change to blame (MeshWeaver.Plugins#1349 is blocked on it).
Both sides of the conflict resolve inside
/app:🚨 This PR is INERT on its own. It is the prerequisite, not the fix, and the props comment says
so — see below.
Refs #3328, notCloses.Why the issue's suggested fix would not have worked
The issue proposes pinning the managed trio at 2.1.11. Measured, that is a no-op:
core 3.0.2Microsoft.CodeAnalysis.Workspaces.Commondeclares no SQLitePCLRaw dependency in any cached version (4.14.0, 5.0.0, 5.3.0, 5.6.0, 5.9.0); the only packages depending on the family areMicrosoft.Data.Sqlite*, all asking2.1.11lib.e_sqlite3 3.53.3drags in managed 3.x[]for project items2.1.11is already what resolves and ships — it is the losing side. Pinning it changes nothingand the same MSB3277 returns, with a pin that now looks like the fix.
The open question the issue flagged, settled by experiment
A probe referencing MDS 10.0.10 with
core/provider.e_sqlite3/bundle_e_sqlite33.0.2 andlib.e_sqlite33.53.3:No MSB3277, and the CVE-patched engine is unchanged.
MeshWeaver.Hosting.Sqliteuses onlySqliteConnection/SqliteCommand— noLoadExtension, no native extension — so the probeexercised the surface the backend actually uses. 3.x managed beside a 3.53.3 native is also the
coherent pairing; 2.1.x-managed-under-3.53.3-native was only ever the CVE workaround.
🚨 Why it is inert, measured on this very edit
Under Central Package Management a bare
<PackageVersion>does not pin a pure transitive.Building MeshWeaver.Plugins'
MeshWeaver.Hosting.Sqliteagainst this tree(
-p:MeshWeaverRoot=<this worktree>) still resolved:The one that moved is the one with an explicit
<PackageReference>. That is the whole mechanism,and it is why this PR alone changes nothing at runtime.
The other half, and why it is not here
The remedy is the narrow one
Directory.Packages.propsalready prescribes for DataProtection: aversionless
<PackageReference>in the project the package flows through(
MeshWeaver.Hosting.Sqlite, beside the existinglib.e_sqlite3one) — not repo-wideCentralPackageTransitivePinningEnabled, whose blast radius is resolution-wide and belongs in itsown PR.
That half lives in MeshWeaver.Plugins and is gated on this commit reaching its
MW_PLATFORM_REF: a versionless reference to a package with noPackageVersionin the pinned coreis a CPM error. Plugins holds zero pins of its own —
src/Directory.Packages.propspurelyimports core's — so it cannot be short-circuited there without introducing a second place pins live.
Verification
MeshWeaver.Graph.Contract—0 Error(s) 0 Warning(s), Release,-warnaserror. Nothing in corereferences SQLite at all, so nothing in core resolves differently; the props file parsing and the
Plugins-side resolution measurement above are the real checks.
Refs #3328