Evaluating Enterprise Library 2.0

time to read 6 min | 1185 words

Because, I didn’t have an inflammatory post in nearly two days, and I’m feeling faint

Anyway, I’m working at the moment at a highly Microsoft focused client. Which means that they consider the Enterprise library as Mana From Heaven. This forced me to raise from my own pile of tools and take a look at the Enterprise Library.

I can’t say that I am overly impressed. Here is my quick summary:




Not sure why we will need this now. There are strongly typed accessors for configuration, and they are flexible enough to do whatever I need. If I need to pull the configuration out of the database, I can do this in one line of code (using Active Record).

If I need to do complex configuration, including object graphs, I will either use a data base and Active Record, which make it a breeze, XML Serialization or just rethink what I’m trying to do.

For me, all those lengthy configuration files are death-by-XML.


They mention event log, performance counters and WMI events. I’m not sure why the event log is in instrumentation, and I’m clueless with regard to WMI events, but why do we need another layer on top of performance counters?

I just did a project that required some heavy use of performance counters, and the API couldn’t really be simpler.

Object Builder

There is something very wrong in Microsoft building their own IoC container.

The Object Builder looks like a reasonable implementation of Dependency Injection and Inversion of Control container, but I don’t see any reason to use it except that it got “Microsoft” in its name.


Again, I have a problem with this, mainly because of log4net. It was there first, after all. Why do the same thing again?

Data Access

I got NHibernate, enough said

This looks like a whole lot of work to get what I have seen Oren Ellenbogen do in about five minutes and 15 LoC using delegates.

Exception Management

This one I like in concept, but not in practice. The problem that I have with this is code such as this: “if(ExceptionPolicy.HandleException(ex,”Foo”)) throw;” This presume that under some circumstance I will want to swallow an exception. This kind of stuff gives me ticks. You have no idea how big a bug-fest can get when such a thing is happening. Errors are vanished into the night, and so is sanity, soon after.

What is interesting about the exception handling is that it supposed to prevent you from leaking sensitive data to remote callers on error conditions. It is a notable goal, I just got a design problem with solving the problem this way.

Depending on the application, I would either hook an OnError event (ASP.Net) or provide a service decorator that handles this (web services / Remoting).

Beyond that, I suspect everything that has boilerplate code in it.

The real problem is that all the things that it is trying to achieve are not something that could change safely without affecting all calling code.


This one looks cool. A durable cache that survives application restarts is something very interesting. Of the top of my head, the only kind of applications that I would use this is for partially connected applications, like smart clients, etc. A cache is something that takes care & feeding, not something that you can just use without thinking about.

(Cache invalidation policies, for instance. Concurrency issues, etc. )

I would generally not bother with those issues unless I had a partially connectivity scenarios.


Um, why? None of the services that they offer can’t already be had from the framework in five lines of code tops.


It looks nice, but I don’t know enough on the subject to talk.


One thing that annoys me about the Enterprise Library is that at least two of the core components are duplication of outside effort. I can think of at least two well known logging framework for .Net (log4net & NLog ), both of which existed before the Logging Application Block saw the light of day. I can’t think of all the IoC containers for .Net, and that is because there are so many of them.

I got an issue with this because it creates an artificial segmentation of the tools. As far as I can say, those tools were not created because of some need that Microsoft could not meet using the open source equivalents. Nor because of some licensing issues (like NAnt / MSBuild) since most of the IoC containers for .Net as well as log4net are free for the taking. Including for commercial use.