The Checks Editor

The Checks screen allows you to add, edit, and remove Checks.

While not accessible from this screen, there are also general settings and input assembly settings that affect how Check processing will behave and whether it is turned on at all.

Checks Table

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.

Table Columns:

• 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:

1. 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.

2. 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.

3. 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.

4. 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.

Browse Dialog

On the ActivationKeyFile property of a ShelfLifeCheckAttribute, clicking the "..." icon will allow you to browse to and select a Shelf Life Activation Key.

Similarly, this dialog can be invoked to browse to and select a PrivateKeyFile for a ShelfLifeCheckAttribute.

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.

Disabling Checks

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:

See Also:

• Understanding Checks
• Check Attribute Listing
• The Settings Tab in the Dotfuscator Config Editor