Grigori Melnik, product manager for Enterprise Library, just announced that-

"With the upcoming version of EntLib (v4), we are planning to provide containers (flat and hierarchical) that will support dependency injection out of the box. These containers will be packaged individually and also with EntLib v4..."

A couple of things to take note.

EntLib 3.5 Just Became EntLib 4.0

Grigori mentioned not too long ago that the next version of Enterprise Library was going to be v3.5, not 4.0, and was only going to consist of bug fixes:

Enterprise Library: alive and well - planning v3.5

This 3.5 announcement took into consideration the dedicated community members who responded to their annual survey, so I am curious as to the recent motivating factor to move to Enterprise Library 4.0. Something at the PnPSummit? Feedback from other teams in the Patterns & Practices Group? Developers on the CodePlex Team? Some advisory committee? My guess is that the answer will be all of the above, but I would love to know more details on the motivation for this change of plans.

Dependency Injection Application Block

I don't see an actual reference to a Dependency Injection Application Block in Grigori's post as recently mentioned by Jeremy based on what he read in a newsgroup, but it may be implied or a part of another team's efforts.

Assuming a DIAB will be provided by and used by Enterprise Library v4.0, this is a huge deal and I don't think those developers who occasionally peek into the world of P&P have a full appreciation of what this means. Some developers will see this as a way for P&P to re-invent something already out there, but I see this as a big win for all dependency injection tools and developers. It opens up the software factories and Enterprise Library to something other than ObjectBuilder and allow us to use our DI Tool of choice - whether that be the DIAB or another tool.

Right now it is no small task to remove ObjectBuilder ( and EntLib ) from P&P solutions - thus providing us little opportunity to use any other tool. I have been ranting on this for some time as most people will know:

• Move Dependency Injection from WCSF to Enterprise Library
• Think of Enterprise Library as a Provider not a Dependency - Repository Factory Example
• Microsoft Patterns & Practices - Enterprise Library Is Not The Layer Of Abstraction in Software Factories
• Repository Factory With Pluggable Database Provider - 4 Hours Including Custom Tooling

I even went as far as re-writing the Composite Web Application Block to a Simple Web Application Block that removed ObjectBuilder and Enterprise Library dependencies ( not a trivial task ) for use with smaller projects:

• Composite Web Application Block - ObjectBuilder - Enterprise Library = Big Smile
• Simple Web Application Block Gets StructureMap and Windsor Dependency Injection Integration

This is a huge win and a positive move by P&P.

As far as calling it the Dependency Injection Application Block ( if that will be the name ), it does sounds generic, but it is consistent with the naming convention of all the application blocks:

• Data Access Application Block
• Caching Application Block
• Cryptography Application Block
• Logging Application Block
• etc...

Most P&P customers will identify with the name so I think it makes sense.

Again, I see this as a positive move and can't wait to see what happens with this!