Mixed-mode assembly with a System.* name prefix but a non-system public key token fails to load in the .NET Framework build host (PS0264 / 0x80131515)

[gfraiteur]

Summary

On .NET Framework, PostSharp fails to weave a project that references a mixed-mode (C++/CLI, IJW) assembly whose name starts with System. but which is not a framework assembly — i.e. it has a non-Microsoft public key token and is not in the GAC. The mixed-mode build of System.Data.SQLite is the motivating example. The build fails with:

error PS0264: Could not load file or assembly 'System.Data.SQLite, Version=1.0.118.0, Culture=neutral,
PublicKeyToken=db937bc2d44ff139' or one of its dependencies. Operation is not supported.
(Exception from HRESULT: 0x80131515)

0x80131515 is COR_E_NOTSUPPORTED. It is enough for a type from the mixed-mode assembly to appear in the signature of a woven method — no compile-time code referencing the type is required.

Repro

• A net48 project that:
  • references a mixed-mode build of System.Data.SQLite — the "static" bundle where the native SQLite engine is statically linked into System.Data.SQLite.dll (i.e. CorFlags shows ILONLY: 0). This is not the pure-IL System.Data.SQLite.Core NuGet assembly, which works fine.
  • applies any aspect (e.g. OnMethodBoundaryAspect) to a method such as void M(SQLiteConnection c).

Result: PS0264 / 0x80131515 during weaving. Replacing the mixed-mode assembly with the pure-IL NuGet build, or removing the SQLite type from the signature, makes the error disappear.

Analysis

To run aspects at build time, PostSharp loads referenced assemblies into its build host process from memory, and a mixed-mode assembly cannot be loaded that way (the runtime must map its native sections — IAT fixups / a TLS section — from a file on disk). To handle this, PostSharp normally normalizes a mixed-mode image into a pure-IL, metadata-only stand-in before loading it.

The bug: this normalization is skipped by a name-based fast-path that treats mscorlib / System / System.* as framework assemblies needing no processing. A mixed-mode assembly named System.Data.SQLite matches that pattern, so it is loaded raw and fails.

Scope — this only affects assemblies PostSharp itself loads into the build host. Genuine framework mixed-mode assemblies such as System.Data and System.Transactions are not affected: although they are also mixed-mode and named System.*, they carry a Microsoft public key token and live in the GAC, so PostSharp lets the runtime load them from the GAC directly — they never go through PostSharp's loader. The bug is specific to a System.*-named mixed-mode assembly with a non-Microsoft public key token.

(A separate mechanism — the pure-IL facade PostSharp builds for wrong-architecture references, message PS0220 — only engages on an architecture mismatch, so it does not cover this same-architecture case.)

Expected behaviour

PostSharp should weave a project that references such a mixed-mode assembly, rather than failing to load it.

Workarounds

• Use the managed build of the dependency where one exists — for SQLite, the NuGet System.Data.SQLite.Core package (pure-IL System.Data.SQLite.dll + separate native SQLite.Interop.dll) loads correctly.
• Avoid putting types from a mixed-mode assembly in the signatures of woven methods.

Affected versions

Reproduced on 2025.1.12; 2026.0 exhibits the same behaviour.

[gfraiteur]

Root cause identified.

PostSharp's .NET Framework build host already knows how to consume mixed-mode (C++/CLI) assemblies: before loading one into the compiler process, it normalizes it into a pure-IL, metadata-only image (which can be loaded), instead of loading the raw mixed-mode image.

The problem is a name-based fast-path: assemblies named mscorlib, System, or anything starting with System. are assumed to be pure-IL framework assemblies and are loaded as-is (to avoid unnecessary work). The mixed-mode build of System.Data.SQLite matches that System.* pattern, so it is wrongly exempted from normalization — the raw mixed-mode image is handed to the runtime and the load fails with 0x80131515.

This explains the observations exactly:

• the pure-IL System.Data.SQLite.Core NuGet build works (nothing to normalize);
• only the mixed-mode ("static") build fails;
• it fails when the assembly's architecture matches the host (the normalization fast-path, not the architecture-mismatch handling, is what's involved).

Fix direction: decide whether to normalize based on the actual image — i.e. normalize whenever the assembly is not IL-only — regardless of the assembly's name, rather than exempting System.* assemblies. The name-based fast-path should continue to gate only the unrelated optimization it was intended for.

A regression test reproducing the exact failure (using a mixed-mode System.Data.SQLite binary) has been added on our side.

[gfraiteur]

Released in v2026.0.14.

-- Claude for Gael