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 behaves and whether the feature is on.

Checks Table

This table lists all of the Checks you configure in the current Dotfuscator config file and any Checks that you may configure 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 displays 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 opens.
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 information.
3. In the code tree on the right side of the editor, select the Locations in your input assemblies where you want to inject 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 appears 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 opens, 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 You Define in Source Code

Since the Checks tab also displays both Checks you define 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 then ignores the check in the source code and does not represent it with its own row in the table of Checks. The application uses the Check you create in the Config Editor 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 the application to create a config Check with the changed values and/or additional locations which overrides the check 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 overrides the Check in code at that location.
• If you remove a config Check that was overriding a check in code, the check from the source code once again takes effect.
• You cannot remove Checks 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 displays icons if you are using source code to configure Checks:

• No icon displays if you add the Check using the Config Editor and it does not override a Check in code.
• displays if the Check is fully specified in source code.
• displays if the config Check overrides at least one Check in code.

Editing Check Properties

Modifying properties of Checks is usually straightforward; the supported fields 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, also display a "..." icon. Clicking it displays an additional editor for populating the field. You can find descriptions of these editors 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 allows you to browse to and select a Shelf Life Activation Key.

Similarly, you can invoke this dialog 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 application determines that the Shelf Life Key information valid, it enables the Generate button. Clicking this button generates a new Shelf Life Token that can be used in your Shelf Life-configured application. You can copy the Shelf Life Token Data 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 is 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 occurs.

Even if Checks are disabled, Dotfuscator still honors 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. The application can apply these settings 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