Consider using `PublishAot` for Mobile Platforms and Blazor WASM

[agocke]

Android currently uses the property AotAssemblies. PublishAot seems to do the same thing. Maybe we should accept either for Android, to provide uniformity. Same with Blazor, which uses RunAOTCompilation.

[agocke]

@marek-safar @steveisok Thoughts on the above switch for controlling AOT across Android, iOS, wasm, and NativeAOT?

[steveisok]

Within mono (and Blazor), RunAOTCompilation has been the property we use to run AOT. Naturally, that would be my preference everywhere as (to me) it's clear irrespective of where it runs. We can run aot both during build and publish.

I'm pretty sure AotAssemblies was a holdover from what was done in legacy xamarin-android. @jonathanpeppers can probably fill in the details there.

@lewing Any thoughts?

[agocke]

also + @jkotas @samsp-msft @richlander @vitek-karas

[lewing]

I think there are still distinctions we need to address with build vs publish but I'm also not attached to a particular property name as long as the old one continues to work since it is in net6 for wasm

• @danroth27 @radical

[agocke]

Yup, no breaking changes suggested here, just a proposal that it would be nice if we could settle on a uniform name for the future.

PublishAot is the suggestion from NativeAOT because it matches PublishSingleFile, PublishTrimmed, and PublishReadyToRun. There's also good reason to put the line directly in the project file, as it should enable the appropriate analyzers. The build/publish UI decision isn't one I really plan to revisit here, but it's worth noting that for NativeAOT, AOT will only happen during publish. I don't know if that's true for these other scenarios.

[radical]

PublishAot is the suggestion from NativeAOT because it matches PublishSingleFile, PublishTrimmed, and PublishReadyToRun.

I like PublishAot, as it also makes it very clear that it will be done only at publish time.

If this is for mobile, then would PublishAotBundle be better?

[agocke]

Is it common to publish AOT without bundling in mobile?

[steveisok]

No, it's usually done as a step towards producing a bundle.

[agocke]

In that case, it sounds like PublishAot should probably imply creating a bundle. If it's not a common scenario to do otherwise, it seems like it would simplify things (and it's a shorter name).

[vitek-karas]

Note that even in NativeAOT PublishAot effectively implies a bundle, in the sense that all of the code in the app is bundled into one executable. Behavior-vise it implies PublishSingleFile (not in implementation though). PublishAot will also set EnableSingleFileAnalyzer (since the app will behave as single-file), this would also make sense for Blazor/Xamarin.

We plan to add guards into the SDK to prevent combinations which don't make sense. For example setting PublishAot=true and PublishSingleFile=false (and several others).

[jonathanpeppers]

AotAssemblies was the setting from Xamarin.Android. We kept it in .NET 6, just to help with developers migrating.

If you use the Project Options screen in a MAUI or .NET 6 Android project:

This setting toggles RunAOTCompilation.

In Android projects dotnet build creates a runnable Android app. There really isn't a great reason to use dotnet publish on an Android project, all it does is copy the same files dotnet build produces to $(PublishDir). If I was setting up an Android CI pipeline, the simplest setup is set a $Configuration env var to Release, dotnet build, and then archive any .apk or .aab files as artifacts.

If we pick something for AOT "the official name", I would suggest we use it for all platforms. It would be nice if you could dotnet publish -p:PublishAot=true a .sln and all projects could output their binaries to $(PublishDir).

We also should continue supporting RunAOTCompilation for a period of time? Android can also deprecate/remove AotAssemblies in .NET 7.

[agocke]

In Android projects dotnet build creates a runnable Android app

Right, this is a significant difference between the publish model for net* projects and android (and maybe wasm?) projects -- changing the configuration will change optimization levels, but won't do extra artifact deployment steps, like AOT or R2R or creating NuGet packages. The gesture we use for that right now is publish. I don't really know how to reconcile the differences between project types here.