Version 5

[QuantumNightmare]

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.

@nblumhardt we would like to work on getting this new version 5 of the Raygun Serilog Sink released. Please let us know anything we need to do to help out with this. Also let us know if you have any questions about the changes.

[nblumhardt]

Fantastic seeing it all move forwards 👍

To release the 5.0.0 version, the process is to create a PR (e.g. "Release 5.0.0") from dev into master, containing these release notes.

... oh, drat, I didn't notice the addition of <Version>, so this has now already been published as 5.0.0.

The <VersionPrefix> is sufficient for versioning, the suffix is dynamically selected via the build script.

Will tidy up now :-)

[nblumhardt]

Another quick note, development for "vnext" usually occurs on dev, and changes are PR'd from forks rather than branches within this repository (helps to keep this repository tidy :-))

[nblumhardt]

Should be all sorted now; https://github.com/serilog/serilog-sinks-raygun/releases/tag/v5.0.1 is out, dev is where the 5.0.2-dev packages will build from. Cheers!

[QuantumNightmare]

Thanks for publishing this so quickly! I'll keep all these notes about the procedure in mind for future development :+1:

[nblumhardt]

We should probably write them up somewhere under the serilog/serilog wiki 😅 ... I've been meaning to for a while - sorry!

[QuantumNightmare]

No worries, those docs would be great :)