UnityContainer was the first IOC container I learned to use, and I had different feelings for it. If there is a follow-up release, I'm willing to pay for it

I've tried to maintain Unity part time, but it introduced more issues than I fixed. It is a full time job.

I would love to continue work on the project, but unfortunately I can no longer afford sponsoring it on my own.

For me unity was the best container, the config in file help clean the code, I honestly tried to help but I coudn't solve the issues that I opened, and when I upgraded to .net core, all of my implementations stopped working, it's a shame that it's ending

Just checked as well, i presume the only change is to remove: { KeyPair = new StrongNameKeyPair(pair)

But it should be done with ifdef on .netcore probably (it might have meaning on .netframework)

@rizi Are you preparing a PR?

At the moment I'm on holidays and I have no access to an computer, maybe after my holidays. Is it still possible to create a PR? And would it be merged by @ENikS .

Br

I can confirm that moving it to
#if NET40 || NET45 || NET46 || NET47 || NET48 || NETFRAMEWORK allows us to continue working

Am I right that the project can be affected by this issue only when it's using Unity.Interception nuget and adding the extension like below?
container.AddNewExtension<Interception>();
@yfital @rizi

Am I right that the project can be affected by this issue only when it's using Unity.Interception nuget and adding the extension like below? container.AddNewExtension<Interception>(); @yfital @rizi

That's correct.
Br

fwiw we've been on .net 5 then .net 6 for months now using Unity with zero issues just not using that extension. We have no plans to migrate off of it anytime soon.

@ENikS what would you need to keep the project running (and up to date)?

br

Should we start crowdfunding? How much does it brew per year?

@IanKemp we have the latest unity version running with .Net 6.
Does the .Net build-in DI have all features that Unity or Autofac have?

br

.NET DI doesn't have file configuration and named registrations

.NET DI doesn't have file configuration and named registrations

thx, at least for our company that's a no go --> so we have to support Unity in some way or move on to some other DI-container (like Autofac).

In detail, not all DI have the same behavior. The One DI will probably never exist.

.NET DI doesn't have file configuration and named registrations

Also doesn't have a concept of child containers which can take additional registrations.
It only has one top level container and three lifetimes:

• singleton, meaning one instance in the entire container;
• scoped, meaning a new instance per IServiceScope; and
• transient, meaning a new instance per resolve,

and that's it. There's no way to model something like a multi-ton as would be typical for e.g. a multi-tenant solution.

As there are no explicit child containers there's also no way to override a type registration to resolve to different types at different hierarchy levels, or to use different implementations within sibling containers at the same hierarchy level (which would again be something that caters to scenarios like multi-tenant applications).

These are all things Microsoft explicitly doesn't want to support -- People have asked before, and got told exactly that. -- so don't expect them to ever be added either. The advice MS will give you is that for more advanced usage scenarios you will have to integrate a third party container.

By looking at my LinkedIn profile, you may see that I am just a regular developer deriving my income from my work. I was hoping, in time, to derive all my income from work on Unity.

Unity is an extremely-useful, full-featured, “classical” platform. Unfortunately, there is no fame or glory in working on it, just thousands and thousands of hours of mundane work. The only compelling reason to spend any effort on Unity is to earn money from companies that depend on the library in their core business and are willing to pay for work.

If there is no paycheck associated with these efforts, I see no conceivable reason why any reasonable person would work on Unity with no benefit for themselves. At the end of the day, it is all about paying bills and providing support for the family.

I totally agree, I will talk to our CEO.

Would it also be considerable for you to let someone else maintain this project?

Br

I'm not sure if it's that easy, unity is not that simple to understand

I'm sure that won't be easy, but it would be sad to let this project go.

i think that too, I used unity for many years, created extensions, I really like it

Would it also be considerable for you to let someone else maintain this project?

Be careful with this. It opens up big can of worms on supply chain management side of things. If someone wants to maintain it, they should launch a fork and it either sinks or swims accordingly.

@ENikS I think you've made the right decsion. When we pulled NancyFX, we left the door open for busineses to get support such as sponsoring a .NET Core/5/6 version for migration/continuity reasons, or consultancy to migrate to AspNetCore. We had a few enquiries but absolutely zero engagements (most didn't even respond after we responded to their intial enquiry). I also pulled ProxyKit the minute Yarp was announced. "Interested parties" won't come together - that is just not the culture in .NET (oss) ecosystem.

Take pride in the work you've done and happiness from the journey and friends you've made along the way. You don't owe anyone anything.

Take pride in the work you've done and happiness from the journey and friends you've made along the way. You don't owe anyone anything.

I haven't played around with the built in container in .NET 6 so I don't have a strong opinion on this decision, but I did wanted to chime in and say I used and liked Unity for many years. As someone who spent an inordinate amount of time and money on one of my own projects without getting much back (financially), I understand the decision and completely agree with @damianh's sentiment above.

How about an different approach? What if we port the features that are very useful in unity to another container that already has more common features with unity. This way we could make a unity shell over the second best container.

This way we could get configuration files again, registration conventions, named registrations and so on

We moved to Lamar( https://github.com/JasperFx/lamar), it has an very active community and maintainer and has more or less all features that unity has.

Unity Container have alternatives?

Autofac come to mind. As does StructureMap.

There's also Lamar, which is a work-in-progress refactoring of StructureMap - specifically tuned to support the ASP.NET Core DI abstractions.

I am using Autofac and no issues so far.

Same here. Autofac was (almost) a drop in replacement after wiring it into the ASP.NET Core DI abstractions.
Just a few minor gotchas where it behaves different from Unity.
The two with the most impact being:

1. No automatic resolves of non-registered concrete classes without adding a specialized registration source for it in Autofac; and
2. No transitive resolves of type registrations, i.e.

   services
     .AddSingleton<ISomeInterface, ISomeOtherInterface>()
     .AddSingleton<ISomeOtherInterface, ActualConcreteType>()

   will work and resolve ActualConcreteType for both interfaces with Unity - but won't work with Autofac when attempting to resolve ISomeInterface.

Even though I knew nothing about library or project, and why its being killed, but at this sad occasion I will only say "RIP, Sadge and die in honor".

@Mer0winger :
Frankly, i don't know if you should use Unity. I ditched all previous frameworks a long time ago.
The problem with them, they will always do things differently. Thats why i ended up with an own framework. ;)
I would suggest to stick with the Microsoft DI and use an own MVVM implementation. Take a look at MvvmLight or even better MVVM Toolkit. It's a long time ago i used Prism.
Due to incompatibilities with UWP i left this (superb) library long ago.

I used Autofac to replace unity, had to do some small changes and learn how to register things in autofac, in my case it was successful but the application is a small one. I used Prism and AvaloniaUI.

This is about dependency injection.

By the way, here is an article with a workaround for named registrations with the .NET Core Container: https://stevetalkscode.co.uk/named-dependencies-part-1

@dansiegel, @ENikS
First, thanx for your work. I use both Unity (all projects) and Prism (WPF) a lot.
Please do continue to maintain both Unity and Unity support in Prism.
I think there is a LOT of code out there that is using that combo.

I do not have the skill to help you out, by coding, but will do what I can and and sponsor you both (and @brianlagunas), to show that I realy appriciate the work you all do with Unity and Prism.

@PeterOscarsson

Thank you Peter!

@ENikS just wanted to check in with you. I know it seemed that you were planning on doing an update for a v6. Is this something that you still plan on doing?

RIP @ENikS

https://www.gofundme.com/f/eugene-sadovoi

OhMyGod, such a sad news