[Blazor] Enable Blazor apps running inside of ASP.NET Core to be Native AoT compiled

[javiercn]

There are several issues around this topic, and none are very explicit.

This issue will track the work we need to do to make this happen.

AoT has become an important tech across the industry, with emphasis on cloud scenarios, performance and "leanness". As such, it's interesting for Blazor Applications (a subset at least) to be able to be compiled ahead of time.

AoT opens the door to new scenarios, such as:

• Running on devices with heavy constraints (e.g. IoT)
• Running on devices with constrained sandboxes (e.g. iOS). While .NET runs in these devices today, Native AOT is a guarantee that we can run anywhere.
• Providing Web Based UIs for CLI tools (e.g. dotnet tools).

It also enhances Blazor's ability to run on existing scenarios:

• Serverless (e.g. Azure Functions)
• Containers (e.g. Kubernetes)

In general, AoT brings in the following benefits:

• Reduced app size
  • This is important for cloud scenarios where its desirable to achieve higher container density.
• Faster startup:
  • This impacts cold starts of the application, which is important in serverless contexts.
  • Scale out of rolling updates in Cloud scenarios.
• Reduced memory demand:
  • AoT apps generally run with less memory compared to JIT apps, since there are many runtime components that are not needed.
• Increased performance:
  • Many of the constraints imposed by AoT are addressed via optimizations that can be applied at compile time, which in many cases
    leads to better performance.
• Enhanced security:
  • AoT apps are less susceptible to runtime attacks, since the code is already compiled and there is no JITing happening at runtime.
  • When running in container scenarios, you can "chisel" the container to only have the minimum code needed for the app to run, reducing the surface attack area.

Goals/Scope of the work

• Investigate and list all the blockers that prevent the app from being AoT.
• Understand the available solutions for each problem (source generation, etc.)
• Identify the fixes that we think are valuable for other reasons (perf, better trimming, etc.)
• Prioritize the set of changes we want to tackle in .NET 9.0 to drive towards this scenario (low hanging fruit, performance, trimming)

Reasoning

We only get the benefits of AoT if we remove all the blockers, so we want to reduce the cost as much as possible by making changes that provide immediate value for other reasons (perf, trimming, etc).

[javiercn]

/cc @danroth27

[javiercn]

#40033

[danroth27]

Related issue tracking enabling full trimming: #49409

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[richlander]

I'd like to see trimming and AOT as two separate goals. That way we can deliver value for folks wanting to use both CoreCLR and native AOT runtimes. In fact, I suspect we'd get more users for this work if it was productized for CoreCLR as well.

[maloo]

Please prioritize trimming over AOT. I assume it is a prerequisite for AOT anyway. I have lost several Blazor projects to other tech due to lack of trimming. Iot, CLI UI, tooling, vscode plug-ins, k8s...

[richlander]

Hey @maloo, can you elaborate a bit more? Sounds like you've got some great feedback. Also what do you mean by "CLI UI"?

[maloo]

@richlander I just meant that step one should be to support trimmed Blazer Web apps. I assume that will be a requirement for AOT apps anyway, but first supporting trimming would enable new use cases before having to fix things like runtime generics that can work with CLR but not AOT.
I do a lot of LOB stuff with C# for clients. And in many use cases (listed above) size is more important than AOT. Jit is fast enough in most cases (though I would prefer it for CLI apps). But it is easy to loose these use cases to go, rust, c++ etc when your app is in the 100MB size instead of 10MB. It just looks bad and sometimes that is enough to loose the project.
By CLI UI I mean the ability to have a CLI tool that can open upp a UI in a browser. You could do that with gui.cs, but that is way more limited than a Blazor UI.
Another thing is that LOB apps are often shared by email, which is hard without trimming...
Another mentioned use case is a native service for vscode (common in many dev companies) where you need complex UI in vscode. But to make it easy for user you want to bundle the server process (Blazor app) in the extension installer, again size matters when compared to other solutions.

[maloo]

Somewhat related to CLI UI, I think it was a big oversight to stop Steve Sandersons webview2 app. It would have opened up lots of new use cases. Again size matters, so MAUI is way overkill/bloat (and no trimming I guess) when all you want is a native html view for your Blazor app. Photino should be a part of Blazor in .NET to solve the desktop and cross platform UI gap in .NET after MAUI failure. https://www.tryphotino.io/

[ivanjx]

will this also cover the WebView component to be native aot friendly? it seems that native aot wont work on libraries like Photino.Blazor which uses that component.

[danroth27]

will this also cover the WebView component to be native aot friendly? it seems that native aot wont work on libraries like Photino.Blazor which uses that component.

@ivanjx No, this issue is specific to Blazor web apps (although there may be some overlap with the work). For Native AOT support for the various BlazorWebViews I recommend opening a new issue in the dotnet/maui repo.