The Checks Editor
The Checks screen allows you to add, edit, and remove Checks.
This table lists all of the Checks that are configured in the current Dotfuscator config file and any Checks that may be configured via custom attributes in the application source code.
The first column only shows icons if you are using in-code attributes to define Checks.
The Check Type column indicates which of the possible Check Types this Check is.
The Description column describes the locations in the input assemblies that have this Check.
- Method signatures in this column are abbreviated, and only the common namespace is displayed if there is more than one location for the check. To see a full, unabbreviated listing of these method signatures, you can look at the tool tip for the Check's description.
Adding Checks to the Config File
To add a Check:
Click the button that corresponds to the type of check you want to create: Add Debugging Check..., Add Tamper Check..., Add Shelf Life Check..., or Add Root Check.... An editor for the new Check will open.
In the grid on the left side of the editor, configure the properties for your Check. See the section on Property Editing for more detailed instructions.
In the code tree on the right side of the editor, select the Locations in your input assemblies that you wish to be injected with this Check. Each location can only be associated with one Check of a particular check type.
Click OK to confirm. A new row in the table will appear for the Check.
You can edit a Check by highlighting the Check in the table and then clicking the Edit button. The Check's editor will open, and you can edit its properties as well as change its locations.
You can remove a Check from the config by highlighting the Check in the table and then clicking the Remove button.
Working with Checks Defined in Source Code
Since the Checks tab also displays both Checks defined in your source code via custom attributes and Checks in the config file, there are a few things to keep in mind:
You can override a Check defined in code with a config Check. Dotfuscator will then ignore the check defined in code and will not represent it with its own row in the table of Checks. The Check created in the Config Editor will be used instead. Overriding happens when either of the following occurs:
You edit the properties of or add a location to a Check defined in code via the Config Editor. Because Dotfuscator cannot modify the source code, this causes a config Check to be created with the changed values and/or additional locations which overrides the check defined in code.
You add a location to a config Check and the new location already has a Check in code with the same Check Type. this config Check will override the Check defined in code at that location.
If you remove a config Check that was overriding a check defined in code, the check from the source code will once again take effect.
You cannot remove Checks defined in source code using the Dotfuscator Config Editor. If you wish to remove a Check defined in source code, you must remove it from the source code itself.
The first column of the Checks table will display icons if you are using source code to configure Checks:
No icon is displayed if the Check is was added using the Config Editor and does not override a Check defined in code.
is displayed if the Check is fully specified in source code.
is displayed if the config Check overrides at least one Check in code.
Editing Check Properties
Modifying properties of Checks is usually straightforward; the supported fields will accept free text (for most string properties), provide a drop-down list of supported values, or provide a date picker.
However, some properties, when selected, will also display a "..." icon. Clicking it will display an additional editor for populating the field. These editors are described in the following subsections.
In addition, the Checks property documentation explains what each of the specific properties means and what behavior it controls.
Owner Type Selection Dialog
An Owner property of sources and sinks, such as ApplicationNotificationSinkOwner, specifies a type within the application. Click the "..." icon in the field to launch the dialog from which you can select the type.
Similarly, this dialog can be invoked to browse to and select a PrivateKeyFile for a
Generate New Shelf Life Token
When using Shelf Life Checks with an externally stored Shelf Life Token, Dotfuscator allows you to generate new Shelf Life Tokens easily by clicking Tools > Generate Shelf Life Token... in Dotfuscator.
Within the dialog box that displays, you can browse to and select the appropriate Shelf Life Activation Key file and, optionally, a PKCS #12 Private Key file to provide additional validation of the Shelf Life Token. When using a private key file, enter the correct password in the Private Key File Password field.
Set the Expiration Date and optionally set the Warning Date.
Next to the Warning Date field is the Use Warning Date checkbox.
Clear this check box if you did not enable Warning Date behavior using the
ShelfLifeCheckAttribute, or if you enabled it but wish to provide an updated Shelf Life Token that disables it.
When the Shelf Life Key information is determined to be valid, the Generate button is enabled. Clicking this button generates a new Shelf Life Token that can be used in your Shelf Life-configured application. The Shelf Life Token Data can be copied to the clipboard by clicking the Copy button.
You can disable Checks in the Feature subsection of the Settings Tab > Options property page in the Dotfuscator Config Editor.
Disable Checks: Acts as a master switch for the entire Checks feature. If set to "No", Check injection will be performed as specified by the Check-related settings configured in Dotfuscator as well as by all check attributes contained within the input assemblies. If set to "Yes", no Check injection of any kind will occur.
Even if Checks are disabled, Dotfuscator will still honor each input assembly's Strip Check Attributes option which is an assembly-level injection option.
Assembly-level Check Options
Dotfuscator allows granular control of the handling of Check attributes on your assemblies. You can tell Dotfuscator whether to honor or ignore and whether to keep or remove these attributes from the assemblies. These settings can be applied at the assembly level.
Honor Check Attributes
Set Honor Check Attributes to "True" (the default) to tell Dotfuscator to process these attributes and perform the indicated injection on the target assembly. Setting the property to "False" tells Dotfuscator to ignore any Check attributes.
A "False" setting is useful in testing scenarios and in advanced scenarios where a set of assemblies may need to be run through Dotfuscator multiple times.
Strip Check Attributes
Set Strip Check Attributes attributes to "True" (the default) to tell Dotfuscator to remove these attributes from the target output assembly. Setting this property to "False" tells Dotfuscator to leave the attributes in the output assembly.
Like the Honor Check Attributes option, a "False" setting is useful in testing scenarios and in advanced scenarios where a set of assemblies may need to be run through Dotfuscator multiple times.
The table below indicates the results when combining these two options and why you might want to use each combination:
|Honor Check Attributes||Strip Check Attributes||Notes|
|True||True||Default settings. The assembly is injected with code based on attributes declared in the assembly, and these attributes are removed.|
|False||True||The assembly is not injected with code based on attributes declared in the assembly, and these attributes are stripped out. This is useful for creating test builds that do not include Checks functionality.|
|True||False||The assembly is injected with code based on attributes declared in the assembly, and these attributes are left in. This combination is not recommended.|
|False||False||The assembly is not injected with code based on attributes declared in the assembly, and the attributes are left in. This is useful for assemblies that need to be obfuscated but will need to have Checks added in a subsequent step.|