Support DI Container mutability

[dansiegel]

Description

Currently the container provided by Microsoft.Extensions.DependencyInjection provides an immutable container. By design this makes sense for Web Applications where this was originally designed for. However for desktop and mobile apps there needs to be a way to configure the container to support mutability. This is a blocker for Prism which depends on registering core services, adding modules and then being able to dynamically load those modules after the container has been initialized. For instance the way Prism works we initially register the core services like so:

c.RegisterSingleton<IModuleManager, ModuleManager>();
c.RegisterSingleton<IModuleCatalog, ModuleCatalog>();
c.RegisterSingleton<IModuleInitializer, ModuleInitializer>();

Then once the initial services are registered as the application is initializing the bootstrapper will provide a callback for the developer to configure the ModuleCatalog like:

// Prism Code:
// RegisterRequiredTypes: See above sample
RegisterRequiredTypes(_containerExtension); 

// Developer can register their core services and override Prism default services
RegisterTypes(_containerExtension); 

// Effectively where we would go from IServiceCollection to IServiceProvider
_containerExtension.FinalizeExtension();

// Resolves either the default Prism implementation or developers implementation
_moduleCatalog = Container.Resolve<IModuleCatalog>();

// See below
ConfigureModuleCatalog(_moduleCatalog);

// This is where it blows up due to immutability
InitializeModules();

// Developer Code:
protected override void ConfigureModuleCatalog(IModuleCatalog catalog)
{
    catalog.AddModule<ModuleA>();
}

In the case of Microsoft.Extensions.DependencyInjection this causes a failure in the InitializeModules step as each module will be first resolved and then have the opportunity to add additional dependencies. We would really like to add support to Prism for Microsoft.Extensions.DependencyInjection however this is one of 2 significant blockers for us.

• blocks [Enhancement] Support Microsoft DI (added in .NET 8) PrismLibrary/Prism#2922

Tagging subscribers to this area: @dotnet/area-extensions-dependencyinjection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Currently the container provided by Microsoft.Extensions.DependencyInjection provides an immutable container. By design this makes sense for Web Applications where this was originally designed for. However for desktop and mobile apps there needs to be a way to configure the container to support mutability. This is a blocker for Prism which depends on registering core services, adding modules and then being able to dynamically load those modules after the container has been initialized. For instance the way Prism works we initially register the core services like so:

c.RegisterSingleton<IModuleManager, ModuleManager>();
c.RegisterSingleton<IModuleCatalog, ModuleCatalog>();
c.RegisterSingleton<IModuleInitializer, ModuleInitializer>();

Then once the initial services are registered as the application is initializing the bootstrapper will provide a callback for the developer to configure the ModuleCatalog like:

// Prism Code:
// RegisterRequiredTypes: See above sample
RegisterRequiredTypes(_containerExtension); 

// Developer can register their core services and override Prism default services
RegisterTypes(_containerExtension); 

// Effectively where we would go from IServiceCollection to IServiceProvider
_containerExtension.FinalizeExtension();

// Resolves either the default Prism implementation or developers implementation
_moduleCatalog = Container.Resolve<IModuleCatalog>();

// See below
ConfigureModuleCatalog(_moduleCatalog);

// This is where it blows up due to immutability
InitializeModules();

// Developer Code:
protected override void ConfigureModuleCatalog(IModuleCatalog catalog)
{
    catalog.AddModule<ModuleA>();
}

In the case of Microsoft.Extensions.DependencyInjection this causes a failure in the InitializeModules step as each module will be first resolved and then have the opportunity to add additional dependencies. We would really like to add support to Prism for Microsoft.Extensions.DependencyInjection however this is one of 2 significant blockers for us.

• blocks [Enhancement] Support Microsoft DI (added in .NET 8) PrismLibrary/Prism#2922

Author:	dansiegel
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[rogihee]

Another good scenario would be Blazor WebAssembly with Lazy Loading. With Lazy Loading you can dynamically load a dll that may not necessarily have services for the DI container but most of the time will.

[steveharter]

Another good scenario would be Blazor WebAssembly with Lazy Loading.

Yes see #85907:

To keep initial download time down, Blazor WASM allows us to modularize our applications and then have those modules downloaded when the user needs something within them. Unfortunately, there is currently no way for IServiceProvider to do the same. So when an app's modules are loaded (Blazor or otherwise), none of the injected dependencies they hold can be registered.

which was closed as a duplicate for this issue