2.0 Creating a TraceListener w/ full EntLibConfig tool integration

Topics: Building and extending application blocks, Enterprise Library Core, Logging Application Block
Feb 27, 2007 at 9:18 PM
I recently extended the Exception handling block to implement my own ExceptionHandler. I followed the example Vijah Metha created, but in VB.NET –

Rather than create a class that inherits from CustomExceptionHandler and uses CustomExceptionHandlerData I implemented IExceptionHandler and created my own custom ExceptionHandlerData type that inherited from ExceptionHandlerData. This let me creation ExceptionHandlerAeembler to assemble them at runtime.

I then implemented a CommandRegistrar, ConfigurationDesignManager, ExceptinHandlerCommand, HandlerNode and NodeMapRegistrar so I could have full design time support within the EntLibConfig tool. This is very slick imho and so much more intuitive than the name/value pairs the CustomExceptionHandler makes available.

This is working great, most importantly; I didn’t have to alter the default EntLib 2.0 source code at all.

I attempted the same thing with the Logging Block and ran into some big problems. At first everything appeared similar, until I got to the LoggingConfigurationDesignManager class I needed to implement. Why was the decision made to seal most of the Design time support classes in the Logging Block?

If I want my LoggingTraceListener to be tightly integrated with EntLibConfig tool it appears I’ll have to create a “custom” EntLib 2.0 build to get at the classes I need or duplicate half of the design time classes. Not exactly what I was hoping for.
--> Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.Design

Am I missing something here? Are there other options? Has the design time support for the Logging Block changed in 3.0?

Thanks in advance for any guidance here,
Feb 28, 2007 at 1:36 PM

I would check out the Application Block Software Factory and use it to extend Enterprise Library 3.0.

It generates a ton of code for you to help with design-time integration with the configuration tool.

In your case you want to create a provider library that creates a new typed provider for the Logging Application Block. There are numerous recipes that help you with this challenge.

The Application Block Software Factory comes with EntLib 3.0. You can create a new provide library or new application block by...

File -> New Project... -> Guidance Packages -> Application Block Software Factory

There is some preliminary documentation in the Docs folder where you installed EntLib 3.0 on how to use it.




David Hayden
Microsoft MVP C#
Feb 28, 2007 at 2:53 PM
Thanks David,
I'm glad this is addressed in 3.0. I'll look into it. I'l' just leave my implmenentation as a CustomTraceListener for now and address this when entlib 3.0 is released.
Feb 28, 2007 at 4:45 PM
As David points out, the Block Factory will make it much easier to build new extensions, including designtime support. But we haven't changed anything in the underlying architecture, so everything it does can be done in EntLib 2.0 today.

I'm not sure I understand the exact issues you're facing building designtime classes for Logging, but I'd suggest looking at the Logging.Database.Configuration.Design assembly for clues. This assembly contains a designtime node for the Database TraceListener, and is completely separate from the main Logging assemblies so it should be much the same as your situation.

Feb 28, 2007 at 10:27 PM
I was able to get my TraceListener registered in the EntLib design tool. But only after commenting out the OpenCore and ConfigurationSectionInfo functions in my custom implementation of a LoggingConfigurationDesignManager. When performing this same excercise with the Error Handling block, only the Register function existed in the example I took. These additional two functions are my problem.

The functions -
OpenCore - Opens the logging settings configuration section, builds the design time nodes and adds them to the application node.
GetConfigurationSectionInfo - Gets the a ConfigurationSectionInfo for the logging settings configuration section.

reference a following sealed classes -

I grabbed the code from the LoggingConfigurationDesignManager in EntLib directly when I attempted to create my custom EmailTraceListener. Then, using the method I had used when creating a custom ExceptionHandler, I registered just my custom TraceListener in my custom LoggingNodeMapRegistrar.

My Logging Extension Design assembly has the following classes -

My Logging Extension Assembly has the following classes -

I haven't tested my Custom EmailTraceListener yet other than I can save values, open the app.config back up in EntLibConfig and they are persisted. Short of becoming an EntLib Logging block expert, what are the ramifications to the code I commented to get this get this working?
Mar 1, 2007 at 12:15 AM
OpenCore and GetConfigurationSectionInfo are implemented on the base ConfigurationDesignManager class, so it isn't mandatory to override them. I wouldn't suggest commenting them out as it will prevent the base implementation from executing, but if there's no need for custom logic in those places then you should be fine to leave them out.

Mar 1, 2007 at 1:24 PM
Thank you Tom.
Everything appears to be working well. This is the type of extensibility and tool integration I was looking for from EntLib. The developers I support should find this TraceListener much easier to use than the vanilla CustomTraceListener I could have implemented.