Should I use Unity (is it still alive)?

I've worked with Unity 2 years ago, and i was planning on using it again.

But, when you google for it, you get to开发者_如何学JAVA the microsoft site which says that the pages are no longer maintained, and another big hit is at codeplex.com.

At codeplex however, there hasn't been a release since begin 2010, and they promise movies in may/june (I assume they mean 2010) but they aren't there yet.

So I was wondering wether the product was still alive, or is MEF the new kid-that-rocks?

ps (bit offtopic)

don't know if i'm the only one but i never seem to get a good overview of the maturity / status / 'will they exist next year' etc. of a codeplex project, and the documentation most of the time is so-so

---

A few points:

1. MEF, isn't aiming to be a competing product with Unity (so keep that in mind when choosing it for the primary purpose of IoC). A Microsoft employee, Glenn Block, brought this up here on stackoverflow:

   We are not aiming for MEF to be an all-purpose IoC. The best way to think about the IoC aspects of MEF is an implementation detail. We use IoC as a pattern because it is a great way to address the problems we are looking to solve... MEF is focused on extensibility.

2. There is also a similar question (from last month) on the P&P forum for Unity with the following answer:

   Unity is alive and well and there's a team working on it right now (we are building Unity Interception support for Silverlight as part of the Silverlight Integration Pack). Check out the latest drop, you'll see updates there.

   Besides, there are many projects using Unity today, including Microsoft products. The pulse of Unity adoption is quite healthy - over 100K downloads of Unity 2.0 standalone and much more via EntLib. The number of subscribers to Unity forum on stackoverflow is the same as to MEF forum.

3. I would highly suggest that you abstract away your IoC container of choice behind a thin wrapper to help immunize yourself from the risk of any given container becoming obsolete. It will make it easier to switch to a different container if the need arises. Page 251 of Brownfield Application Development in .NET advocates this approach too, and sample code is as follows (I changed it a bit to avoid copyright infringement):

   public class Resolve
   {
       public static T TypeOf<T>()
       {
       //…
       }
   }
   
   public class SomeClass
   {
       public void DoingSomething( )
       {
           var someDependency = Resolve.TypeOf<ISomeDependency>();
           //...
       }
   }
   

---

MEF (Managed Extensibility Framework) and Unity currently sit on competing ground when it comes to dependency injection offerings from Microsoft. As far as interception and AOP (aspect oriented programming), MEF hasn't really made an effort to tackle that just yet.

History tells us that Microsoft doesn't really manage its competing/overlapping team projects well and the result is a track record of half baked implementations that often lack basic functionality (look at LINQ to SQL and Entity Framework for an obvious example - 3 years later, EF still lacks very basic functionality that LINQ to SQL had out of the box).

I would personally go with a more mature, better maintained DI framework (most have which also have more functionality than MEF and Unity combined). I like Castle Windsor. NInject, StructureMap, and others also seem to have good track records.

---

I think MEF is the new kid-that-rocks. And it's pretty sweet. It seems to be pretty well documented and it looks like it'll be around for a while. It's easier than Unity too, from what I've seen.

---

Yes, Unity does still exists ! and so does mef. If i am not mistaken, microsoft patterns and practises is same as unity 2.0 ?