Removal (A.K.A. Pruning)
Dotfuscator can statically analyze your application and determine which pieces are not actually used. This includes searching for unused types, methods, and fields. This is of great benefit if application size is a concern, particularly if you are building your application from reusable components.
The problems that can occur with Removal are very similar to those that may occur with Renaming. If Dotfuscator is unable to tell that certain methods are being called (due to reflection / XAML / etc.), then it may try to remove things that are required at runtime.
There are two types of inclusions possible, and both can be controlled by specific inclusions and by custom rules.
Consider an application in which method
A() calls method
- Include Triggers: If you select a method as an Include Trigger, Dotfuscator will make sure to keep that method, as well as any descendants of that method in the call graph Dotfuscator sees (again skipping things like reflection). If an Include Trigger is set on method
A(), then both
B()will be kept.
- Conditional Includes: Any method set as a Conditional Include is kept, but its call tree is not traversed for additional methods to keep. If a Conditional Include is set on method
A()will be kept, but
B()will be removed (as long as it is also not called by any other methods that Dotfuscator knows about).
There are two options for Removal Kind:
- Remove unused metadata and code: This is used when you want Dotfuscator to actively search out and remove unused types and methods.
- Remove only literals (const definitions): This is used to strengthen the power of String Encryption, so that unencrypted string consts get removed. If String Encryption is enabled, Removal should be turned on with this option selected.
In the Dotfuscator User Guide: