So a quick observation on the alt.net conference list:



"You'll be
happy to know then that in the new WPF Composite work we are doing,
the DI/IOC mechanism will be decoupled and pluggable. Actually the
next version of Entlib will be the same. There's a new Dependency
Injection block that will allow you to plug-in the container of
your choice."


Which was posted
on the alt.net conference
yahoo list by by Glen
Block from Microsoft.



I think this is very good news, at least for the WPF composite work
they're doing - it might make it a great deal more appealing to me
then the CAB was (I was never a big fan of the CAB because it
didn't integrate well with the other stacks of technologies that
made me productive).



I'm fairly ambivalent about the Enterprise Libraries upcoming
pluggable IoC support however - surely the overlap between it and
the facilities and services already provided by the IoC container
you'd be plugging into would be great ... and IoC is only part of
that story... for a number of common services (i.e. logging,
transactions etc.) you're going to have create appropriate wrappers
and sandwich things into the containers "abstracted" view of the
world, or face tightly coupling your application to the Enterprise
Library, I'm not sure there is much of a value proposition there...
though I'm open to being educated if any P&P Microsoft people
happen to read this.



Interestingly enough Jan
Van Ryswyck has picked up on this slip from Glen and
noted that it also implies Microsoft are writing yet another IoC
container that will probably ship with EntLib & the WPF
composite work (in whatever shape it eventually takes) and they ask
the question "why oh
why!" .



Personally I think it makes good sense to provide an out of the box
IoC container, with it the product is far more accessible to new
developers and people reviewing the technology - especially when
you consider that:

• If support was added into say the Castle Windsor container,
  it wouldn't see an official release until RC4 was made public -
  and until then would be in a state of flux as part of the castle
  trunk.
  
• People would expect Microsoft to "suggest" an OSS container
  that works best with their offering - and playing favorites with
  the .Net OSS community could only do harm to the ecology I feel.
  
• Microsoft retain consistency with their existing approach of
  providing an entire stack of technologies for you to get the job
  done, if that's what your like/want or are told you
  want. 
  
  
• They can provide a set of consistent tutorials and training
  materials for developers to "get up to speed" with for the
  product, without having to provide umpteen alternative examples
  for different containers, or explain why the container
  terminology is slightly different to the product
  terminology.
  
  

So in short, I think it's a positive sign, not a negative one,
even if another container is introduced into the mix - I'll be
interested in seeing just how they do it (both the container, and
the extension points to allow for plugging in a different
container)... Though it could just be a hack using
IServiceProvider, I wonder if perhaps they may need to go a bit
further, so they can register services into the plugged in
container with the appropriate lifestyle and configuration
etc.



Edit: I just noticed
Ayende posted about this as well...  he seems pretty well
aligned with the "why oh why" viewpoint, perhaps I'm missing
something - but I just don't see it being all that practical in
some scenarios to provide a product that wont work without the
developer going through a separate selection process to pick an IoC
container, if they don't already use one from the OSS
community.