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
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
OpenCvSharptype (e.g.private Mat? srcMat;) fails to render at all, both on a fresh/deep-linked load and on normal in-appNavLinknavigation from an already-booted page:Same failure for
BlazorApp.Pages.FeatureMatching./build-info(BuildInfo.razor) is the only page that renders correctly - it's also the only page whose@codeblock never declares a field of anOpenCvSharptype (it only callsCv2.GetBuildInformation()inline in markup).Suspected cause
BlazorApp.csprojhasRunAOTCompilation=truefor Release, but #9'sExcludeOpenCvSharpFromAOTtarget excludesOpenCvSharp.dllfrom that AOT pass (it stays interpreted; see #8).BlazorApp.dllitself, 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:
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 indotnet/runtime, or once #8 no longer requires excludingOpenCvSharp.dllfrom AOT at all).Related
OpenCvSharp.dllis excluded from AOT)