AOT-excluding OpenCvSharp.dll breaks type loading for any component with an OpenCvSharp-typed field

Summary

Deployed the app to GitHub Pages after #9 (the AOT-exclusion workaround for #8) landed, and any page whose component holds a field typed as an OpenCvSharp type (e.g. private Mat? srcMat;) fails to render at all, both on a fresh/deep-linked load and on normal in-app NavLink navigation from an already-booted page:

System.TypeLoadException: Attempting to load invalid type 'BlazorApp.Pages.OpenCvSharpSample'.
   at Microsoft.AspNetCore.Components.ComponentFactory.<>c__DisplayClass11_0.<CreatePropertyInjector>g__Initialize|1(IServiceProvider serviceProvider, IComponent component)
   at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForRange(DiffContext& , Int32 , Int32 , Int32 , Int32 )
   at Microsoft.AspNetCore.Components.Rendering.ComponentState.RenderIntoBatch(RenderBatchBuilder , RenderFragment , Exception& )
   at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue()

Same failure for BlazorApp.Pages.FeatureMatching. /build-info (BuildInfo.razor) is the only page that renders correctly - it's also the only page whose @code block never declares a field of an OpenCvSharp type (it only calls Cv2.GetBuildInformation() inline in markup).

Suspected cause

BlazorApp.csproj has RunAOTCompilation=true for Release, but #9's ExcludeOpenCvSharpFromAOT target excludes OpenCvSharp.dll from that AOT pass (it stays interpreted; see #8). BlazorApp.dll itself, which contains the page components, is still AOT-compiled. It looks like an AOT-compiled type that stores a field of a type belonging to an assembly excluded from that same AOT pass can't be loaded at runtime - i.e. mixing an AOT'd caller with an interpreted-only referenced type breaks type loading for the caller, not just for calls into the excluded assembly.

This matches the fallback the #9 comment already anticipated:

if a future SDK update breaks this, fall back to <RunAOTCompilation>False</RunAOTCompilation> for Release

Workaround

Disabling AOT for Release (RunAOTCompilation=false) avoids the type load failure - confirmed against the live GitHub Pages deploy. Tracking this issue to re-enable Release AOT once the underlying interaction between partial-AOT and interpreted-assembly-typed fields is fixed (either upstream in dotnet/runtime, or once #8 no longer requires excluding OpenCvSharp.dll from AOT at all).

Related

• #8 (why OpenCvSharp.dll is excluded from AOT)
• #9 (the exclusion workaround that introduced this regression)

Start with BlazorApp.csproj and the AOT-exclusion context from issues #8 and #9, then reproduce the Release deployment failure on OpenCvSharpSample or FeatureMatching and compare it with BuildInfo. Done means Release AOT can be enabled without TypeLoadException for components containing OpenCvSharp-typed fields, either after an upstream fix or when the exclusion is no longer needed.