All available options for configuring your integration with BugSnag.
Used to attach the version number of the application which generated the error. If the application version is set and an error is resolved in the dashboard the error will not be unresolved until a crash is seen in a newer version of the app.
WPFClient.Config.AppVersion = "5.0.1";
Represents the current release stage for the application. This needs to be set manually.
WPFClient.Config.ReleaseStage = "staging";
By default, the client will report on all errors regardless of the release stage. However, you can filter out errors from certain stages. To specify which stages you want to notify on, use the following method.
WPFClient.Config.NotifyReleaseStages = new string[] { "development", "production" };
The concept of “contexts” is used to help display what was happening in your app at the time of the error
WPFClient.Config.Context = "DataAccess";
When an exception stacktrace is recorded, the file associated with each frame will be recorded, if its available. This will be the complete file path, which can lead to bloated frame entries. The paths will also reflect where the application was complied. The client can be configure to remove common file path prefixes.
WPFClient.Config.FilePrefixes = new string[] { @"C:\Projects\Production\MyApp\",
@"C:\Projects\Development\MyApp\",
@"H:\MyApp\" };
Note: This can help significantly when grouping similar errors.
BugSnag will highlight stack trace frames if they are detected as being In Project. The client can be configured with project namespaces. If a stack trace frame method call originates from a class that belongs to one of these project namespaces, they will be highlighted.
WPFClient.Config.ProjectNamespaces = new string[] { "MyCompany.MyApp", "MyCompany.MyLibrary" };
Debugging information is used to provide file paths for stack frames. Normally, this information is only available for locally built projects. Therefore, in most cases, stack frames that have file information relate to calls made within the users code. We use this fact to automatically mark these frames as In Project by default. This is in addition to any project namespaces that have been manually added. This behavior can be disabled.
// Disable marking frames with file names as In Project
WPFClient.Config.AutoDetectInProject = false;
If no project namespaces have been configured and auto detect has been disabled, all stack frames will be highlighted.
The client can be configured to ignore specific types of exceptions. Any errors with these types of exceptions will not be sent to BugSnag.
WPFClient.Config.IgnoreClasses = new string[] { "ArgumentNullException", "MyConfigException" };
Data associated with notifications are sent via the Metadata
object attached
to the error. Sensitive information can be filtered before its sent to BugSnag
by setting filters. Any tab entries that have keys matching these filters will
have their value replaced with the text [FILTERED]
WPFClient.Config.MetadataFilters = new string[] { "Password", "Credit Card Number" };
All notifications are send to the Endpoint URL. By default, this is set to
https://notify.bugsnag.com
, however this can be overridden.
WPFClient.Config.Endpoint = "https://myserver.bugsnag.com";
If reports fail to send then they can be stored offline in IsolatedStorage. This is disabled by default and can be enabled with the following configuration.
WPFClient.Config.StoreOfflineErrors = true;
Stored reports will attempt to be sent in a background thread when the client is instantiated. You can also manually tell the client to send any stored reports by calling the following method on the client. This will synchronously attempt to send any stored reports.
WPFClient.SendStoredReports();