One thing I should note, is that I didn't mean to give the indication that MEF is perfect - it isn't. I often get frustrated by certain design decisions we made, the attributes annoyed me at first, however, I actually got used to them, and now like applying them (I love being able to quickly look at a type, and know exactly what service it provides - especially if in a hierarchy). The lack of ExportFactory in v1 (basically a mix of 3 & 4 in the relationship zoo<http://nblumhardt.com/2010/01/the-relationship-zoo/>), was also sorely missed (although you can actually write your own without too much difficultly). Debugging sucks - and I work on the product. One small trick is look in your debug output window - we output some tracing there - especially in the rejection case, which is the most common case that customers run into.
It also becomes very good in complex cases. I use it extensively for non-extensibility purposes in my package & project system for the Portable Library Tools<http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981>. My entire system is built up using MEF, from the package, to the project object, to the individual project services, the presenters, views etc. Basically it's made up of a bunch of different containers representing the different lifetimes of the components (ie one for the package itself, one for the project which inherits the package, one for each presenter/view combo, etc). Kitty HawkVisual Studio LightSwitch is another product that makes heavy use of it as an IoC container. That said, however, make sure you evaluate all the other IoC containers and choose one based on the features you're actually interested in. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Jake Ginnivan Sent: Thursday, August 25, 2011 9:04 PM To: ozDotNet Subject: RE: Anyone using Prism? Thanks for that David, That was quite interesting =) I must admit I haven't used MEF in any heavy way, my experience is using it in FunnelWeb for extensibility. I have the opportunity in a few weeks to give MEF a spin in Silverlight as I am breaking a codebase apart to make it modular. I will give it a shot of replacing what I have done in Autofac with MEF to improve my understanding. Appreciate the detailed response. Regards, Jake Ginnivan Readify | Senior Developer | MVP (VSTO) M: +61 403 846 400 | E: jake.ginni...@readify.net<mailto:jake.ginni...@readify.net> | W: www.readify.net<http://www.readify.net/> From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com]<mailto:[mailto:ozdotnet-boun...@ozdotnet.com]> On Behalf Of David Kean Sent: Friday, 26 August 2011 9:28 AM To: ozDotNet Subject: RE: Anyone using Prism? Everyone's opinion on what defines an IoC container differs - even guys well known in the DI area don't agree on what makes an IoC container. I know this because we involved a lot of them throughout the development of MEF - some worked on our team, Nick (Autofac) and Hammet (Windsor), and others were on the MEF insiders group that we used to call monthly. Where do you think Nick got the inspiration for that relationship zoo post he blogged about? MEF has a representation for every one of those dependency relationships, Autofac actually added some of them after MEF. :) I'm actually using MEF as my mainline IoC container. In the next update of MEF (I believe we've got a preview drop on the codeplex site), some of the major things missing have been added in the box (open generics, fluent interface - registration builder), factories and parameterized construction have been there since day v1, ExportFactory was added to v2 (Silverlight). When I do find things that are missing, I usually just end up writing an ExportProvider or Catalog that enables it. For example, we have a bunch of legacy IServiceProvider provided services in VS - I plugged in my own ExportProvider, now all of sudden I can start [Import]ing them, and not have my components touch the IServiceProvider. We don't have AOP, and I don't think we'll ever add it - we of the opinion that this sort of thing needs to happen at compile time (think in PostSharp, CCI, and compiler-as-a-service terms), not at runtime. Lifetime is limited, but we wanted to keep it that way. What do you think is missing? Blast away and I'll file some suggestions internally. From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com]<mailto:[mailto:ozdotnet-boun...@ozdotnet.com]> On Behalf Of Matt Siebert Sent: Thursday, August 25, 2011 6:04 PM To: ozDotNet Subject: Re: Anyone using Prism? I agree. This issue is discussed several times on MEF's CodePlex site: http://mef.codeplex.com/discussions/35083 http://mef.codeplex.com/discussions/43823 http://mef.codeplex.com/discussions/43424 Admittedly, these may be a little dated but some of Glenn Block's comments are very enlightening. The following post is also worth reading: http://blogs.msdn.com/b/nblumhardt/archive/2009/03/16/hosting-mef-extensions-in-an-ioc-container.aspx On Fri, Aug 26, 2011 at 10:24 AM, Jake Ginnivan <jake.ginni...@readify.net<mailto:jake.ginni...@readify.net>> wrote: I don't agree that both MEF and Autofac are IoC containers. Sure they both perform dependency injection, but MEF was never designed to solve the same issues that today's IoC containers solve. MEF is more about architecture and extensibility, where the IoC containers help us manage a set of static resources and relationships between those resources. Mef has no support for Open Generics, Automatic factories, parameterised construction, AOP and the lifetime support is more basic. I would use mef to discover, and let me know when there are more modules, then use new ContainerBuilder().. register new components, _container.Update(containerBuilder); Regards, Jake Ginnivan Readify | Senior Developer | MVP (VSTO) M: +61 403 846 400<tel:%2B61%20403%20846%20400> | E: jake.ginni...@readify.net<mailto:jake.ginni...@readify.net> | W: www.readify.net<http://www.readify.net/> From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On Behalf Of David Kean Sent: Thursday, 25 August 2011 10:58 PM To: ozDotNet Subject: RE: Anyone using Prism? I would either use MEF or I would use Autofac. I wouldn't mix them together. They are both IoC containers, and are both around to solve the same problems. I personally use MEF, but I worked on it so I'm a little bias. I would use MEF if you don't want to take a dependency on something outside of the framework, otherwise, I would evaluate all the good IoC containers (Castle Windsor, StructureMap, Autofac, Unity) out there and pick the one you feel most comfortable with. From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com]<mailto:[mailto:ozdotnet-boun...@ozdotnet.com]> On Behalf Of Matt Siebert Sent: Thursday, August 25, 2011 5:44 AM To: ozDotNet Subject: Re: Anyone using Prism? Take a look at http://code.google.com/p/autofac/wiki/MefIntegration It's not a tutorial but shows how you could use MEF with Autofac. I haven't tried it yet but I'm about to start using MEF (and probably Autofac too) in my current project. On Thursday, August 25, 2011, Kirsten Greed <kirst...@jobtalk.com.au<mailto:kirst...@jobtalk.com.au>> wrote: > Thanks Jake > > Do you know of any good tutorials on MEF and Autofac? > > Kirsten > > > > ________________________________ > > From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> > [mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] > On Behalf Of Jake Ginnivan > Sent: Thursday, 25 August 2011 1:50 PM > To: ozDotNet > Subject: RE: Anyone using Prism? > > > > Quite good timing actually, here is a post which backs up my point about > staying away from unity if you want a well performing app: > > > > http://philipm.at/2011/0808/ > > > > Another negative side effect of Prism is that modules have a single Run > method. Which you have to do your container registrations and resolve your > dependencies. > > > > Internally when you resolve, if you have performed any registrations since > you last resolved the container has to rebuild it's dependency tree, which is > costly. Autofac forces you to create a ContainerBuilder then build the > container from that, so you mentally separate registration and resolutions, > this has the advantage that Autofac does not have to lock the container when > you perform a Resolve, reducing contention and once again speeding the > container up. Unity has to lock on all operations. > > > > Regards, > > Jake Ginnivan > Readify | Senior Developer | MVP (VSTO) > > M: +61 403 846 400<tel:%2B61%20403%20846%20400> | E: > jake.ginni...@readify.net<mailto:jake.ginni...@readify.net> | W: > www.readify.net<http://www.readify.net> <http://www.readify.net/> > > > > From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> > [mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] > On Behalf Of J
