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.

So I quite like Family.Show as an end to end solution of WPF goes... but I think what's been more fascinating is seeing how my (beautiful) Financee is finding it as a working product.

So she's a big genealogy zealot - and for the first time when saying "hey have a look at this" for some random piece of tech I could see here interest was piqued, so we click-once'd it onto her machine and she's been playing around with it for the last day or so - having loaded around 300 people into it so far.

First off the good - it's pretty, and very fluent - you can see immediately who's being edited, current vs. past relationships, dead vs. alive (hollow people are dead... ) And it performs nicely... 200+ vector "people" on screen and the machines not sweating a bit.  

Surprisingly it's also pretty quick for data entry, something I had my doubts about when first looking at the application vs. something a little more traditional - after about 5 minutes of experimentation she was an expert.

Second the bugs... well the main one is that certain characters in a name like a double quote causes the "stories" data screen to crash upon saving...  And every now and then it just flakes out completely... I might throw some logging into and see just what's going on, it doesn't even let you get a stack trace *erk*.

Interaction - well here's where she's getting pissed with it and I'll probably need to enhance it a little - and it's all to do with relationships...  there doesn't appear to be any way to establish a relationship between two people once their added to the tree... a pretty big oversight - they expect you to add all relationships by adding a brother/mother/father/sister/spouse/child to the person currently being edited, but that means you cant actually implement something like:

• Joe marries Jane
• Bob marries Martha
• Jane & Bob die
• Joe marries Martha

A big problem during times of war because it was not uncommon for widows to marry the brother of their dead husband.  This seems like a big oversight (though it is just a tech demo).

Interesting though, and this sample is definitely the best WPF app with source code I've had to play/learn from... great stuff Vertigo.