Using Microsoft's Application Blocks

Question

I haven't done a lot of .NET programming, but I've examined a few of the application blocks published by Microsoft's Patterns and Practices group. I was wondering how these are typically used:

• Linked directly into applications
• Source added into applications and built with them, perhaps with some customization's
• Sample code used as reference while writing application-specific code

I'm sure all three of these usages are common, but what are the most typical usage patterns?

Are there a few particular application blocks that are used by "everyone?"

Note: This question is related to, but not the same as Enterprise Library Application Blocks OR Home Grown Framework?.

Answer 1

I usually put the source into my project, and then I can get better intellisense (and a better understanding of them). I don't tend to customize them at all though. I like to have them stock so I can just distribute the stock binaries anytime I need them.

Answer 2

I have used Microsoft's Enterprise Library extensively. They generally should never be included within your project if possible. The added cost of compiling can be heavy. Additionally, there's no reason to have the source code in your project to use the classes. You will still get intellisence during coding as long as you add a reference to the DLL's in your projects. It is also advisable to avoid having multiple codebases floating around your developer environment. If you need to customize the classes, open them up in their own solution and keep one version active. Of course I always strongly suggest using version control (VSS or Subversion) in case you need to roll back changes.

There are also open source alternatives to the Microsoft classes that are usually better coded (i.e. Log4Net, nUnit, etc.). Microsoft code tends to be bloated and inefficient.

Answer 3

I've tried several Application Blocks of Enterprise Lib 3.1 (May 2007) and here are some comments :

Caching Application Block : Less interesting than System.Web.Caching in simple scenarios (like In-Memory caching) Exception Handling & Logging : Over-complicated. NLog or Log4Net are better solutions.

I looked at the other Blocks but they didn't seem to fit for our projects.

Finally we completely dropped EntLib because it was painful to customize... I would advise you to really consider a less monolithic solution than EntLib.

Answer 4

We just put the EntLib 3.1 binaries in the global assembly cache and add references in our projects. We typically only use the logging framework, though.

Answer 5

I think that most convenient way is to add App blocks\EntLib as a solution items. That way they will not be recompiled each time you build your project (they will not participate in build process at all) and you can easily access their source code\set breakpoint etc.

Answer 6

We use the blocks by adding references to the DLLs, making sure that "copy local" is set so that they are deployed with the app into the app's bin folder. This means that we don't have to muck around with the GAC - much simpler!

When debugging, Visual Studio can still step into the source code even if it's not directly included in your project, as long as you have the EntLib source code on your hard disk somewhere. It will prompt you for the location on first use, and remember it thereafter.

We currently use the Caching, Exception and Logging blocks. We haven't thought of a use case for the rest yet.