Lurgle.Alerting v1.2.0 released - Consistent attachment content types!

I've released a small update to Lurgle.Alerting which adds automatic determination of the attachment content type using the MimeMapping library. I've raised the version to v1.2.0 to align with Lurgle.Logging's current releases.

This specifically addresses an issue when sending attachments with MailKit as the SMTP sender. The FluentEmail implementation was essentially causing a System.ArgumentNullException exception in MimeKit.Utils.ParseUtils.ValidateArguments, because content type defaults to null. With the old SmtpClient, that was okay, but FluentEmail was explicitly trying to parse a null content type and receiving the error.

The aforementioned MimeMapping project on Nuget had an extensive set of mime types and provided a straightforward way to perform a 'best effort' match based on file name, with a sensible default of application/octet-stream. Perfect.

As a result - Lurgle.Alerting will always supply a valid mime type to the underlying SMTP sender if you don't pass one. If you do pass a content type and it's invalid, we don't attempt to validate that at this point - so you will likely get an exception.

As per normal, update from Nuget, or via the oh-so-fancy links below.

Comments

You may also like:

Lurgle.Alerting - a standardised FluentEmail implementation with extra goodies!

Another Lurgle Around the time that I tackled my original Serilog logging implementation, I also looked at our email alerting. Emails can be used for a variety of reasons, and it's not uncommon that they are sent as a simple string that concatenates or formats variables. In this scenario, the...

Seq.App.EventTimeout v1.4.5 Released

I've released a new update to Event Timeout for Seq, which improves the handling of 24 hour windows (eg. Start 00:00, End 00:00) and how repeat timeouts operate. Ordinarily, Event Timeout is forward looking - it always calculates the next start time if the configured start time would fall in...

Lurgle.Logging v1.2.0 - Multi-threaded correlation ids are now a thing

Implementing Multi-Threaded Lurgles If we revisit my example from earlier, we'll see a much simpler implementation for multi-threaded code; Log.Level().Add("Here is my log entry"); Log.Level(LurgLevel.Error).Add("Oh no! An error!"); Log.Level().Add("Phew ... moment passed"); Log.Level(correlationId: Logging.NewCorrelationId()).Add("After all that, I'd really like a different correlation id"); Log.Level(LurgLevel.Debug).Add("CorrelationId is {CorrelationId}"); You can see from...