publishing Blazor with AOT is now broken in 8.0.10 AspNetCore

[Sean4572435243]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Upgraded from 8.0.4 AspNetCore to 8.0.10 and now my production publish script breaks because of AOT. This is the command

dotnet publish /p:Configuration=REDACTED_TESTING /p:PublishDir="%localREDACTEDDevIISPublishDir%" "%REDACTEDSolutionDir%\Modules\REDACTEDAS" -p:RunAOTCompilation=true -p:BlazorEnableCompression=false

for which it seemed to AOT about 78 files, but then followed with:

[REDACTEDSAC.dll] Exec (with response file contents expanded) in 
c:\REDACTED\Modules\REDACTEDAS\obj\REDACTED_TESTING\net8.0\linked: 
MONO_PATH=
	c:\REDACTED\Modules\REDACTEDAS\obj\REDACTED_TESTING\net8.0\linked;
	C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\8.0.10\runtimes\browser-wasm\native\;
	C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\8.0.10\runtimes\browser-wasm\lib\net8.0 
MONO_ENV_OPTIONS= 
	C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Runtime.AOT.win-x64.Cross.browser-wasm\8.0.10\Sdk\..\tools\mono-aot-cross.exe --wasm-exceptions --debug --llvm 
		"--aot=no-opt,static,direct-icalls,deterministic,mattr=simd,dwarfdebug,
			llvm-path=C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.Emscripten.3.1.34.Sdk.win-x64\8.0.10\tools\bin\,
			static,llvmonly,interp,asmonly,
			llvm-outfile=c:\REDACTED\Modules\REDACTEDAS\obj\REDACTED_TESTING\net8.0\wasm\for-publish\REDACTEDSAC.dll.bc.tmp,
			temp-path=c:\REDACTED\Modules\REDACTEDAS\obj\REDACTED_TESTING\net8.0\wasm\for-publish\REDACTEDSAC.dll.tmp" "REDACTEDSAC.dll"

C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\8.0.10\Sdk\WasmApp.Native.targets(686,5): error : 
Precompiling failed for c:\REDACTED\Modules\REDACTEDAS\obj\REDACTED_TESTING\net8.0\linked\REDACTEDServiceAdaptersCore.dll with exit code -1073741571. [c:\REDACTED\Modules\REDACTEDAS\REDACTEDAS.csproj]
C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\8.0.10\Sdk\WasmApp.Native.targets(686,5): error : [c:\REDACTED\Modules\REDACTEDAS\REDACTEDAS.csproj]

Expected Behavior

Nothing in my build script changed, only the update to 8.0.10 broke AOT

Steps To Reproduce

Couldnt' produce an isolated example from my large codebase

Exceptions (if any)

No response

.NET Version

8.0.403

Anything else?

No response

[javiercn]

/cc @lewing

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[Sean4572435243]

I should add I see many dotnet.exe instances, and these don't die after the failed attempt at AOT compilations, leaving folders/files blocked and blocking repeated build attempts. There's some inconsistent behavior that's hard to pinpoint. I tried making another solution with a subset of projects, and that bore initial results, but I haven't been able to replicate, even deleting bin/obj dirs.
EDIT: might also be the mono-aot-cross.exe processes. There's two left that never complete, consuming gigs of ram

[Sean4572435243]

Was finally able to isolate to the offending code: usage of dynamic. I'll try to rework the code to avoid dynamic.

Are we not supposed to use dynamic in AOT? Or is this a bug?

I can't be certain if this code was just recently uncommented or was previously AOT compatible so it may have nothing to do with the AspNetCore version upgrade; apologies for the misleading issue title if this is the case.

[colejohnson66]

dynamic is not supported in trimming, because the runtime has no way of knowing what the object is until it’s used. IIRC, things that are not trim compatible are also not AOT compatible.

[Sean4572435243]

Ok thanks Cole. I'll close this issue and write it off as a known limitation of trimming/AOT

[Sean4572435243]

Figured it out
#109166

[colejohnson66]

Nice. While my comment about dynamic was true, the compiler/MSBuild shouldn't be bugging out.