Prism.Wpf/Prism.Unity 8.1.97 with custom DI container

[td3466]

Hi, I'm wondering if someone can point me in the right direction.
I have been following this link as best I can to use a custom container with Prism (https://prismlibrary.com/docs/dependency-injection/add-custom-container.html).

I'm not an expert, but what I'm finding is that when doing this, I need to register some classes manually with the container from the RegisterTypes method (mainly the RegionAdapters and the Behaviours) otherwise an exception is thrown saying the type doesn't exist in the container (if there might be a cleaner way to do that please let me know).

    protected override void RegisterTypes(IContainerRegistry containerRegistry)
    {
        if (!unity)
        {
            containerRegistry.Register(typeof(SelectorRegionAdapter));
            containerRegistry.Register(typeof(ItemsControlRegionAdapter));
            containerRegistry.Register(typeof(ContentControlRegionAdapter));

            containerRegistry.Register(typeof(DelayedRegionCreationBehavior));
            containerRegistry.Register(typeof(BindRegionContextToDependencyObjectBehavior));
            containerRegistry.Register(typeof(RegionActiveAwareBehavior));
            containerRegistry.Register(typeof(SyncRegionContextWithHostBehavior));
            containerRegistry.Register(typeof(RegionManagerRegistrationBehavior));
            containerRegistry.Register(typeof(RegionMemberLifetimeBehavior));
            containerRegistry.Register(typeof(ClearChildViewsRegionBehavior));
            containerRegistry.Register(typeof(AutoPopulateRegionBehavior));
            containerRegistry.Register(typeof(DestructibleRegionBehavior));

            containerRegistry.Register(typeof(Shell));
            containerRegistry.RegisterInstance(typeof(IContainerExtension), containerRegistry);
        }
    }

After all the types are manually registered so there are no more exceptions, it displays the Shell. The Shell has 3 regions defined, 1 for a ribbon accross the top, 1 for a statusbar accross the bottom and 1 for a main content area (I'm not trying to load the actual controls for these regions just yet, haven't gotten that far).

    <ContentControl Grid.Row="1" x:Name="ribbon" prism:RegionManager.RegionName="ribbonRegion" />
    <ItemsControl Grid.Row="2" x:Name="dock" prism:RegionManager.RegionName="dockRegion" />
    <ContentControl Grid.Row="3" x:Name="status" prism:RegionManager.RegionName="statusRegion" />

What I find is that only 1 region is actually created in the RegionManager when the Shell Window is shown, and only the one for the last control defined (ie: statusRegion in the xaml exerpt above).

if I use the default container (Ie: Unity), all 3 regions are created in the RegionManager; is there a type that may not be registered in the DI container?

I have tried Prism.Wpf and Prism.Unity nugets, and get the same result. I have tried using the regionManager.RegisterViewWithRegion from the Shell constructor to no avail. I have also tried regionManager.Regions[regionName].Add(view) but because the regions don't exist that throws an exception. I tried debugging the code, but it's a bit too advanced for me (I got stuck trying to follow it through the DelayedRegionCreationBehavior class).

Any thoughts as to what I'm missing? Any help greatly appreciated.
Troy.

[dansiegel]

@td3466 based on your title alone what you are asking "How do I drink water from a glass of Coca Cola?"

Prism.Unity is an implementation of the IContainerExtension using the Unity Container. Now you do have the ability to further customize the behavior of the Unity Container and pass that into the the UnityContainerExtension, however that is 100% not the same thing as adding a custom container as defined by the docs that you referenced.

If your goal is to add a custom container then you should be referencing Prism.Wpf and NOT Prism.Unity.

Keep in mind that for Prism to work correctly we additionally ensure that the settings of the underlying container will:

• Automatically resolve any Concrete (non-Abstract) type (i.e. your ViewModels)
• We prefer that in the event a service has more than one constructor it will fall back to one which it can construct if it does not have what it needs for the default constructor it selected.
• We prefer that the container automatically will resolve <T>, <Lazy<T>>, & <Func<T>> while only registering <T>
• Prism does require the ability to Register/Resolved named types. Without this Navigation will not work. Whatever container you choose must support this.
• While only DryIoc currently supports this, we also prefer that the container supports a ResolveAll<T> or Resolve<IEnumerable<T>>. This enables support for scenarios where you may have an IVehicle with registered implementations for Car, Truck, Bus. This allows you to get the full list of registered IVehicle's when resolving <IEnumerable<IVehicle>> and getting the last registered implementation of IVehicle when resolving <IVehicle>
• The container must also provide mutability. This means that you must be able to Register Services... Resolve Services... and then Register additional Services. Containers like Autofac, or Microsoft.Extensions.DependencyInjection are Immutable Containers and not compatible with Prism.

[td3466]

Appreciate the reply Dan,
The problem I'm really trying to get around is the regions not being created as expected.

I created a Prism.Wpf project, that uses a custom container, and only 1 region is getting created as initially described.

I then created a Prism.Unity project to see if the 3 regions got created as expected, which they did.

So I'm trying to understand what would be different, and the container used looks like the major difference at the moment. Could the difference be there are classes registered in the container created by the Prism.Unity project, that may not be present in the project using Prism.Wpf? When using custom containers do we need to tell it to register all the types in particular prism assemblies at all?

Could there be something not related to the containers that would prevent the regions being created?

[spassm]

Hi @dansiegel,

I am very appreciate to use Prism in WPF Apps (started use Prism a long time ago, I guess more than 7 years ago).
My personal opinion about IoC libs is immutable containers are popular in enterprise usages and I think if Prism will provide support for this kind of containers will be very cool.

I faced with the same issue what described here and I will be very glad to see support immutable container out of the box.
I do not want start "holy war" about what is the best - mutable or immutable containers approach, but I guess support of both kinds will dramatically increase usages of Prism, is not it?

What do you think?
Thank you!

[brianlagunas]

Certain features of Prism, like modules, literally cannot work with an immutable container.

[dansiegel]

I will be very glad to see support immutable container out of the box

Never going to happen the concept of an Immutable Container is fundamentally incompatible with Prism's concept of Modularity. To begin with Prism has to resolve the Module Catalog for you to register the Modules. Prism then has to resolve the Module Manager in order to activate it moduleManager.Run()... and then the Module Manager has to resolve the Module in order for you to Register additional types...

[dansiegel]

I'll add the argument for Immutable Containers is generally around performance... but you can just use an awesome container like DryIoc which beats all of the Immutable Containers on performance.

[spassm]

@brianlagunas @dansiegel
I hope you all are well!
And thanks for quick response!

Good point about modularity, but I think that we can create immutable container per module during load stage and use main app container as root container for each module nested container.
Because when we are defining dependencies for module we will have enough info about root container, module and module linked nested container to resolve correct instance.
I am about child containers in Autofac and MS DI Extensions for example.

[spassm]

Hi guys,
Just few more notes from my side:

• Autofac has 128 M downloads vs DryIoc - 3 M downloads
• Modularity is very closer to hierarchy approach and Autofac supports hierarchy

I guess this info is enough to think about Immutable IoCs support in Prism.

Best regards and good luck!