DryIoc vs Unity

[EuroEager2008]

This bug report: #3089
was immediately closed because I couldn't easily describe a repro (I thought I had to expose my clients assemblies to do that).

Just for the sake of order, I found out myself and perhaps other struggle (or perhaps it is so obvious to all other, but myself):
Unity accepts to resolve types with non-public constructors (at least internal is ok), however DryIoc throws a ContainerResolutionException if constructors are not public.

[dansiegel]

DryIoc does in fact support it, we just haven't had it configured by default. If this is something you need you can provide the rules like:

var rules = DryIocContainerExtension.GetDefaultRules()
    .With(Made.Of(FactoryMethod.ConstructorWithResolvableArgumentsIncludingNonPublic))

If I see some interest in having this be the default behavior it's something we can consider. In general though you are far better off with DryIoc. Unity is out of active development and there are a number of features it does not support.

[EuroEager2008]

Thanks Dan
Would you care to hint about the "correct" location of this rule setting?
Also please be aware that I am using Prism 8.
It seems like the GetDefaultRules() method doesn't exist, but the DefaultRules property exists, however, the Create method of PrismContainerExtension is not available (needed for applying the rules I guess).

I find it natural to have a project for each module and making the classes and constructors internal if used only internally within the module, that is why I faced the problem in the first place.
I will check a bit to see if it makes sense (classes are e.g. internal anyway). I assume private constructors cannot be resolved(?)

[EuroEager2008]

Did find out about rules settings (CreateContainerRules())
However, have been thinking about it and done some tests and found that I don't want to set this rule for the following reasons:
It enables resolving private constructors
Most important: it leads to a dependency to a certain container (DryIoc in this case).

Anyway, thanks a lot for your concern

[dansiegel]

if used only internally within the module

So the short answer is you should actually never use a container specific package for a Module. You should only have this in the application head where your App (or Bootstrapper for WPF) is located while using only the Abstractions for a Module.

Also remember that the Unity Container is effectively dead and it seems very unlikely that there will be another version released. While it is "stable" it also lacks a number of important features which is why you'll notice we do not ship support for Unity with MAUI and Uno Platform. It is only provided for WPF and Xamarin.Forms for legacy support but we do not recommend that you develop apps with it, and I would actually recommend that you migrate off of Unity for a number of reasons including perf.

If you have a Commercial Plus license then you do get access to Grace IOC and Microsoft.Extensions.DependencyInjection as backing containers for Prism. We are currently considering additional containers as well.