Enterprise Library, not always the best option!

I had to say it, the Enterprise Library which I think is a brilliant repository of coding practices from Microsoft, is not always the best option!

I struggled a lot with it when trying to deploy it to a shared hosting environment and I finally gave up. I had to write this on the GotDotNet Message board:

"Enterprise Library and shared hosting
Posted on: 08/12/2005 02:11:21

Hi guys, ok I have now developed 2 reasonably big ASP.NET applications built on the Enterprise Library. One of them uses Data Access, Configuration, Caching and Security (DB) and the other one uses the Data Access and Caching. They are both intranets and although it took me quite some time to suss out how to get everything to work and to code/debug my VB.NET calls to the EL, I finally managed to get the sites working very well and I am quite impressed with some of the functionality in EL.

However I have to emphasize on the fact that I did struggle, it is not always developer friendly and you have a few obstacles to overcome (I guess it's still quite new so people are getting used to it!) and even though it is packed with very cool functionality I still think it is a sledgehammer to crack a nut. Compared to the old DAAB and the ever so friendly SqlHelper class, there is quite a big gap! Maybe you should think about the Enterprise Library Lite! (.NET Framework 2.0?)

The Enterprise Library is awesome when it comes to hosting a very complex web app yourself on your very powerful W3K Server on an AD Domain. But when your designing a very simple secure site hosted on a shared hosting environment with a simple SQL server backend, like it is the case 99% of the time (for me anyway), you are in for a big ride!!! No way I could run "InstallServices.bat" on the 3rd party shared hosting network of course, so you get the nice "Access Denied error" when you try to run the blocks because of the Instrumentation and Logging trying to access the EventLog...

I read Tom's blog: http://blogs.msdn.com/tomholl/archive/2005/02/18/376187.aspx

Tried what he suggested but was still getting errors from the Caching block even after turning off the Instrumentation altogether. After many hours of frustration, I just chose to give up, got rid of EL DLLs altogether and replaced them with the good old SqlHelper! Rewrote my data access layer, implemented a simple SQL server authentication mechanism with password encryption and swore I would never use EL again.

So end of story for me, a lot of time wasted, no will to get a dedicated server solution (too expensive) and therefore back to a normal plain old SqlHelper class, which I have to say now I kind of prefer to the EL!

At least it deploys to any server.

Sorry guys but I had to say it! On a different note, I still think the Enterprise Library Code is probably one of the best open source I have seen in terms of architecture and new ways of thinking blocks. Just make sure it is developer friendly and that you can deploy it to any .NET environment, especially remote with limited access rights!

Cheers, Etienne "