Name

Opinion

Configuration

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.

Instrumentation

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.

Logging

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.

Caching

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.

Cryptography

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

Security

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