Somebody just has to put the facts on the table. This is what I think.

I have had much experience with Entlib from the times of separate "blocks" for Data Access and Logging. I had to use it because it was the policy. I want to make it brief and simple so here are my points:

Configuration and Deployment:

If you need an external WinForm application to be able configure this shit you are wrong wrong wrong...

50k - 100k for Web.config is too much. Config file is not readable in notepad. Entlib 1 used to have multiple configuration files and one main config file that links to them. So you decide what sucks more...

Deployment and/or configuration of the working environment is a pain in the ass. What for do they need services or performance counters in case of class libraries. There is no need to take it that far.

Bugs in Enterprise Library Part 2Parameters sizes. This one is actually a design bug.

Performance sucks and it is not scalable enough. Writing custom Data Access block is not a rocket science and there are better libraries on the net. All over.

Logging block. It is a pain to configure. There are common libraries like log4net. If one has to put entry separators texts into the application configuration file there is definitely some design problem here. My advice - inherit from System.Diagnostics and keep it simple.

Exception handling block. I bet Exception handling block will dissapear in the future versions of Entlib. Exception handling is just policy, no need to make class library of it. You have just to decide regarding Exception handling policy. Simple points for exception handling policy:

Handle exceptions at a higher level, throw at lower APIs.

Do not swallow or downgrade (like returning boolean or error codes).

Log exceptions.

Do not use exceptions to define business logic flow.

For web - use in addition asp.net mechanisms.

These are main points. There are some other blocks like Caching and Cryptography but they are not so important. There are examples at Codeproject (and other sites) are more valuable, IMHO.