PostSharp build fails when Newtonsoft.Json is in the GAC (error 0x80131050)

[gfraiteur]

Summary

PostSharp's build-time compiler fails to load its bundled Newtonsoft.Json when a different binary of the same assembly (same version 13.0.0.0, same public key token, but different build) is registered in the GAC. The CLR rejects the load with error 0x80131050.

Root Cause

PostSharp ships its own copy of Newtonsoft.Json 13.0.0.0 in its installation directory. At build time, the PostSharp compiler (running as a 64-bit process) attempts to load this bundled copy. However, the CLR detects that an assembly with the same identity (version + public key token) but different binary content already exists in the GAC, and refuses to load the PostSharp-bundled copy.

The AMD64 reference visible in PostSharp logs is a red herring — it is just the first GAC probe attempt by PostSharp's internal assembly resolution. It falls back to MSIL, which is the actual GAC entry.

Reproduction

• Have Newtonsoft.Json 13.0.0.0 registered in the GAC (e.g., installed by another application).
• Build a project with PostSharp — the build fails with error 0x80131050.
• The issue does not occur on machines where Newtonsoft.Json is not in the GAC.

Workarounds

• Remove Newtonsoft.Json from the GAC.
• Replace the GAC copy with the exact binary that PostSharp bundles (may break other GAC consumers).

Possible Fixes

1. Investigate whether Newtonsoft.Json still needs to be bundled with PostSharp.
2. Give priority to GAC copies over PostSharp's bundled copies.
3. Mask this assembly from the GAC during PostSharp's assembly resolution.

[gfraiteur]

Reproduction

We reproduced the issue using a Docker container with Newtonsoft.Json 13.0.1 installed in the GAC (while PostSharp bundles 13.0.3 — both share assembly version 13.0.0.0 but have different binaries).

The key trigger is having an aspect whose type references a Newtonsoft.Json type. When PostSharp loads the aspect type at compile time, the CLR must resolve Newtonsoft.Json. The host store provides PostSharp's bundled copy, but the CLR detects a different binary in the GAC and throws FUSION_E_REF_DEF_MISMATCH (0x80131050).

Dockerfile

# escape=`
FROM mcr.microsoft.com/dotnet/framework/sdk:4.8

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop';"]

# Install Newtonsoft.Json 13.0.1 into the GAC.
# PostSharp bundles 13.0.3, but both have assembly version 13.0.0.0 with the same public key token.
RUN [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; `
    nuget install Newtonsoft.Json -Version 13.0.1 -OutputDirectory C:\temp\nuget; `
    $gacutil = Get-ChildItem 'C:\Program Files (x86)\Windows Kits' -Recurse -Filter 'gacutil.exe' | Select-Object -First 1; `
    & $gacutil.FullName /i 'C:\temp\nuget\Newtonsoft.Json.13.0.1\lib\net45\Newtonsoft.Json.dll'; `
    Remove-Item C:\temp -Recurse -Force

Minimal repro aspect

[PSerializable]
public class TestAspect : OnMethodBoundaryAspect
{
    // Static field: not serialized by [PSerializable], but the CLR must load
    // Newtonsoft.Json when loading the TestAspect type at compile time.
    private static readonly JsonSerializerSettings Settings = new JsonSerializerSettings();

    public override void OnEntry(MethodExecutionArgs args)
    {
        Console.WriteLine(Settings.ToString());
    }
}

Note: simply referencing Newtonsoft.Json in runtime code (e.g. in OnEntry) is not sufficient. The type must be loaded at compile time when PostSharp loads the aspect class, which happens when the aspect has a static or instance field of a Newtonsoft.Json type.

Verified

• Without fix: build fails with error LA0014: TypeInitializationException (caused by FileLoadException: 0x80131050)
• With fix: build succeeds

Fix

Add Newtonsoft.Json's public key token (30ad4fe6b2a6aeed) to the CLR-loaded assembly list in the native host's AssemblyReferenceList. This tells the host to let the CLR resolve the assembly from the GAC instead of the host store, avoiding the binary mismatch.