#
Choosing .NET Reactor Protection Settings
Enabling more protection features generally makes the output harder to analyze and reverse-engineer. The right combination also depends on compatibility and runtime performance.
#
Start with the default settings
.NET Reactor enables Obfuscation, String Encryption, and Anti ILDASM by default rather than applying every protection at once. Start with these settings, protect your application, and test it.
Then enable additional features one at a time and test after each change. This makes it easier to identify which setting causes a compatibility or performance issue.
Keep Obfuscation enabled as your minimum protection. Preserve names needed by reflection, serialization, or applications that use your public API. Use Declarative Protection or the Advanced Rules Editor for these exceptions instead of disabling obfuscation for the whole assembly.
#
What cannot be recovered from the protected assembly
Obfuscation replaces the original type and member names. Merge Enums combines enum types and removes their original separation. The overwritten names and enum structure cannot be recovered from the transformed metadata.
Someone who understands the remaining code may be able to guess meaningful names or enum groupings. Those guesses do not establish what the originals were.
A separately saved mapping file can still translate obfuscated names because it records them during protection. Keep it private for stack trace deobfuscation. It does not reconstruct the original enum structure.
#
Consider runtime performance
The table gives a general guide to runtime overhead. Actual impact depends on the application.
If runtime performance must remain unaffected, limit protection to Obfuscation, Merge Enums, and Anti ILDASM. Merge Enums only applies to enums that are renamed by obfuscation.
Do not use Code Virtualization on performance-sensitive methods. Apply it only to selected methods using declarative protection or advanced rules. Control Flow Obfuscation can also be costly in frequently executed code.
Compare startup time and method execution times with an unprotected build, both on first use and after warm-up.
#
Distribute PDB files only when necessary
PDB files contain source file names. A name such as OrderService.cs can suggest the original class name even after the class has been renamed in the protected assembly.
Only distribute PDB files when they are genuinely needed. Otherwise, keep them private for debugging. Follow the Publishing guidelines to review loose PDBs, embedded symbols, source information, and private diagnostic archives.
#
Check publishing requirements
When protecting before ReadyToRun, disable NecroBit, Anti Tampering, and Inject Invalid Metadata. For trimming, the requirements depend on whether it runs before or after protection.
For .NET SDK single-file publishing, publish first, then open and protect the bundle in .NET Reactor.
Test and verify the final protected package before shipping it.
#
Related topics
Reflection problems · Protect a library · ReadyToRun