Loupe 3.5.4 Released with Agent Changes

We’ve just released Loupe 3.5.4 which is primarily a defect fix rollup of items discovered since Loupe 3.5 shipped.  But, we couldn’t help ourselves and went a little deeper this time.  You can read the full release notes to catch up on all of the changes but let’s dive into the changes that may be unexpected.

We took a few moments to make adjustments from feedback we’ve gotten from users the past several months - both directly from users and from analyzing our support tickets.  That’s brought about several behavioral changes in the Agents that you should be aware of.  While we try hard to void making any breaking changes to the Agent, in these cases we felt the changes erred on the side of much more benefit to users than risk.

Agent NuGet Package No Longer Includes Packager

Previously we included the Gibraltar.Packager.exe utility in the Agent NuGet package.  The problem with this is there are a number of cases where you don’t want to distribute the Packager utility.  In these cases, every time the Agent needs to be updated from NuGet it adds the Packager back.  This particularly causes problems with customers that have their build process set up to automatically update.

To avoid this notable downside, and given that the Packager isn’t needed in the most common scenario currently (ASP.NET applications) we’ve decided to separate it out into its own NuGet package.  For cases where you want to keep distributing it - like with WinForms/WPF applications - Just add the Gibraltar.Packager NuGet Package.

Automatically Send on Error

We’ve found virtually every user that enables Loupe Server integration wants to have the Agent automatically send information when errors occur.  We’ve handed out this snippet of code more times than we can count:

using Gibraltar.Agent;
 public class Global : System.Web.HttpApplication
 {
     protected void Application_Start(object sender, EventArgs e)
     {
         Log.MessageAlert += Log_MessageAlert;
     }
     private void Log_MessageAlert(object sender, LogMessageAlertEventArgs e)
     {
         if (e.TopSeverity <= LogMessageSeverity.Error)
         {
             e.SendSession = true;
             e.MinimumDelay = new TimeSpan(0, 15, 0);
         }
     }
 }

We’ve baked this behavior into the agent and enabled it by default.  Now when you enable Auto Send Sessions on the server it will assume you want this exact behavior - send on the first error, then send at most every five minutes thereafter.

We implemented this by changing the default values of the LogMessageAlertEventArgs passed to the event so you can still override it in the MessageAlert event, and if you have an existing handler it’ll generally be unaffected by the change.  Still, if you want to disable this feature you can - just set the autoSendOnError option to false.

Log4Net Version Update

The Log4Net team made a change a while back to have two different signed binaries - one that used the same signing key used historically and another that used an updated key that was published as part of the open source code to enable people to produce their own builds of Log4Net that could be used by other assemblies without recompilation.

The headache for us is that the new signing key is in NuGet with a higher version number than the legacy key, meaning anyone that just reaches out and adds Log4Net to their application will get that version and discover that Loupe doesn’t work correctly with it due to the signing key change.  So, we’ve updated to target the newer version.

If you are still using the older version of Log4Net (prior to 1.2.10) then you’ll want to just use the source code version of the Agent for Log4Net distributed with Loupe to compile the agent into your own application.

New Exception Logging Methods

Traditionally Loupe offered two different ways of logging exceptions - the basic Log.(error, warning, critical, etc.) methods and Log.RecordException.  The key distinction is that the latter method attributed the logging call to the source where the exception was thrown, not where the logging call was made.  This is optimized for use in unhandled exception handlers where the source of the logging call is irrelevant but the location where hte unexpecfted error is thrown matters a great deal.

After looking at some user’s usage patterns we’ve added specialized overloads for Log.Error, Log.Critical, and Log.Write (and a few related methods) to support attributing the log message based on where the logged exception was thrown instead of where it was logged.  This is the same behavior that Log.RecordException uses but allows you to fully control the log message.  These overloads are designed for logging within higher-level exception handlers where it isn’t meaningful where it was caught as much as where the error happened in the first place.

New Assembly Version

Because of these new API features we’ve updated the Assembly version to 3.5.4.0 from 3.0.0.0.  This ensures that if you are compiling against one of the new features in this build you can be confident it will be available, even if someone places the Loupe Agent in the GAC.

This does mean that if you don’t want to recompile an older assembly that targets the Loupe Agent you’ll need to do an assembly binding redirect to 3.5.4.0 for it to work.

Loupe Viewer Upgrades and More

There are other non-breaking changes we’ve made to enhance the developer experience with Loupe Desktop - just download the latest release and you can check them all out!  As always, if you have feedback for us on what you’re looking for next, just leave it in the comments here or reach out to us via email to support.