Skip to content

Releases: exceptionless/Exceptionless.Net

v4.0.0-beta

21 Jun 16:27
Compare
Choose a tag to compare
v4.0.0-beta Pre-release
Pre-release

Version 4.0 includes support for .NET Core and ASP.NET Core! This means you can now use Exceptionless to build .NET applications on Linux, macOS and Windows!!

New Features

Breaking changes

  • We merged in the Exceptionless.Portable and Exceptionless.Extras functionality into the Exceptionless package and dropped support for .NET 4.0. The Exceptionless NuGet package now supports .NET Standard 1.2+, PCL Profile 151, and .NET 4.5 This is the main reason for bumping the major version.
    • The Exceptionless.Portable NuGet package still exists and has a dependency on the Exceptionless Package. This should make upgrading a breeze.
    • If you need to use .NET 4.0, please stick with the 3.5 NuGet Packages which will continue to work as expected 👍.
  • Properties marked deprecated (in v2.0.0) were removed:
    • ExceptionlessClient.Current property was replaced with ExceptionlessClient.Default.
    • Configuration EnableSSL properties were removed.

Upgrading to 4.0.0

If upgrading from v2 or v3 the upgrade process should include just updating your NuGet packages. Please see the upgrade guide for more information.

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.5.0

10 May 20:08
Compare
Choose a tag to compare

Version 3.5.0 focused on improvements to sessions, real time configuration and logging.

  • Added the ability to exclude events by type and source in real time as well as minimum log levels! We've made improvements to real time project configuration to ensure that if you accidentally disable logging completely, your settings can be updated in the background and functionality restored! We will expand on UI support for this in the near future, in the mean time please check out the example project configuration below:
    • Key: @@EVENT_TYPE:SOURCE Value: false You can use any event type or source. We support using wildcards * as part of the source. If you want to ignore complete event types then set the source to *.
    • Key: @@error:*MyCustomException Value: false The following disables the submission of any error event where the stack trace contains an exception with a type name that ends with MyCustomException. You can also specify the full type name with namespace and remove the wildcard.
    • Key: @@log:* Value: Off Log types are special cased but still accept true or false for values. This example will turn off log messages completely. Known values are: Trace, Debug, Info, Warn, Error, Fatal, Off.
    • Key: @@log:MyNamespace.EventPostsJob Value: Info This sets a minimum log level for the EventPostsJob.
  • Added support for automatically checking for updated configuration settings when the client is idle. By default the client will now check every 2 minutes after the last event submission for updated configuration settings. You can also turn off the automatic updating of configuration settings when idle by calling client.Configuration.UpdateSettingsWhenIdleInterval = TimeSpan.Zero;.
    • Checking for updated settings doesn't count towards plan limits.
    • Only the current configuration version is sent when checking for updated settings (no user information will ever be sent).
    • If the settings haven't changed, then no settings will be retrieved.
  • Session Heartbeats and Session End events are now sent through an optimized api end point. This means that they no longer count towards your plan limits!
  • Added an easy way to exclude events from being submitted via by defining a simple Func<Event, bool> callback. The following example ignores any event that has has a value property of 2 client.Configuration.AddEventExclusion(e => e.Value.GetValueOrDefault() != 2);
  • Fixed a bug where SettingsCollection.GetBoolean(name) didn't support parsing 0 or 1 as boolean values (#88). We also now support yes and no as valid boolean values.

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.4.1

19 Apr 20:07
Compare
Choose a tag to compare

Version 3.4.1 focused on bug fixes pertaining to running under .NET Native. We'd like to thank @gardebring for his help in tracking down the .NET Native issues.

  • Fixed an .NET Native issue that could cause a runtime exception to be thrown when calling client.Configuration.ReadFromAttributes().
  • Fixed an .NET Native issue that could cause serialization to fail on complex types.

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.4.0

12 Apr 15:47
Compare
Choose a tag to compare

Version 3.4.0 focused on massive improvements to deduplicating events. We'd like to thank @srijken for all of his hard work in implementing this functionality.

Deduplication improvements

In previous versions of the client we had a simple plugin that looked at the hash code of each stack trace and discarded events when any part of the errors stack trace was a match. We knew we could be smarter about this and provide you even more value so iterated on it.

Here are some key improvements over the previous implementation:

  • All events types are considered for deduplication instead of just error events.
  • All of our models now have equality and GetHashCode implementations which allows us to calculate more accurate hash codes. This allows us to be super confident about discarding duplicate events.
  • We keep a counter of all discarded events and submit that Count so you know exactly how many events occurred without paying the price of submitting the duplicates.

How does it work?

We have a plugin with a low priority that sits at the end of the plugin pipeline. This is to ensure events we check for duplication have been processed completely before we check it. Here is how our plugin works:

  1. Lets assume we submit a new event. Our plugin checks the events hash code to see if the event has been processed within the past 60 seconds. Since it hasn't been processed we add the hash code to a list of processed hash codes and allow the event to be submitted.
  2. The next time an event is submitted that matches the previous events hash code in step 1, we cancel the event from being submitted and enqueue it into a queue for submission at a later time.
  3. Any subsequent events that match on hash code will be canceled and a counter on the enqueued event (from step 2) is incremented and occurrence time is also updated.
  4. After ~60 seconds, a background timer submits any enqueued events from step 2.

What we gain from this is allowing you to see an accurate representation of events are occurring within your app without them counting against your plan (because only a fraction of them were submitted).

How do I get this functionality?

Just upgrade your clients to the latest version!

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.3.6

25 Feb 16:58
Compare
Choose a tag to compare

Version 3.3.6 focused on improvements to sessions and bug fixes.

  • Fixed an issue where dictionary keys names were being changed (#63). This was causing query string parameters and cookies to be renamed (E.G., myId to my_id).
  • Calling the client.Register() method will now respect your session setting. If you want to have Register handle calling client.SubmitSessionStart() for you, then remember to first call client.Configuration.UseSessions().
  • Updated the manual stacking implementation to use a model instead of a string. This allows us to send a stack title and key value pairs on how the event should be stacked. You should be using the SetManualStackingKey("manualStackingKey") and SetManualStackingInfo() Event extension methods or EventBuilder method overloads.

This is a required update if you were previously using manual stacking.

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.3.5

18 Feb 21:30
Compare
Choose a tag to compare

Version 3.3.5 focused on improvements to sessions.

  • Added new extension methods for events to make it easier to set valid geo coordinates, tags, reference id's and much more
  • We updated UseSessions() to take an optional heartbeatInterval TimeSpan parameter which defaults to 30 seconds. We also added a useSessionIdManagement boolean parameter that will automatically set a manual session id. We recommend that you only call useSessionIdManagement on long lived desktop apps.
  • Fix geolocation for cultures that have a different separator for decimals (@InlineAsm #80).

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.3.4

15 Feb 21:17
Compare
Choose a tag to compare

Version 3.3.4 focused on bug fixes.

  • Added SubmitLog and CreateLog overload without source parameter (#78 @AhmetTaha).
  • Replaced ExceptionlessClient.Default.Configuration.UseDebugLogger() with ExceptionlessClient.Default.Configuration.UseInMemoryLogger() as it previously only worked in debug mode with client source.
  • Fixed an issue where the serializer wasn't always being passed through to the get known event data helper methods (E.G. event.GetUserIdentity()) This was causing a few plugins to silently fail.

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.3.3

12 Feb 18:58
Compare
Choose a tag to compare

Version 3.3.3 focused on bug fixes and features.

  • Added the ability to do manual stacking by calling EventBuilder.SetManualStackingKey("MyStackingKey")(@adamzolotarev). By doing this you are taking complete control over how the event is stacked so be careful.
  • Added support to ignore events that match a user agent bot filter (#73). You can set this client side (ExceptionlessClient.Default.Configuration.AddUserAgentBotPatterns("*bot*")) or server side (project settings).
  • Increased the default RequestInfo max size limit.
  • We now merge any exception.Data properties into the Error.Data dictionary. This prevents you from having extra nesting (E.G., error.Data.Data).
  • Fixed a bug where AggregateExceptions that contained more than one inner exception would be discarded (#15).
  • Fixed a bug where SetGeo would cause an event to not be processed on machines with a non english locale.
  • Fixed a bug where an ArgumentNullException could be thrown if post data or cookies contained a null key.

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.3.2

25 Jan 23:12
Compare
Choose a tag to compare

Version 3.3.2 focused on improvements to sessions.

  • Users can now opt into sessions on desktop applications by setting a default user and calling ExceptionlessClient.Default.Configuration.UseSessions().
  • Fixed an issue where module info wasn't being included in some error reports.

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!

v3.3.1

22 Jan 16:20
Compare
Choose a tag to compare

Version 3.3.1 focused on bug fixes.

Improvements

  • Added plugin to cancel any session events that don't have an identity set.
  • Fixed an issue that caused clients to fail on machines that didn't have .NET 4.6 installed. This was caused by a bug with MSBuild.
  • Fixed an issue where some deeply nested exceptions could have been truncated due to default max depth serializer settings.

Please take a look at the change log for a full list of the changes.

Feedback

We're listening and we'd love to hear your feedback! Please send us your feedback by clicking on one of the links below!