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 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 to combine several assemblies into one
- 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 with dynamic VB.NET code