Assemblies compiled using the .NET framework contain MSIL (Microsoft Intermediate
Language) instructions that are executed by the .NET runtime just-in-time compiler
when your application is run on the user machine. The just-in-time compiler converts
the MSIL instruction to native machine instructions which are then processed by
the machine. The MSIL instructions, together with class, methods, fields and other
metadata information available inside a compiled assembly makes it possible for
tools like .NET reflector, dotPeek and JustDecompile to translate the code back
to its source language (C#, VB or any other .NET language).
Symbol renaming doesn't modify the MSIL instructions at all, it only changes the
names of classes and methods but leaves the MSIL instructions untouched. In fact,
symbol renaming doesn't offer a good solution for guarding software against unauthorized
distribution. Even if symbols are renamed a hacker could still identify where license
validation take place and simply patch the assembly to circumvent license validation
all together.
By applying code encryption you make it significantly more difficult for someone
to read your code and modify your assembly. Agile.net encrypts the MSIL code and
keeps it in a secure storage. When the assembly is loaded Agile.NET binds to the
.NET runtime engine and manages decrypting the MSIL on a per method basis. Agile.NET
creates a runtime environment that executes the original MSIL code by decrypting
one method at a time, this important virtue minimizes the exposure of MSIL code
in memory and thus prevents dumping the code from physical memory.
Code encryption adds a native component that has to be shipped together with the encrypted software. The native component binds to the .NET runtime and takes control of method execution. Agile.net support both x32 and x64 platform by adding x32 version as well as x64 version of the runtime component. By default Agile.net embeds the runtime components directly into the encrypted assembly. Doing so there is no need for you to add the runtime components to the deployment package explicitly. If you still like to explicitly add them to the deployment package you can do so by checking the 'disable runtime embedding' option available in the options dialog.
Code encryption is much easier to integrate with existing software, while symbol renaming may introduce errors due to usage of reflection API in your code and therefore may demand additional configuration code encryption isn't expected to introduce such errors.
To enable code encryption: