5.0.1 Release

[nblumhardt]

Note: due to a build issue, 5.0.0 was released from dev.

Changelog

Breaking changes

• Raygun payloads now include the Client section that tells the Raygun backend where the crash reports are coming from. Among other things, this allow Raygun to select an appropriate grouping algorithm that can also be selected by Raygun users. As a result of this change, crash reports will start being grouped differently to how they were grouped from previous versions of this Sink which is why this is considered a breaking change.
• Raygun payloads now include the HTTP Request section which includes the URL, HTTP method, query string parameters, cookies, server variables, form fields, headers etc. This is considered a breaking change because some applications may have sensitive values in some of these sets. If you are concerned about some of these including sensitive values, then check the readme for various options that allow you to filter or prevent sending them. The Request section is included when an HTTP context is present while logging an Exception.

Features

• A new option called userInfoProperty can be used to specify a key in the properties dictionary that provides a RaygunIdentifierMessage. This gets attached to the User section of the crash report payloads sent to Raygun to provide richer user information than the existing UserName option. This supports RaygunIdentifierMessage objects being either destructured or not. If this option is provided, then the UserName option is ignored.
• Raygun payloads now include the Environment section that states the CPU architecture, used/available memory, locale, timezone offset etc of the machine where the crash report was sent from.
• Raygun payloads now include the HTTP Response section which provides the response code and status description. This is provided when an HTTP context is present when logging an Exception.
• Logging null exceptions will now set the Error.Message to be rendered with property values, while Error.ClassName continues to be the log template. Thanks intermediateza for suggesting this change.
• Logging null exceptions will now include the current execution stack trace on the crash report where the Exception stack trace would normally be.
• The application version included on crash reports sent to Raygun will now automatically be read from the entry assembly of the application where possible. This is overwritten by the applicationVersionProperty feature if used.
• The applicationKey parameter can now be null or whitespace rather than throwing an exception. Thanks phillip-haydon for suggesting this change.
• The same Exception instance can no longer be sent to Raygun twice. This is a feature provided by Raygun4Net which is designed to protect your Raygun monthly usage costs in the case that duplicate exception logging has accidentally been wired up.
• Up to 64 crash reports can now be saved to isolated storage if available in the case that they fail to be sent to Raygun. These are then attempted to be resent later.
• Properties in the properties dictionary that provide values for various parts of the crash report payload are now removed from the UserCustomData section. For example, you can provide a list of Tags as a value in the properties dictionary. These tags get attached to the appropriate Tags section of the crash report payload. Previously these tags would double up by also appearing in the UserCustomData section, but now they will only be displayed in the Tags section.

Bug fixes

• Exceptions logged with log-level Fatal are now sent synchronously, while log-level Error continues to send crash reports asynchronously. Log-level Fatal should be used for unhandled exceptions that result in the application being terminated. Previously, sending crash reports asynchronously while the application is being terminated would prevent the HTTP request being completed and so they weren't showing up in Raygun. Thanks benjaminsampica for identifying and fixing this.
• The wrapperExceptions option is now wired up to actually strip out specified wrapper exception such as TargetInvocationException which would result in only the inner exception(s) being logged.