Dotfuscator is capable of renaming all classes, methods, fields, properties and events to meaningless names. In addition to making decompiled output much more difficult to understand, it also makes the resulting executable smaller in size.
Problems can occur with Renaming when using any type of reflection (including XAML), configuration files that specify entry points, libraries that are called by other applications, etc. It is important to fully test applications after Renaming to ensure no such problems exist.
Presuming Library Mode is turned off, Dotfuscator will try to rename everything it possibly can. Certain uses of reflection can cause Dotfuscator to not update all references to a particular entity upon renaming. In the following example, we’ve excluded four classes and their fields:
Our application references these types and members by looking up their names via reflection. If they were to be renamed, the application would be unable to find them at runtime. Therefore, we exclude them from renaming via these checkboxes.
Custom Exclusion Rules
There may be times when you may need to make many specific exclusions for a particular coding convention. And even then, when a developer adds more code that follows that convention, they would have to remember to make yet another specific exclusion for their new code.
The solution to this is Custom Exclusion Rules. Using the previous example, let’s say we figured out that all types with names ending in "Dungeon", and specific types of fields within those types, will need to be excluded from renaming for some reason. Rather than creating a bunch of specific exclusions, we can make one custom rule:
The rule is displayed on the right pane.
We added the rule's root node with the Add Type button and given it the name
.*Dungeon and set the Regular Expression (
regex) option to
true to indicate that the name should be treated as a regular expression. Thus, the node will match types whose names end in "Dungeon". Because we have set Exclude Type (
true, any types matching this name will be excluded from renaming. If we had set that option to
false, the types that match would not be excluded from renaming - only the members specified by their child nodes.
We then added a child node by right-clicking the root node and selecting, in this case, Add Field. We gave this node the name
.* and again indicated that this should be treated as a regular expression. We've restricted the rule to only cover fields which have the public access modifier (by setting
+public), and whose signature is
string, as both are necessary in our scenario.
Once a rule is configured, you can select a node and click the Preview button, and Dotfuscator will highlight the entries that match your custom rule in the tree view on the left. In our example, we are previewing the child node, so fields that match the criteria are highlighted. Notice that the "Keys" field in "AdventureGame.Validation" is not excluded, because while it matches this child node, its parent type does not match the parent node (i.e., the class name "Validation" does not end in "Dungeon").
The resulting configuration of this custom rule is stored as XML in the configuration file. This example produces the following config XML:
<type name=".*Dungeon" regex="true"> <field name=".*" speclist="+public" signature="string" regex="true" /> </type>
Built-In Rules are Custom Exclusion Rules that are fairly universally useful; we include them by default so users do not have to re-implement them.
The exact definitions of each of these can be found in
For example, Methods with System.Web.Services attributes translates to the following custom rule:
<excludelist> <type name=".*" regex="true" excludetype="false"> <comment>Exclude all methods that are decorated with attributes from the System.Web.services namespace.</comment> <method name=".*" regex="true"> <customattribute name="System.Web.Services.*" regex="true" /> </method> </type> </excludelist>
There are many renaming options available on the Rename | Options tab, including what renaming scheme should be used, whether to introduce explicit overrides, and many others. They are well-documented in the Dotfuscator User Guide.
Enhanced Overload Induction
With this feature enabled, Dotfuscator extends Overload-Induction™ by allowing a method’s return type or a field's type to be used as a criterion in determining method or field uniqueness. This feature allows up to 15% more redundancy in method and field renames. In addition, since overloading on method return type or field type is not allowed in source languages such as C# and VB, this further hinders decompilers.
Note: Overload Induction is typically not performed on assemblies containing any XAML code because of the way the runtime determines how XAML and code are linked up. As a result, the Use Enhanced Overload Induction option will not change anything for such assemblies.
In the Dotfuscator User Guide: