Why didn’t Jeremy just “punt” the configuration-based filtering (after discovering the issues) and instead create an ELMAH filter in code (i.e. programmatically)?
Well, I actually tried that approach, but I didn’t get very far down that road before encountering another blocking issue.
As soon as I added a “
using Elmah;” declaration to my code-behind file for
Global.asax, I discovered the Elmah assembly is not signed. Since the “Caelum”
assemblies (i.e. the code running TechnologyToolbox.com) are all signed with a
strong name key, any assemblies explicitly referenced at build time must be
signed as well.
Up to that point, I had gotten by using the unsigned Elmah.dll since it was previously referenced only in the Web.config file.
After a quick search of the issues list for ELMAH, I found issue 109 (Strong name the assembly). Shortly thereafter, I stumbled upon a discussion thread which, quite honestly, made my head hurt (in one of those morning after New Year’s Eve sort of ways):
Click the link above at your own peril.
Since Microsoft recommends signing assemblies as a best practice (there’s even an FxCop rule for it), I’ve been signing .NET assemblies for as long as I can remember (regardless of whether or not the assemblies need to be loaded into the GAC).
Not wanting to compile my own ELMAH assembly, I quickly retreated from trying to filter errors programmatically.
I do hope the whole NuGet “strong naming conundrum” gets solved (soon) – but to be honest, I’m glad that I’m not involved in that mess ;-)
Personally, I’m sticking with my “Thou shalt sign all .NET assemblies” commandment (until someone can convince me otherwise).