We’re hard at work on Enterprise Library 5.0. One of the things that we’re going to be digging into pretty heavily is .NET 4.0 compatibility. As part of that, I’m beginning to wonder (again) about which blocks still make sense in Entlib.

The Caching block is one of our more popular blocks. It’s been around since before Entlib 1.0 as a stand-alone piece. It was originally intended to suit the needs of occasionally connected client apps to have an offline, persistent cache of information from the server. In practice, it’s been used a lot as a simple in memory cache. We also get constant requests to build a distributed or shared cache.

Requests like this are what got me thinking. In .NET 2.0, the ASP.NET team did a ton of work to make System.Web.Cache work outside of web apps (sadly, they never updated their docs to say so). Since they’re at a lower level than we can write at, the web cache stuff makes a much, much better in memory cache than we can. It monitors overall memory usage, for example, while the best we can do is track how many items are in our cache. With the upcoming release of the cache-formerly-known-as-Velocity, Microsoft has a quality distributed cache technology available. We’d be nuts to try and replicate all that work. We did an analysis of the APIs between our CacheManager and the Velocity cache and came to the conclusion that wrapping Velocity in our interface would cost you a huge amount of capability, so we decided the best guidance was “use Velocity” rather than go through the caching block.

Finally, in .NET 4.0, there’s a new namespace called System.Runtime.Caching, which provides essentially the ASP.NET cache mechanism, but with a provider model behind it. So you can use the existing cache, but you could also plug in new implementations of caching as well.

So, here’s my thinking: given the presence of System.Runtime.Caching, does it make sense to have the caching block at all in Entlib 6? The only scenario that isn’t met by it is the persistent offline cache, and that can be done by building a new cache provider. We’ve always said that p&p’s job was to fill gaps in the platform until the platform catches up. In this case, the platform has definitely caught up, and even passed us in some ways.

Do you use the caching block? Does it do anything you couldn’t do as well or better through the framework provided mechanisms? Is it just backwards compatibility keeping you on it, or is there something I’m missing?

Let us know!

MSDN magazine has just published my latest article. It’s part of the Inside Microsoft patterns & practices online column, and it’s about building libraries that take advantage of dependency injection. I used the work we did rearchitecting Enterprise Library 5 as a sort of case study of the goals, forces, and resolutions. I’m actually quite proud of what we did here, and thought that others might be interested.

Unfortunately, for those of you who get the printed magazine, you may see my name on the cover, but the description of the article is actually from Brian Randell’s article from October’s issue.  I will be having … words … with the magazine staff over this one tomorrow. Sorry Brian, TFS work items are something I’m very happy to let you be the expert in.

Anyway, if you’re interested in how Entlib 5 works under the hood, or want to write a library that uses a DI container without forcing your users to use a specific container, please check it out. And let me know what you think!

We’re about to spin up on development of Entlib 5. As part of that, we want to know what you, yes you want to see in it! Grigori has posted a survey. Apparently, if we did everything it’d take us about 3 years, so we’d like some help from the community to pare it down a little.

Please go take the survey and help me out. And help yourself too, if you’re an entlib user or would like to become one.

We're officially kicking off the planning for Enterprise Library 5, and we want your input.

Basically, what we're looking for is this: you have $100 to put into Enterprise Library 5. It can be spent on bug fixes, new features, documentation, labs, whatever you want, but you can't go over. The more you spend, the more important you think that particular thing is. So, how do you want to spend you $100?

Please either post to Grigori's blog, or here.

Thanks!

(Whew, I didn't realize I'd gotten so far of the blogging wagon. Time to hop back on!)

At the last Seattle Code Camp, I ended up talking with David Starr for quite a while. He apparently thought I knew what I was talking about (shh! Don't tell him the truth!) and invited me to be a guest on the Elegant Code Cast. It was a great talk about EntLib, life in p&p, Unity, and all sorts of other stuff.

The episode is available here. Thanks again, guys for the great chat!

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?