.NET Client: RaygunClient.SendInBackground crashes if an invalid trace listener is configured

We're developing a project that runs as a Windows Azure Web Role, so our Web.config contains the following trace listener definition:

<system.diagnostics>
    <trace>
        <listeners>
            <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
                <filter type="" />
            </add>
        </listeners>
    </trace>
</system.diagnostics>

However, some of our front-end developers run the site as a plain IIS Express web site, without even having the Azure SDK installed -- hence, they don't have said trace listener installed. Apparently, something that Raygun4Net does in RaygunClient.SendInBackground attempts to create the trace listener, which fails. The failure is not caught by Raygun4Net, and since the exception happens on a background thread, it ends up bringing down the entire IIS Express process.

---

Hi Lauri,

Sorry we've taken so long to get back to you about this! What is probably happening is there is an exception while sending an error to Raygun, which leads us to write a message to the Trace log https://github.com/MindscapeHQ/raygun4net/blob/master/Mindscape.Raygun4Net/RaygunClient.cs#L363

There are a lot of usages of the trace logger throughout the Raygun4Net codebase - it's a good way of logging errors when you don't know what kind of environment you will be running under.

I'm not really sure how much more we can do about this from our end - I've added a try-catch around the threaded part of SendInBackground (https://github.com/MindscapeHQ/raygun4net/tree/catch-trace-log-exceptions), but there are usages of the Trace log throughout the codebase so I can't guarantee that catches all of them. I would suggest looking into disabling the misbehaving listener on your front end dev team machines if you can.

The above changes will be in the next release of Raygun4Net.

Cheers, Jamie

---

Hi,

Obviously we did that right away.

Mostly I reported this issue because I understood that your philosophy is to try to avoid causing a crash that is worse than the original situation. In my understanding, in a .NET application that can only happen when throwing in a background thread, so I believe that handling the async case is sufficient. Thanks!

---

Definitely better to avoid crashing where we can!

---