Future of Prism with Unity Container

[MartinEgli]

The UnityContainer project will not be developed further. What is the future of Prism? We have already lost compatibility with Autofac in the past. Is DryIoc the last IoC container? Can prism Comunity help the Unity Container project?

[dansiegel]

Ultimately this isn't something that we can answer outright at the moment. This will be something that @brianlagunas and I will talk about on an ongoing basis.

For now, it is safe to assume that DryIoc will be the only container supported for Prism.Maui particularly as we needed some features that were slated for Unity 6 to support MS DI/Shiny. We will also likely add an updated deprecation notice for all Unity Container based packages.

Do note that there are some differences between the Unity Container and both Autofac and Ninject which we have previously deprecated. Autofac was deprecated due to them fundamentally changing the way the container behaved from a mutable to an immutable container. That pattern simply cannot support Prism Modularity. Ninject was effectively abandoned during the swap to netstandard, and no usable package was ever produced that would properly support all platforms.

In the case of the Unity Container, there are some missing features which would help developers for sure, however the package itself remains stable and usable for continued use at this time. It will ultimately up to you and your team whether you want to take a dependency which includes the Unity Container as a now deprecated package. For many enterprises this will create a security concern and they would want to look at using DryIoc or implementing IContainerExtension for their container of choice.

Lastly let me address the question is this something the Prism Community can help with? The short answer is that neither @brianlagunas or I will be taking on the additional workload of supporting a DI container. We are both already over extended. The deprecation of the Unity Container is a good reminder for all in the .NET Community that they need to stand up and help support OSS Maintainers. We do have day jobs that we rely on to support ourselves and our families. That will ALWAYS take priority over an OSS project. Whether for Prism, the Unity Container or any other OSS project you depend on there are several ways that you and your employer can support OSS.

1. Instead of just reporting an issue.. take ownership and submit PRs

• Instead of complaining that the docs suck... help fill in the holes where YOU can. Set the example and so others might do the same and fill in the holes you can't.

2. Have your employer dedicate time for you to help work on OSS projects that your company depends on.
3. Become a personal GitHub Sponsor &/or have your company become a GitHub Sponsor of the Projects/Maintainers that you rely on.
4. In the case of the Unity Container specifically you might consider offering help by forming a group who is willing to take on the burden of maintaining the project yourselves.

[MartinEgli]

Thank you for your answer @dansiegel

I work in the machine industry and I know many projects that are based on prism. Because in the machine industry many are still based on .net framework 4.5 to 4.8. Platforms like .net 5.0 or 6.0 are currently not an issue and microsoft has announced .net 4.8 for 2031. Manufacturers such as Siemens are still based on Windows 10 IoT 2016 LTSB today. The migation to .Net will be prutal, since .Net 10 is estimated to be up to date in 2031. We are running our own nuget server, the use of nuget will be extremely distorted. We download a nuget package only once, but use it within the company projects. This cash distorts the statistics of a package. For machine industry oss still difficult, because the fear of knowledge loss is present. Employees are also forbidden to collaborate on oss. I am a big fan of prism, but am afraid that soon there will be no compatible DI. We have made migrations from MEF to Autofac to Unity and now to DryIoc. What is next?

You ask me, "Finally, I would like to address the question of whether the Prism community can help with this." I ask: Can Prism Community exist without compatible DI?

There are many users of Prism and Unity who are not aware of the situation. Companies use oss without seeing the effor that many extraordinary developers provide every day. In our country, unfortunately, they say: "what costs nothing, is worth nothing". Complete nonsense!

How can we all work together to find a solution while supporting our families and fellow human beings?

Only we together create the better future!

[Friendship7]

After reading the original post from Martin Egli, which was somehow alarming for me because I also have two rather large Prism+WPF projects that rely on Unity, I gave it a try to replace Unity with DryIoc in one of them. For the most part it was quite easy, after getting used to the semantics of DryIoc. There were some tricky spots, but fortunately with some reading of the documentation I was able to make them work as well. The most important thing is to understand the differences in the lifetime management so that after the transition singletons are still resolved as singletons and transient instances as new instances. If Unity in the application is accessed over the IoC abstraction layer of Prism it becomes fairly easy to migrate even big solutions to DryIoc.

In trying this with the aforementioned application, I also found some benefits in doing so. Some registration code got more readable and also the performance of the application got slightly improved.

In case you are interested, I found this benchmark of most .NET IoC Containers, which also shows that in terms of performance a migration to DryIoc could be beneficial.

[dansiegel]

It's important to consider if you use Prism's IoC abstraction layer, then switching containers is easy and painless. In fact if you look at our WPF E2E apps you'll see that the one using the PrismApplication and the one using the PrismBootstrapper use different containers but actually share the same module because all of the registrations are with Prism's abstractions. This is a really great way to future proof yourself ensuring that your code doesn't need to change even if you need to switch to another container in the future.