Annotate top-level methods that aren't native AOT friendly as such so that analyzers produce warnings at design time

[DamianEdwards]

While we have issues tracking specific work to annotate the rest of the ASP.NET Core API surface area for trim and native AOT friendliness, as it is right now, enabling trimming or native AOT publish in an ASP.NET Core project often doesn't result in many (if any) warnings appearing during design-time or compile-time.

To improve the experience right now (e.g. in preview.4), we should consider annotating the top-level entry methods to the various large sub-systems of ASP.NET Core to that if they're called in apps configured for trimming or native AOT publish, the user gets appropriately warned that those sub-systems aren't supported when aggressively trimmed.

E.g. calling the following methods should trigger a warning as the various sub-systems they relate to aren't currently supported with full trimming and/or native AOT publish:

builder.Services.AddAuthentication(); // Authentication
builder.Services.AddRazorPages(); // Razor Pages
builder.Services.AddControllers(); // MVC Controllers
builder.Services.AddControllersWithViews(); // MVC
builder.Services.AddServerSideBlazor(); // Blazor Server
builder.Services.AddRazorComponents(); // Blazor United
builder.Services.AddSignalR(); // SignalR
builder.Services.AddSession(); // Session
builder.Services.AddRequestLocalization(o => { }); // Request localization

Should we consider doing the same in EF Core?

[davidfowl]

This feels backwards. Does it mean that when we add any new API we have to mark it as [RequiredUnreferencedCode]? I'm not familiar with how the analyzer works but if it forces all callers to also mark their APIs this way then it means that all APIs end up being forced to add this attribute as well right?

[DamianEdwards]

My understanding is that the analyzer only warns based on the annotations on APIs you explicitly call, e.g. if you create a new API app with native AOT configured (dotnet new api -aot) and add the two calls to enable MVC controllers, and add a single controller that returns an IActionResult, you get no analyzer warnings at design time or compile time.

[eerhardt]

Does it mean that when we add any new API we have to mark it as [RequiredUnreferencedCode]?

No, it doesn't mean that. But what it DOES mean is that if code that your API references has trim/aot warnings, your API itself should be marked RequiredUnreferencedCode. That way callers of your API know that your API isn't guaranteed to work during dotnet build time (when the Roslyn Analyzers run).

The way we have it today means that devs won't see these warnings until dotnet publish time. We want them to know earlier what they are doing isn't guaranteed to work.

Today UseMvc() calls code that has warnings in it, but UseMvc() itself isn't annotated as being unsafe.

I'm not familiar with how the analyzer works but if it forces all callers to also mark their APIs this way then it means that all APIs end up being forced to add this attribute as well right?

The Roslyn Analyzers can only analyze code that is being compiled. It can't analyze the code contained inside referenced assemblies. dotnet publish will analyze all code in the app, no matter where it came from.

The goal with this issue is to "shift left" the warnings, so devs get them earlier in the dev cycle. They don't need to publish to know that UseMvc() isn't going to work.

[eerhardt]

Closed as completed via #47663