If you've been following along for the last couple of posts related to ELMAH -- or if you've read one of the two issues (i.e. bugs) I created on the ELMAH project -- then you might be wondering:

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):

Warning

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).