The Unity is dead, long live.... ? DryIoc?

[the-black-wolf]

Apparently, the entire Unity project has been abandoned and is being allowed to die off (more info on links):

NuGet Gallery: Unity 5.11.10
Unity Container: Project Sustainability

While this is a sad state of affairs, we do understand the reasons behind it, we had our fair share of .net team introducing breaking changes in the chain, supporting a complex library requires a lot of dedication.

That being said, we do not wish to linger for too long on an unsupported IoC engine for our WPF LOBs. I see in the Prism docs that you also directly support DryIoc, so is that a recommended way to migrate?

Has anyone done this and what are the "gotchas"?

[Friendship7]

As I got the news that Unity has been abandoned, I was also forced to take the decision to move on to another IoC engine. Since DryIoC seems to be the only viable solution, I gave it a try. Adapting my rather big codebase of Prism-applications to work with DryIoC was way more easy then I expected and I did not encounter any "gotchas".

[the-black-wolf]

@Friendship7 ok, thanks. we just converted our suite and it works just fine. It was actually good exercise, we discovered some antipatterns with service locators as well ;)

[the-black-wolf]

In case someone comes here to check, there is one difference between the two. DryIOC will refuse to instantiate an internal class with an internal constructor, it will ignore all internal constructors. Internal classes with public constructors will work. This is in contrast to Unity which allowed internal/internal combos. Not a big deal, just so you know in case you encounter "Cannot find ctor" error from DryIOC

[dansiegel]

This is only partially true... that has more to do with our default configuration. You should be able to overcome this by passing in custom rules.

protected override IContainerExtension CreateContainerExtension() =>
    new DryIocContainerExtension(DryIocContainerExtension.DefaultRules
        .With(Made.Of(FactoryMethod.ConstructorWithResolvableArgumentsIncludingNonPublic)));

[the-black-wolf]

@dansiegel its not a big problem, we switched constructors to public anyway.

[the-black-wolf]

@dansiegel
We also discovered we can just override the rules and leave the container creation to Prism.DryIoC.PrismApplication

protected override Rules CreateContainerRules() =>
   DryIocContainerExtension.DefaultRules.With(Made.Of(FactoryMethod.ConstructorWithResolvableArgumentsIncludingNonPublic));