Using Microsoft Application Blocks

Question

I did not program much .NET, but I studied several application blocks published by the Microsoft Patterns and Practices team. I was wondering how they are commonly used:

• Associated directly with applications
• A source added to and built into applications, possibly with customization
• Example code used as a reference when writing application code

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

Are there several separate application blocks that use "everything?"

Note. This question is related but not the same as the Enterprise Library Application Blocks or the Home Rrown Framework .

Answer 1

I usually put the source code in my project, and then I can improve intellisense (and better understand them). I am not inclined to configure them at all. I like to have them available, so I can just distribute the binaries anytime I need them.

Answer 2

I tried several Enterprise Lib 3.1 application blocks (May 2007) and here are some comments:

Application cache: less interesting than System.Web.Caching in simple scenarios (like in-memory caching) Exception handling and logging: overly complex. NLog or Log4Net are the best solutions.

I looked at other blocks, but they did not seem to fit our designs.

Finally, we completely ruled out EntLib because it was painful to tune ... I would advise you to really consider a less monolithic solution than EntLib.

Answer 3

I used Microsoft Enterprise Library extensively. As a rule, they should never be included in your project, if possible. The added cost of compilation can be heavy. In addition, there is no reason for the source code in your project to use classes. You will still get intellisence during coding while you add the link to the DLL in your projects. It is also recommended that you avoid multiple codebases that will move around the development environment. If you need to customize classes, open them in your own solution and save one version. Of course, I always suggest using version control (VSS or Subversion) if you need to revert changes.

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

Answer 4

We just put the EntLib 3.1 binaries into the shared assembly cache and added links to our projects. However, we usually use only the logging environment.

Answer 5

I think the most convenient way is to add \ EntLib application blocks as solution elements. Thus, they will not be recompiled every time the project is created (they will not participate in the build process at all), and you can easily access their source code \ set a breakpoint, etc.

Answer 6

We use blocks, adding links to the DLL, making sure that "copy local" is set so that they are deployed with the application in the bin folder of the application. This means we don’t need to guess with the GAC - much easier!

When debugging, Visual Studio can still enter the source code, even if it is not directly included in your project, if you have the EntLib source code on your hard drive. It will tell you the location the first time you use it and then remember it.

We currently use caching, exception, and logging blocks. We have not thought about using for the rest.