In the Support Corner, we’ve seen coding patterns that require special Dotfuscator configuration. These configurations are typically stored in a DotfuscatorConfig.xml file. In certain circumstances, it may be preferable to use Obfuscation Attributes, which allow developers to inline obfuscation settings directly in the source code.
Please recall the Support Corner article “Protecting .NET applications that use Entity Framework,” which described how ORM frameworks map object names to database table names. Because of this, we exclude entity classes from Renaming to prevent a runtime exception after obfuscation:
These exclusions could be translated into Obfuscation Attributes:
and
By translating to Obfuscation Attributes, we identify and remediate the potential runtime exception without touching the build server. We don’t even need to install Dotfuscator, because the Obfuscation Attribute is defined in the System.Reflection namespace. When this code is sent to the build server, Dotfuscator reads and honors the Obfuscation Attributes. If additional settings are supplied in a DotfuscatorConfig.xml, the rules will be logically ORed together.
As developers working on the codebase daily, we can set configurations earlier than DevOps Engineers or Build Managers. Adding Obfuscation Attributes in code can spare testing, debugging, and configuration — and save time later in the process.
If you have feedback on this topic or other topics you would like us to discuss in the Support Corner, please contact us at support@preemptive.com.