Obfuscation

Elements supports state of the art code obfuscation on compiler level, to protect your code against decompilation and reverse engineering. Obfuscation is available for all platforms, but is especially relevant on .NET, Java and Cocoa, which normally expose human-readable class and member names in the executable.

When obfuscation is applied (controlled via the compiler-provided Obfuscate aspect), the compiler will mangle the names of all types and their members to be unreadable and confusing to reverse engineers. It can do so even for class libraries, without impacting your ability to reference these libraries and reference the obfuscated types and members via their original readable names.

Enabling Obfuscation

To enable Obfuscation, you simply apply the Obfuscate aspect to your code, either for the entire project, or to individual types or members you want obfuscated.

Referencing Obfuscated libraries

On library projects, the optional "Create .fx File" project setting will task the compiler to generate an optional .fx file with metadata that allows you to still reference the obfuscated members with their real names. (.fx files are always generated (and required for referencing) for Cocoa and the Island-backed platforms, but are optional for .NET and Java).

The binary files emitted by the compiler (e.g. .dll, .jar, .a, .dylib or .so files) will only contain the obfuscated and unreadable names – and those are the files that will make up or contribute to your shipping product. The .fx file for your libraries will contain additional metadata that allows the Elements compiler to refer to your types and members using their original, readable names

See Also