Using the GUI
Exception Tracking is an Instrumentation feature that allows an injected application to report when unhandled exceptions occur.
Exception Tracking can be configured at the method level to detect unhandled exceptions that occur within the method and at the assembly level to detect unhandled exceptions that occur anywhere in the assembly.
Note: Dotfuscator Professional Edition also allows you to track exceptions caught by your application and exceptions thrown by your application.
To track exceptions:
Configure the properties of these attributes appropriately.
Build your Dotfuscator project.
The output assemblies will now contain injected code for Exception Tracking.
Exception Tracking can be used on methods within all assemblies supported by instrumentation. Exception Tracking can also be used on those assemblies themselves except for the following cases:
.dllassemblies (this restriction does not exist in the Professional Edition)
When an exception occurs, it may be helpful for the user to provide additional information, such as what scenario triggered the error. Additionally, the user may consent to sending an exception report even if they previously opted-out of telemetry. You can have your application provide this information, or you can have the injected code ask the user for the information.
This information is communicated via a source defined with the
ExceptionTrackAttribute called ReportInfoSource.
The source defines either an
IDictionary or an
There are three keys that the injected code will look up in this dictionary:
"consent": value is the string
"false", indicating whether the user opted-in to transmitting this exception report.
"comment": value is a user-provided comment about what the application was doing when the exception occurred.
"contact": value is an unstructured, user-provided piece of contact information.
Collecting user-specified report information is optional. If using this application-provided report information strategy, you can choose to populate any or all of these values without actually soliciting the information from the application's user.
Dotfuscator can have the injected code ask the user for information, instead of calling out to application code.
To do this, on the
ExceptionTrackAttribute's ReportInfoSourceElement property, choose the "DefaultAction" value.
This dialog will use the following information, if provided:
ApplicationAttribute's Name property.
BusinessAttribute's CompanyName property.
ExceptionTrackAttribute's PrivacyPolicyUri property.
The user can provide additional details (the comment and contact information) by clicking the Add Details button. If they click the Send Error Report button, the report will be sent. If they close the dialog in any other way, the report will not be sent. The general telemetry opt-in preference will be ignored in all cases.
The generic exception dialog can be used on assemblies supported by Exception Tracking, and methods within those assemblies, except for the following:
The assembly must target version 1.1 (or higher) of the .NET Framework or Silverlight version 2 (or higher).
Additionally, in a Silverlight assembly, the generic exception dialog can only be used for assembly-level Exception Tracking; it cannot be used for method-level tracking.
When using the built-in dialog on the .NET Framework, the dialog will be constructed and displayed using the Windows Forms API. This may have unintended consequences for console or service applications; it may be preferable to use application-provided report information in these situations. If the assembly does not already reference the appropriate Windows Forms libraries, references will be added.
Exception Tracking only generates one type of message: Fault.
Includes the following data:
Dotfuscator Version 220.127.116.1134. Copyright © 2017 PreEmptive Solutions, LLC