10.2. General Best Practices
Please carefully read the list below. Not only will this bring you better obfuscation results, but this will also help you to avoid possible pitfalls.
- Use minimal but feasible visibility of the classes and their members
- Avoid using
System.Runtime.CompilerServices.InternalsVisibleToAttributeattribute for production assemblies. If you have to use that attribute, consider alternatives - Use
CLSCompliantAttribute(true)to mark CLS-compliant assemblies. If you produce library or component which can be used by your customers then you should mark the assembly as CLS-compliant to ensure successful interoperability. Eazfuscator.NET internally uses the value ofCLSCompliantAttributeto make a decision on the level of obfuscation to apply. Eazfuscator.NET turns off all CLS-incompatible obfuscation features when the input assembly is marked as CLS-compliant - Try to keep a reasonably small number of assemblies in your product. It leads to a greater code integration inside one assembly; thus, it is harder to deduct the logic contained inside the assembly. Assembly number reduction can be achieved at the application design phase. Alternatively, assemblies merging feature can be used for that purpose
- Consider to use symbol encryption in production releases of your product. It allows you to decode error stack traces and log files
- It is highly recommended to sign your assemblies with a strong name. The signed assemblies are better protected against integrity violations
- Consider to use resource encryption to hide sensitive assembly resources from prying eyes
- Please consider to virtualize the methods that you want to hide by any means possible
- Test your product after obfuscation
Additional for Visual Basic .NET
- It is highly recommended to use
Option Strict Onto achieve good obfuscation results and avoid common problems. Alternatively, you may use a compatibility mode to workaround possible issues