Wow, does this actually work? Is the trick that it already pre-creates a scope during initialization? I wonder, are there any downsides to that?

There are some random test failures, but also I see two legit ones where probably just the tests need to be updated:

1. CreatesServiceProviderByDefault

Assert.IsType() Failure: Value is not the exact type
Expected: typeof(Microsoft.Extensions.DependencyInjection.ServiceProvider)
Actual: typeof(Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope)

Stack trace
at Microsoft.Maui.UnitTests.Hosting.HostBuilderConfigureContainerTests.CreatesServiceProviderByDefault() in /Users/builder/azdo/_work/1/s/src/Core/tests/UnitTests/Hosting/HostBuilderConfigureContainerTests.cs:line 17
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

2. ConfigureContainerCanReplaceIServiceProvider

Assert.IsType() Failure: Value is not the exact type
Expected: typeof(Microsoft.Maui.UnitTests.Hosting.HostBuilderConfigureContainerTests+MyServiceProvider)
Actual: typeof(Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope)

Stack trace
at Microsoft.Maui.UnitTests.Hosting.HostBuilderConfigureContainerTests.ConfigureContainerCanReplaceIServiceProvider() in /Users/builder/azdo/_work/1/s/src/Core/tests/UnitTests/Hosting/HostBuilderConfigureContainerTests.cs:line 37
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

As far as I understand, this PR enables scopes validation during the development of MAUI itself.
But the original issue is about validation in Debug mode for user's apps. So I'd suggest to keep that linked issue open after merging this PR.

Btw, does it make sense to include registered services validation (i.e. that all the dependencies are registered for all the services)?
You can do that like that:

 containerBuilder.BuildServiceProvider(new ServiceProviderOptions
{
	ValidateScopes = true,
	ValidateOnBuild = true
});

There's a potential issue with the current implementation.
ServiceProvider is disposed when MauiApp is disposed. But in this case it's not the root container which is disposed, but only scoped one. I assume that will lead to singleton services being never disposed.

Indeed, @Dreamescaper points are I think both critical:

1. It must be user-configurable to decide whether scope validation is enabled. For example, it's often enabled in debug mode, and disabled in release mode (there's a perf cost to it)
2. Gotta dispose the disposables!

Indeed, @Dreamescaper points are I think both critical:

1. It must be user-configurable to decide whether scope validation is enabled. For example, it's often enabled in debug mode, and disabled in release mode (there's a perf cost to it)
2. Gotta dispose the disposables!

1. yea, I think this is a .NET9 problem though since we've closed shop for .NET8. I don't think we can move the cheese like this currently.

As far as I understand, this PR enables scopes validation during the development of MAUI itself.

Yea, the first step here is just making sure that MAUI itself isn't violating the rules so if users opt in for the validation through the mechanisms that @Foda has shown in the PR that it'll work for users.

/rebase

/rebase

Unless I'm missing something, resolving scoped services will always be "valid" after this change unless there are resolved using MauiApp.Services.GetService(type). Is this common? If not, I don't see the point of the additional complexity of exposing both unscoped and application scoped providers. We might as well make MauiApp.Services scoped too and forget about validation altogether.

The main scenario I think that validation will cover is if you resolve a singleton service with a scoped constructor argument. Something like this

	public static class MauiProgram
	{
		public static MauiApp CreateMauiApp()
		{
			var builder = MauiApp
				.CreateBuilder()
			        .UseMauiMaps()
			        .UseMauiApp<App>();

			builder.ConfigureContainer(new DefaultServiceProviderFactory(new ServiceProviderOptions
			{
				ValidateOnBuild = true,
				ValidateScopes = true,
			}));

			builder.Services.AddSingleton(typeof(Singleton));
			builder.Services.AddScoped(typeof(ScopedService));			
			
			// crashes because the ctor on singleton has a scoped service
			var app = builder.Build();

			app.Services.CreateScope().ServiceProvider.GetServices<Singleton>();
			return app;
		}
	}

	public class ScopedService
	{

	}

	public class Singleton
	{
		public Singleton(ScopedService service) 
		{ 
		}

	}

I don't see the point of the additional complexity of exposing both unscoped and application scoped providers. We might as well make MauiApp.Services scoped too and forget about validation altogether.

This was our initial approach
a8eb11d

but @eerhardt expressed concern so I took at stab at modifying this PR so the MauiApp.Services remains unchanged and then we just modify at a more specific point, which is when we create the MAuiContext. The MauiContext being scoped is already somewhat of a pattern inside MAUI. For example, we scope a new MauiContext for each window that gets created

so it somewhat made sense to me that we could do the same with the MauiContext that gets passed in at the application level.

all that being said :-) I don't quite see the difference between the complexity of this approach vs our first approach just making the MauiApp.Services scoped.

The only difference I can think of there is that if someone were to do

MauiApp.Services.GetService<ScopedService>

if we keep MauiApp.Services as the root container that will throw an exception whereas if the root container is also the scoped service then it won't throw an exception. So, it does protect if someone uses the MauiApp level service to service locate a scoped service.

Also, did we miss a call to the MauiContext ctor in our own Tizen code?

I moved the code for creating the app scope to MakeApplicationScope which should now simplify and just cover all cases

/rebase

Trying a different approach here
#19593