ErrorSignal class and Loose Coupling

[Matt Murrell]

Is there any way to send an error to ELMAH without referencing the
Elmah DLL to call ErrorSignal.Raise()?

My goal is to keep ELMAH completely loosely coupled with the
application. Any suggestions / ideas?

[Atif Aziz]

>>
Is there any way to send an error to ELMAH without referencing the Elmah DLL to call ErrorSignal.Raise()? My goal is to keep ELMAH completely loosely coupled with the application.
<<

The only way to stay independent of ELMAH is to simply add its logging module to your configuration and let it do its job of logging uncaught exception. Signaling was added due to popular demand where people wanted to explicitly invoke ELMAH's pipeline for filtering, logging, mailing and what not for a given error. Signaling allows you to take an explicit dependency on ELMAH but remain independent of how ELMAH is currently configured. I'm not so sure how this explicit coupling can be removed generally without you creating an abstraction within your own solution to insulate it from the dependency on ELMAH.

Do you have any suggestions?

[Schalk]

Why not use Factory or better yet Inversion of Control (IoC) /
Dependency Injection (DI) patterns?

Make the logging method call via a interface class. Basicly have a
factory class in a seperate project which will figure out what
component to instantiate when a call to that interface is made. This
means no direct reference to Elmah is made in your original calling
assembly, but only in the assembly that has the factory class.
This will decouple your code from the direct dependancy to Elmah, the
best solution for this is a IoC container, e.g. Castle Windsor, or to
write your own Factory assembly.