New Custom Handler

Topics: Exception Handling Application Block
Nov 22, 2007 at 9:08 PM
Hi,

I'm just starting with Enterprise Library 3.1 and I'm having dificults on creating a new custom handler. My idea was to create a handler for logging without using the objects provided by the library (aka log4net), but after writing the code and compiling it succesfully, I want to add through the Enterprise Library Configuration Tool the assembly which contains the object definition but I get a "There were no types found in the assembly '<name of the assembly>' that implement or inherit from the base type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.IExceptionHandler'." message.
The skeleton of my code is:


using System;
using System.Collections.Specialized;
using System.Text;
using Microsoft.Practices.EnterpriseLibrary.ExceptionHandling;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration;

namespace Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging
{
ConfigurationElementType(typeof(CustomHandlerData))
class Log4NetExceptionHandler : IExceptionHandler
{
public Log4NetExceptionHandler(NameValueCollection ignore)
{
}

public Exception HandleException(Exception exception, Guid handlingInstanceId)
{
return exception;
}
}
}


I wrote this code based on an example for EntLib 2.0, should I change anything in order to have it working with 3.1?

Thx
Diego
Nov 22, 2007 at 9:19 PM
Hi Diego,

There are new versioning aspects you need to consider now that EntLib ships binaries. Most likely you've built your library linking to the unsigned source code but are using the signed binary for the configuration tool, so the class you inherited from and the one being looked for by the tool are different.

This post from Tom explains the situation http://blogs.msdn.com/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx; while it's not the exact same symptom, it's very closely related.

Fernando
Nov 23, 2007 at 3:03 PM
Fernando,

I think my problem might be related with the linking of signed/unsigned code, but still I can't find a solution. I'm always using the signed assemblies included in EntLib and the Configuration tool included with them.
I've marked all references with "Specific Version = False", I don't know if that should help, but it didn't work either.
Do you know any public example of Custom Handlers for EntLib 3.1? I think it'd really help me if I could take a look to an example implementing this.

Diego
Nov 23, 2007 at 4:15 PM
Hi,

The "Version specific" setting is not going to help here. Make sure your project references the the binaries that match the version of the tool. Eg add "browse" references to the signed binaries in the install folder (most likely "C:\Program Files\Microsoft Enterprise Library 3.1 - May 2007\Bin\") and create a new configuration file using the matching tool binary ("C:\Program Files\Microsoft Enterprise Library 3.1 - May 2007\Bin\EntLibConfig.exe"). You should be able to load your handler; the code you pasted is fine.

Fernando
Nov 23, 2007 at 4:52 PM

fsimonazzi wrote:
Hi,

The "Version specific" setting is not going to help here. Make sure your project references the the binaries that match the version of the tool. Eg add "browse" references to the signed binaries in the install folder (most likely "C:\Program Files\Microsoft Enterprise Library 3.1 - May 2007\Bin\") and create a new configuration file using the matching tool binary ("C:\Program Files\Microsoft Enterprise Library 3.1 - May 2007\Bin\EntLibConfig.exe"). You should be able to load your handler; the code you pasted is fine.

Fernando


That's what I'd done! I'd also tried referencing the assemblies and the configuration tool biult from the source code and that didn't work either.
I'm starting to think its a matter on how I reference the type of the handler from the App.config (since I can't get EntLibConfig to load the assemblies, I'd tried doing it manually using the ExceptionHandlingWithLoggingQuickStart example that comes with EntLib). This is the extract from the App.config:

<exceptionHandling>
<exceptionPolicies>
.............
<exceptionHandlers>
<add type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging" name="Log4Net Handler" />
</exceptionHandlers>
.............
</exceptionPolicies>
</exceptionHandling>

Thanks for your patience
Diego
Nov 23, 2007 at 5:09 PM
Not sure what to tell you... Tried this before answering and it worked.

Here's what the references look like in my project:

<Reference Include="Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.Practices.ObjectBuilder, Version=1.0.51206.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />


Here's what the incomplete class looks like

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.EnterpriseLibrary.ExceptionHandling;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration;

namespace WindowsApplication17
{
ConfigurationElementType(typeof(CustomHandlerData))
public class MyHandler : IExceptionHandler
{
#region IExceptionHandler Members

public Exception HandleException(Exception exception, Guid handlingInstanceId)
{
throw new Exception("The method or operation is not implemented.");
}

#endregion
}
}


And here's the config file authored with the tool

<configuration>
<configSections>
<section name="exceptionHandling" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</configSections>
<exceptionHandling>
<exceptionPolicies>
<add name="Exception Policy">
<exceptionTypes>
<add type="System.Exception, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
postHandlingAction="NotifyRethrow" name="Exception">
<exceptionHandlers>
<add type="WindowsApplication17.MyHandler, WindowsApplication17, Version=1.0.2883.23661, Culture=neutral, PublicKeyToken=null"
name="Custom Handler" />
</exceptionHandlers>
</add>
</exceptionTypes>
</add>
</exceptionPolicies>
</exceptionHandling>
</configuration>
Nov 23, 2007 at 9:09 PM
I finally got through! Thing is the Configuration Tool that VS opens by default, isn't the one that is in the \bin directory with the strong named assemblies (the ones I was referencing from the solution). That's why I couldn't add the assembly with the custom handler from the EntLibConfig.
Anyway, I'll try with a fresh new solution (instead of the ones included as quick start in the EntLib) and I expect I won't have any other issue with this... if not you'll see me around here again ;-)

Thanks for all
Diego
Nov 25, 2007 at 9:35 PM
Hi,

Missed the part on your last post about using the QS as a new starting point, but you shouldn't have had problems with if you linked to the binaries and used the matching config tool...

The QS projects link the source and have a specific setting at the solution level that instructs the VS config tool to switch to the binaries built from those projects (overriding the default behavior of looking for the signed binaries.) Here's some background information on the subject http://blogs.msdn.com/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx.

Fernando
Nov 26, 2007 at 9:25 PM
Not sure, if I'm being silly, but why is your type Log4NetExceptionHandler not public, default "internal" modifier should be blocking the type from being visible. Isnt it ? Please correct me if I am wrong.

Neo.