The following is not a criticism, just an experience, and not blaming Microsoft at all. It's a complex product with lots of gotchas, and this one probably will get a few, so hoping to help.
Spent 3 days in a rabbit hole (#1 and #2) trying to understand why after updating my Blazor project AspNetCore modules (8.0.10 in this case), it would no longer compile successfully with AOT:true, with virtually no logging or output to work with. Tried many code modifications that wasted much time, but in the end it wasn't my code at all, I discovered the problems were due to zombie compile processes and lingering deprecated cached compiled files in my project directories that for some reason weren't being properly destroyed/updated by the new version of the compiler.
A simple 'clean solution' was insufficient. I eventually scripted the hard deletion of my ~30 project bin and obj folders, and likewise preceded the build with a task kill of potentially-orphaned build-related processes that remained zombied, locking files from future build attempts.
The AOT:true compiler does work, but there can't be any trace of prior builds from prior compiler versions residing on disk. I consider this a bug because it's not obvious what the problem is, with many misdirections that leads to days of hunting rabbits. At the very least there should be meaningful error messages when compilation fails, but ideally during package upgrading, an informational popup explaining that all these obj/bin folders need to be deleted, or maybe actually perform that action.
For the workaround (hopefully future-proof), here's my new pre-cleansing script that is executed every time before any AOT:true build is attempted
taskkill /IM mono-aot-cross.exe /F
taskkill /IM dotnet.exe /F
rmdir /s /q "C:\Dev\MyProject1\bin"
rmdir /s /q "C:\Dev\MyProject1\obj"
rmdir /s /q "C:\Dev\MyProject2\bin"
rmdir /s /q "C:\Dev\MyProject2\obj"
..etc
rmdir /S /Q "C:\inetpub\myPublishTarget\wwwroot"
and then the build is like
msbuild /t:restore;build "c:\Dev\MySolution.sln" /t:Clean /p:Configuration=Release
and the publish
dotnet publish /p:NoBuild=true /p:PublishDir="c:\myPublishTarget" "c:\Dev\MyBlazorProjectFolder" -p:RunAOTCompilation=true -p:BlazorEnableCompression=false (or true)
and for posterity, at the end of the build script, I repeat
taskkill /IM mono-aot-cross.exe /F
taskkill /IM dotnet.exe /F
Precleansing for AOT:true builds typically only applies to either production or staging releases, so the loss of pre-cached items shouldn't impact development cycle times at all.
The following is not a criticism, just an experience, and not blaming Microsoft at all. It's a complex product with lots of gotchas, and this one probably will get a few, so hoping to help.
Spent 3 days in a rabbit hole (#1 and #2) trying to understand why after updating my Blazor project AspNetCore modules (8.0.10 in this case), it would no longer compile successfully with AOT:true, with virtually no logging or output to work with. Tried many code modifications that wasted much time, but in the end it wasn't my code at all, I discovered the problems were due to zombie compile processes and lingering deprecated cached compiled files in my project directories that for some reason weren't being properly destroyed/updated by the new version of the compiler.
A simple 'clean solution' was insufficient. I eventually scripted the hard deletion of my ~30 project bin and obj folders, and likewise preceded the build with a task kill of potentially-orphaned build-related processes that remained zombied, locking files from future build attempts.
The AOT:true compiler does work, but there can't be any trace of prior builds from prior compiler versions residing on disk. I consider this a bug because it's not obvious what the problem is, with many misdirections that leads to days of hunting rabbits. At the very least there should be meaningful error messages when compilation fails, but ideally during package upgrading, an informational popup explaining that all these obj/bin folders need to be deleted, or maybe actually perform that action.
For the workaround (hopefully future-proof), here's my new pre-cleansing script that is executed every time before any AOT:true build is attempted
and then the build is like
msbuild /t:restore;build "c:\Dev\MySolution.sln" /t:Clean /p:Configuration=Releaseand the publish
dotnet publish /p:NoBuild=true /p:PublishDir="c:\myPublishTarget" "c:\Dev\MyBlazorProjectFolder" -p:RunAOTCompilation=true -p:BlazorEnableCompression=false (or true)and for posterity, at the end of the build script, I repeat
Precleansing for AOT:true builds typically only applies to either production or staging releases, so the loss of pre-cached items shouldn't impact development cycle times at all.