Thursday, February 17, 2005

Fun with Microsoft Enterprise Library, part 2

Okay, I can see that this is going to be a long series ....

Here's what I'm talking about on how to get Visual Studio to see Enterprise Library assemblies without browsing (taken from the GotDotNet workspace patterns & practices: Enterprise Library: Message Boards):

"Do you want to see EntLib assemblies in Add References message box?
Create a text file named entlib.reg, and add this content:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\AssemblyFolders\Enterprise Library]
@="C:\\Program Files\\Microsoft Enterprise Library\\bin\\"

Double click on the file and you'll be asked whether to add this registry key. Click yes, restart and there you go.
(it is assumed that assemblies are in their default folder - otherwise, change the path above)."

Sigh. I really really try to avoid the Registry when possible.

There's another neat trick for sorting out the structure of the Enterprise Library: open one of the solutions in Visual Studio, select Project-> Visio UML -> Reverse Engineer.

Too bad all it actually does is generate a 75K blank Visio file, because Visio is unable to resolve all of the references.

I suppose this will work for code that's so simple that a UML diagram isn't needed.

Moving right along, I've also found how to sign all of the Enterprise Library Asemblies! You just generate your public/private key pair, and then reference them in the GlobalAssemblyInfo.cs file in:

C:\Program Files\Microsoft Enterprise Library\src
This file gets referenced by every project when it's compiled. Yay!

Except that every project's AssemblyInfo.cs contains blank references:

[assembly : AssemblyDelaySign(false)]
[assembly : AssemblyKeyFile("")]
[assembly : AssemblyKeyName("")]

Which overwrite what gets pulled in from GlobalAssemblyInfo.cs.

So you have to go through every project's AssemblyInfo.cs file and remove those 3 lines.

Sigh. There's 23 projects in the Security section alone, which is sort of the sine qua non for using the EL to begin with, for my purposes.

Well, Caching, Configuration, Data, ExceptionHandling, and Logging are also useful.

One step at a time.

I've gotten Logging to work. Unfortunately, every time it logs it throws three error messages:

"Failed to create instances of performance counter 'Distributor: # of Logs Distributed/Sec' - The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly..

For more information, see Help and Support Center at"

"Failed to fire the WMI event 'LoggingLogWrittenEvent'. Exception: System.Exception: This schema for this assembly has not been registered with WMI.
at System.Management.Instrumentation.Instrumentation.Initialize(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetInstrumentedAssembly(Assembly assembly)
at System.Management.Instrumentation.BaseEvent.Fire()
at Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.InstrumentedEvent.FireWmiEventCore(BaseEvent baseEvent).

For more information, see Help and Support Center at"


"Failed to create instances of performance counter 'Client: # of Logs Written/Sec' - The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly..

For more information, see Help and Support Center at"

Presumably these counters are installed as part of the EL service installation, but going through the batch file yields for logging:

@ECHO ---------------------------------------------------------------------------------
@ECHO Installing Services for the Logging and Instrumentation Application Block
@ECHO ---------------------------------------------------------------------------------

if Exist Microsoft.Practices.EnterpriseLibrary.Logging.dll installutil %1 Microsoft.Practices.EnterpriseLibrary.Logging.dll
@if errorlevel 1 goto :error

So I'd like to break out whatever counters are needed so I can install them on the webserver, and ideally, be able to script this installation for production code on a production server with an Installer project.

Although I'm strongly tempted to just go back to using my ErrorHandling class, which doesn't need anything installed anywhere.

No, I'll persist in using the EL. I'm sure there will be a payoff -- like extending the Logging class to handle XML.

Of course, to extend the EL one should be cognizant of all the Unit Tests there built to ensure its continued functionality. So I need that book on Test Driven Development real soon now.

Well, at least I'm not bored.


Paul Whitaker said...

LOL, yes it's important to not be bored. Thanks for the wrap-up on some of the stuff you can do with EL assemblies, I'll probably do the registry trick :P

Anonymous said...

Good work! this was the only credible place where I found some solution and respite..