We are putting together a workshop on the Unity container and extensibility. We'll be talking primarily about container extensions: what kind of extensions people will build, the API, how the API could be improved, and similar topics. If you're interested in influencing the direction of Entlib 4, please take a look at Grigori's post for details and try to come!

As Grigori has already mentioned, we (the Enterprise Library 4 team) are working on a new Dependency Injection block, named Unity. Grigori's post gives some of the details of our API. The existing API covers probably the 80% case, and we've got an extensibility story for those who need the container to do more.

Underlying our container implementation is the ObjectBuilder library. As I've mentioned before, there's a general impression that OB isn't very good. In asking people, most actually say "well, I had no idea where to start so I gave up." This tells me the real problems are discoverability and documentation. We can't do much about discoverability at this point. After all, I'm working on the container to hide all that stuff away! But if you want to extend Unity, you'll need to understand ObjectuBuilder. That, hopefully, I can help with.

About six months ago, I got kind of fed up with OB. Or more specifically, fed up with myself for not understanding it. So, I set out to understand this library and write down my discoveries. The result is an (at this time) incomplete document called Deconstructing ObjectBuilder. Over the next couple of weeks I'll be posting that document here along with example code. Something like it will also form a chunk of the docs for Unity, but I wanted to get it out there in it's original form.

I hope you all find this useful. At least this way now I won't have to keep mailing Word docs to people.

We've just spent the last week getting the Entlib 4 project going again, and I'm amazed as usual how much stuff just got broken in the build system.

 At p&p, we run our continuous integration servers as VPC's on a fairly big multi-processor box. It generally works out pretty well because none of the projects are typically building at the same time. And the nice thing for us is we can (in theory) archive build servers when a project goes into "hibernation"; just shut down the VPC, copy the file off to backup, and bring it back when you're ready to go.

Of course, in practice stuff like that never just works. Entlib 3.1 wrapped in May of 07, and the build server's been shut down since then. Around Microsoft, if a machine isn't used for more than a month, it gets kicked off the domain, so we had to fix that. Then the account credentials the server was running under had expired. Ok, next one, hey it's building ... what do you mean out of disk space? Turned out the new account didn't have access to the TFS project, so the build server happily output 20 gigs of log files saying "can't connect to source control." And then there was the Oracle server that wasn't there anymore, and the permission changes on the event log that made 200 tests fail, and on and on and on...

ARGH! All this breakage, and there wasn't even a single checkin between May and the start of the project. It's all straightened out, but I have to say, oy, what a pain!

Luckily, I've got a fantastic team that volunteered to shoulder most of the burden. Fernando, thanks a million!

I'm the development lead on the next version of Enterprise Library. The big feature we're adding, as mentioned by Grigori Melnik, is the Dependency Injection Application Block. There's already been quite a bit of discussion on the blogosphere about it, and I don't want to reopen the discussion here. What I do want to ask about is about the underpinnings of many p&p assets, that will play an important role in the implementation of the block: ObjectBuilder.

 For those who don't know, ObjectBuilder (OB) is a fairly small library that is used at the heart of EntLib, CAB, and WCSF.  It's p&p's current implementation of a dependency injection system. And the overall concensus is that it sucks.

The problem with concensus is that, after a while, folks remember the conclusions, but nobody actually remembers how or why that conclusion is reached. So I ask you: why does OB suck?

For what it's worth, my personal opinions on the matter are:

1. There are no docs other than pretty useless XML doc comments.
2. OB is only half of the DI story. The other half, the DI container itself, doesn't exist (yet). Without the container, you've got to deal with an extremely general API which doesn't make any sense at first glance.
3. Perf needs to be improved.

We're going to be working on all three of these for Entlib 4.

So, tell me: other than the above, why do YOU think OB sucks?