Removal (also known as pruning) reduces application size by identifying and removing code, metadata, and resources that are not required at runtime.
Smaller applications can:
- Download faster
- Install faster
- Load more quickly
- Expose less information to attackers during reverse engineering
In addition to removing unused code, Dotfuscator can remove non-essential metadata from an assembly, further reducing its size.
How Removal Works
Removal uses static analysis to determine which parts of an application are required.
The analysis begins with one or more methods known as triggers (or entry points). Dotfuscator examines each trigger and follows all reachable code paths.
As the analysis progresses, Dotfuscator identifies:
- Types that are used
- Methods that are called
- Fields that are accessed
- Resources that are required
The process continues until all reachable code has been analyzed.
Any code that cannot be reached through this analysis can be removed from the protected assembly.
Example
Consider the following call hierarchy:
A()
└── B()
If A() is configured as a trigger, Dotfuscator preserves both methods because B() is reachable from A().
Include Triggers and Conditional Includes
Removal supports two types of inclusions.
Include Triggers
An Include Trigger identifies a starting point for Removal analysis.
When a method is configured as an Include Trigger:
- The method is preserved.
- All reachable methods are preserved.
- The call graph is analyzed recursively.
For example:
A()
└── B()
If A() is an Include Trigger, both A() and B() are retained.
Conditional Includes
A Conditional Include preserves a specific method without analyzing its descendants.
For example:
A()
└── B()
If A() is configured as a Conditional Include:
-
A()is retained. -
B()may be removed if it is not referenced elsewhere.
Conditional Includes are useful when a specific method must remain available, but its dependencies do not need to be preserved automatically.
Library Assemblies
When Library Mode is enabled for an assembly, Dotfuscator automatically treats all visible types and members as entry points.
This helps preserve the public API surface of reusable libraries and components.
For more information, see Library Mode.
Removal Options
Removal supports two operating modes.
| Option | Description |
| Remove unused metadata and code | Removes unused types, methods, fields, resources, and metadata. |
| Remove only literals (const definitions) | Removes literal constant definitions while preserving other code. |
Using Removal with String Encryption
When String Encryption is enabled, it is recommended to enable Removal and select Remove only literals (const definitions).
This removes original string constants after String Encryption has processed them, helping prevent unencrypted strings from remaining in the protected assembly.
Removal Report
Dotfuscator generates a Removal Report in XML format that describes how each input assembly was processed.
The report includes:
- Assemblies analyzed
- Types and members that were preserved
- Types and members that were removed
- Resource pruning results
- Overall removal statistics
Review the report after a build to verify that required code has been preserved. Configure the Removal Report in the Config Editor, by going to Settings > Reports > Removal.
Limitations
Removal relies on static analysis.
If Dotfuscator cannot determine that code is used at runtime, it may remove elements that are required by the application.
This can occur when applications use:
- Reflection
- XAML
- Runtime type discovery
- Dynamically loaded code
These limitations are similar to those that can affect Renaming. When necessary, configure additional triggers or conditional includes to preserve required code.