More on Logging UnhandledExeptions from Managed Add-Ins [Jesse Kaplan]

Last time we discussed some issues to be aware of when trying to build hosts that are resilient to failures in their add-ins.

The central idea was to subscribe to the UnhandledException event on the hosts AppDomain and to use the "sender" parameter to associate the exception to the add-in that caused it. The main limitation of the approach discussed for detecting and logging unhandled exceptions from the add-in's was that it only worked when the host itself was running in the default AppDomain and that this excluded hosts that themselves run inside other hosts (such as IIS).

This time we are taking a slightly different approach that works regardless of which AppDomain the host is running in, but has a different limitation. Instead of subscribing to the event on the host's domain, you can subscribe to them individually on each add-ins AppDomain. This causes a subtle but important difference in the way the handling code for that domain runs: it always executes in the domain that fires the event regardless of where the subscriber came from. This means that the piece of code handling this event needs to be loaded in the add-ins domain and, for versioning reasons, should be as small and have as few dependencies as possible. By keeping this code small and with few dependencies you reduce the chances that the code conflicts with the add-ins dependencies and causes a failure. In the attached sample I have refactored the code for handling exceptions into a separate assembly and made sure it was independent from the host and so brought no other pieces of the host into the add-ins AppDomain. There were a few small tweaks to the host itself, but all the interesting changes take place in the new UnhandledException project.

So the pattern used in the sample can work with hosts in non-default domains at the expense of having a slightly higher risk of causing versioning problems butwith careful coding you can minimize this risk.

 

Note: The attached sample was built for a pre-RTM version of .NetFX 3.5 and will not work on the RTM build. For an updated sample please see our codeplex site here: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=clraddins&ReleaseId=9456

 

ReliableExtensibleCalculator.zip

Comments

• Anonymous
  June 05, 2007
  Off topicSorry for this general CLR question but I am hoping some there knows the answer as I am really stumped.  I have some .Net code that generates a dynamic assembly.  Inside the assembly I emit some code using the ILGenerator.Emit() method.  All is working well except that for some reason right in the middle of the IL being generated I am ending up with the following sequence of instructions:breaknopnopbreakI do not generate these instructions and I can't seem to trace down where they are being generated from or why.  I have turned off debug information generation on the assembly to no avail - the instructions continue to show up.If I choose to save my assembly to disk (I normally create it to run in memory only) I can dissassemble it and remove the sequence of instructions and reassemble and every thing is fine and verifies nicely.  Anybody have any idea why/how these instructions are ending up in my emitted assembly?Thanks,Rod
• Anonymous
  August 20, 2007
  How do i go about logging these exceptions without having to specify the logging configuration for each add-in separatly? I just want to configure this in the web.config or app.config of the host application.Thanks,Jeroen