Last week, Microsoft’s Patterns & Practices team released Patch 2554 for the Enterprise Library 2.0. The main point of this patch is to allow one to use the library in partial trust mode—which is a common scenario with web applications in these dangerous days.
I have been using the libraries quite a while, so I thought I would share some tips and tricks about using the code that I found were not particularly well documented nor advertised.
Trick #1: Get the Libs, Man
There are two current versions of the Enterprise Library: Version 1.1 (aka June 2005) for .NET 1.1 and Version 2.0 (aka January 2006) for .NET 2.0. Download as appropriate & desired.
Trick #2: Do the Labs, Man
The first time I looked at the documentation, I was wondering what the hell I got into. Fortunately I stumbled on the Enterprise Library Hands-On Labs (available for 1.1 and 2.0). I found they were quite well written quickly gave the student the ability to make use of the major features of the library.
Trick #3: Remember to Build for Release
The Enterprise Library is, interestingly enough, released only as source code with an installer. This installer does provide a handy “Build the Enterprise Library” checkbox. But there is a hidden gotcha—it builds the library using the DEBUG, not RELEASE, build setting. This means the code is not fully optimized for production use.
Now, if you are including the projects and compiling them with your solution things will work out just fine. But I, myself, prefer to just statically include the compiled assemblies as I don’t really need to worry about the internals of said library.
In any case, building the library properly is a two step process. First, you must run the release build script. Then you must run the script to copy the assemblies. Presuming one has installed the library to c:projectsEntLib, you will need to fire up a command window and run the following commands in that folder:
c:ProjectsEntLibBuildLibrary Release
c:ProjectsEntLibCopyAssemblies Release
[Note that the sources for Version 1.1 are in the [InstallFolder]src folder, so you will have to go there to find the scripts. Also note that, for Version 1.1, Visual Studio .NET 2003 must be installed for the build script to function.]
After running this, all necessary dlls (and xml documentation) will be avaliable in the bin folder of your enterprise library directory.
Trick #4: InstallUtil
This trick really applies to version 1.1. By default it fires off a number of performance counters and writes to the event log. Now, this is generally not a problem in development. But as soon as one moves the application to the staging server, one gets a nasty “Cannot write to registry” error.
There are two ways around this. First, one can modify the build options so that it does not use performance counters. I have, admittedly, never got this to work successfully. But then again I did not try particularly hard. And I happen to like having performance counters available.
The other option is to use .NET’s InstallUtil.exe utility to register the assemblies. To do so, you need to fire up a trusty command line window and run the following command for each of the library’s assemblies you are using:
C:WINDOWSMicrosoft.NETFrameworkv1.1.4322InstallUtil.exe c:MyAppFolderbinEnterpriseLibraryAssembly.dll
Replacing the path to the assembly as appropriate.
Wyatt Barnett
