Updating .NET MAUI to use MauiApp/MauiAppBuilder pattern and use MS.Extensions.DependencyInjection

[Eilon]

What's new/different:

• Each platform-specific application type is abstract and has an abstract method protected abstract MauiAppBuilder CreateAppBuilder(); that is overridden in the user's app to create and return a MauiAppBuilder.
• The IStartup interface is removed, and the user's app startup is in a conventional MauiProgram class with a static method that creates the app builder and returns the built MauiApp.
• MauiAppBuilder is akin to ASP.NET Core's WebApplicationBuilder and has properties, methods, and extension methods for setting up the app. For example, registering services, fonts, handlers, etc.
• All of Microsoft.Extensions.DependencyInjection's features are supported (constructor injection, enumerable multi-services, open generic registrations, etc.).

Before:

	// Platform-independent app setup
	public class Startup : IStartup
	{
		public void Configure(IAppHostBuilder appBuilder)
		{
			appBuilder
				.UseMauiApp<App>()
				.ConfigureFonts(fonts =>
				{
					fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
				});
		}
	}

	// Each platform (WinUI/Android/iOS/MacCatalyst) has something like this:
	public class MainApplication : MauiApplication<Startup>
	{
		...
	}

After:

	// Platform-independent app setup
	public static class MauiProgram
	{
		public static MauiApp CreateMauiApp()
		{
			var builder = MauiApp.CreateBuilder();
			builder
				.UseMauiApp<App>()
				.ConfigureFonts(fonts =>
				{
					fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
				});
			return builder.Build();
		}
	}

	// Each platform (WinUI/Android/iOS/MacCatalyst) has something like this:
	public class MainApplication : MauiApplication
	{
		...

		protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp();
	}

Please share feedback in this PR, either in general, or on specific lines of code.

[Eilon]

All the stuff I said was un-done is now done. Support for IHost, IHostBuilder, custom DI, config is all done (by copying stuff from AspNetCore). I believe that all tests pass because they did pass locally not long ago, and CI seems fairly happy, aside from things that are flaky even in main. There is likely still some bug in the code anyway, which I will continue to hunt down.

What's left now?

• Finalize naming of major public types, such as MauiAppBuilder (though this type name is rarely seen in user code), and MauiApp (which is typically seen at least once in projects to create the builder).
• Lots of code cleanup to do (rename files/types, etc.), but I would much rather wait until the rest is committed before getting to that because I tried to keep things in such a way that I could more easily keep re-basing on main. (If I move things too much, it's nearly impossible to rebase.)
• Add any new tests that are needed. (Almost all existing tests continue to exist and were merely updated; a few that are not relevant anymore were deleted.)
• Project template updates (this is trivial, and I'm also delaying it to avoid merge conflicts_

@Redth / @PureWeen / @rmarinho / @mattleibow / @davidfowl - I would love your feedback on what we've got here so that we can get this into RC1.

[Eilon]

Local test pass in WinUI SLN (everything passes except some tests that aren't supposed to pass locally, and I don't know how to run DeviceTests).

[Eilon]

And for fun I just tried using Autofac as the DI container and it seems to work great when I run in Android! I referred to the Autofac docs for ASP.NET Core because that's the pattern in this PR for .NET MAUI.

I added a reference to this Autofac package:

    <PackageReference Include="Autofac.Extensions.DependencyInjection" Version="7.1.0" />

And here's what I changed in Startup.cs to make use of Autofac:

using Autofac;
using Autofac.Extensions.DependencyInjection;

...

	public static MauiAppBuilder CreateAppBuilder()
	{
		var appBuilder = MauiApp.CreateBuilder();

		// Before (with Microsoft.Extensions.DependencyInjection registration):
		//appBuilder.Services.AddSingleton<ITextService, TextService>();
		//appBuilder.Services.AddTransient<MainViewModel>();

		appBuilder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory(containerBuilder =>
		{
			// After (with Autofac registration):
			containerBuilder.RegisterType<TextService>().As<ITextService>().SingleInstance();
			containerBuilder.RegisterType<MainViewModel>().AsSelf().InstancePerDependency();
		}));
		...
	}

And all the rest of the registrations in the app were done using MS.Ext.DI registration because it's mostly various .NET MAUI and Blazor stuff.

[mattleibow]

@Eilon you can run device test by just launching those apps. It is just a normal maui app with a UI and everything. There is a "Run All" button.

[Eilon]

I just had a great meeting with @halter73 from the ASP.NET Core team to review some of the patterns here.

These are my notes to investigate and implement from the feedback in this PR from various folks and also from my meeting with @halter73 .

• Make sure all framework code uses services.TryAddXyz(...) and services.TryAddEnumerableXyz(...) to avoid multiple registrations of the same service
• Have the user's MauiProgram class call .Build() on the MauiAppBuilder and return the constructed MauiApp. This makes it clearer to the user that they fully baked the app themselves and the framework isn't going to do magic on it later. This is also more similar to ASP.NET Core.
• Consider naming of the .NET MAUI per-platform application base types in terms of consistency across platforms and in terms of using up the "good" names for types that are almost never seen. For example, on WinUI there's MauiWinUIApplication, on Android there's MauiApplication, on iOS/MacCatalyst there's MauiUIApplicationDelegate. Perhaps these should either use names more similar to each other (not just Maui prefixed to the base class), or at least not use up very generic names like MauiApplication that we could instead use somewhere else.
  • Moved to Consider changing the names of the native app base types (MauiWinUIApplication, MauiApplication, MauiUIApplicationDelegate) #2242
• Consider using the "good" application types names for the more user-seen parts of the app, and change MauiApp-->MauiApplication and MauiAppBuilder-->MauiApplicationBuilder
  • Blocked, pending resolution of app base type renames: Consider changing the names of the native app base types (MauiWinUIApplication, MauiApplication, MauiUIApplicationDelegate) #2242
• Look into using hosted services. This would replace the icky IMauiInitializeService that I added, and also to enable users to use hosted services. MAUI will automatically call StartAsync/StopAsync at the appropriate time. Sadly, this pattern is async-only, whereas in MAUI the call sites are always (or at least almost always) sync. But give that this is app startup/shutdown, doing async-over-sync might be OK (we would block).
  • Moved to Add support for hosted services in .NET MAUI apps #2244
• Add collections for Handlers, Fonts, and other collection-y things on MauiAppBuilder instead of the various ConfigureXyz methods. This is much simpler code for the user and avoids syntax goop that lambdas have.
  • Moved to Add MauiAppBuilder top-level properties for common features: Handlers, Fonts, etc. #2245

[mattleibow]

Great things in that last comment!

For the name we should at least have MauiAndroidApplication.

One thing that needs to be handled is the case on Android there are 2 parts: MauiApplication and MauiAppCompatActivity. And I think iOS/MacCatalyst will have the same with the UISceneDelegate when we get multi-window. It is not possible to have an Android app without both the Applictation (which runs everything up to Build()) and then Activity(which starts the UI process).

[PureWeen]

@mattleibow can we go with

MauiNativeApplication => AppDelegate, Android.App.Application, Application
MauiNativeWindow => SceneDelegate, Activity, Window

for everything? Possibly even drop the Maui prefix?

[mhutch]

This is great. I love the more straightforward imperative feel.

This gave me an idea for using top level statements. If the body of CreateMauiApp became top level statements, a source generator could generate the CreateMauiApp method from them. My initial thought was that this would be far too magical, but AFAICT we're already using source generators to obscure the real platform-specific entrypoints, and I don't think it's any worse than that.

[mattleibow]

@mattleibow can we go with

MauiNativeApplication => AppDelegate, Android.App.Application, Application
MauiNativeWindow => SceneDelegate, Activity, Window

for everything? Possibly even drop the Maui prefix?

YES! YES! and maybe!

We may want the Maui prefix to avoid clashes with other things the libraries do "Native" is very generic. But this is just my obsession with prefixes :)

NativeApplication is actually fine. I just had to write out that my deep-rooted, but still light (I hope), OCD wants things.

[rmarinho]

Not a fan of. the "Native" in the namings.. I think the most used api should be MauiApplication and MauiWindow in all platforms

[Redth]

This is great. I love the more straightforward imperative feel.

This gave me an idea for using top level statements. If the body of CreateMauiApp became top level statements, a source generator could generate the CreateMauiApp method from them. My initial thought was that this would be far too magical, but AFAICT we're already using source generators to obscure the real platform-specific entrypoints, and I don't think it's any worse than that.

@mhutch Yes, this would be awesome!

The idea was always to source gen the Activity/AppDelegate/etc parts eventually...

Last I looked at the top level statements, I don't think that source gen has access to know its namespace/type/method to be able to call it? I had thought the same once this PR was started - it would be really nice to have a top level statements file be called from the Activity/AppDelegate/etc entry points...

[mhutch]

Last I looked at the top level statements, I don't think that source gen has access to know its namespace/type/method to be able to call it? I had thought the same once this PR was started - it would be really nice to have a top level statements file be called from the Activity/AppDelegate/etc entry points...

IIRC the generated main method cannot be called from C#, but I assumed (maybe incorrectly) that source generators could inspect the syntax tree of top level statements like they can other code. If a source generator can inspect the top level statements, it can generate a new method with those same statements (and appropriate #line directives), and the linker can remove the unused entrypoint method. If that doesn't work, invoking the entrypoint method via reflection is a fallback option - not ideal, but a single reflection invocation is probably not a big deal - and if it is, we could have the linker optimize it into a direct call.

Another aspect to consider is how we would return the user-created app object from the top level statements so the generated CreateMauiApp method can return it to the caller. It also needs to make sense - even if we could do return app as a top level statement, that would be kind nonsensical as there's no context as to where the app is returned to and what happens next.

One way would be to generate a "return method" - a method the user must call on the app as the last toplevel statement. This could look like a mainloop, such as an app.Run() extension method, which would be cute but rather misleading about what's happening. Or we could be more explicit about what's happening e.g. Platform.HostApp(app). If we used the approach of generating a CreateMauiApp method from the top level statements, we could directly replace the return method method call with a return statement. If we take the other approach and have the generated CreateMauiApp method somehow invoke the actual entrypoint method, then the return method could stash the app on a private static field from where the CreateMauiApp could retrieve it and return it.

[Eilon]

@mhutch / @Redth - yes I'd love to see top-level statements and other simplifications in .NET MAUI! I logged #2243 to track this (I couldn't find an existing issue) because it's certainly out of scope of this PR, and I don't want to lose track of it.