|Dotfuscator > Configuring Dotfuscator via the GUI > The Removal Editor > Understanding Include Triggers and Conditional Includes|
Dotfuscator can statically analyze an application to determine which elements are not actually used and remove those elements from the output binaries, reducing application size.
The static analysis works by traversing your code, starting at a set of methods called “triggers," or entry points. In general, any method that you expect external applications to call must be defined as a trigger. For example, in a simple standalone application, the
Main method would be defined as a trigger. An assembly can have more than one trigger defined for it.
Note that turning on library mode for an assembly causes Dotfuscator to treat all visible types and members as entry points, automatically.
As Dotfuscator traverses each trigger method’s code, it notes which fields, methods, and types are being used. It then analyses all the called methods in a similar manner. The process continues until all called methods have been analyzed. Upon completion, Dotfuscator is able to determine a minimum set of types and their members necessary for the application to run. Only these types are included in the output assembly.
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. To avoid this, you configure Include Triggers to tell Dotfuscator which class members (method, property, field, event) should be treated as "entry points" for the static analysis. Dotfuscator will preserve those members and all descendants of those members in the call graph.
Sometimes, though, this isn't the most optimal behavior. Consider an application that loads a set of types via reflection, casts them to an interface, and then invokes methods on that interface - a plugin model, essentially. Dotfuscator's static analysis won't identify the types that could potentially be loaded, but it does know which methods on that interface are going to be called.
In such a case, you should configure the types as Conditional Includes. Dotfuscator will include them and figure out that they implement the interface. If it determines that some of the methods in the interface are unused, it will prune those methods from the interface, and from all the implementations in the conditionally included types. Methods that weren't pruned will then be further analyzed for pruning, as usual.