.NET Encryptor encrypts your application assemblies using your own unique strong name. The encrypted assemblies are added as embedded resources to a small "bootstrap" application project (written in VB.NET or C#). The bootstrap application displays a splash screen and calls the AssemblyLoaderx86 or AssemblyLoaderx64 DLL to decrypt and execute the main assembly of your application. The "bootstrap" project builds the application executable that you distribute to your customers. You can fully customize the assembly attributes (version, icon, name etc) and splash screen of the bootstrap application to match your requirements. The encryption process can be fully automated by adding a "Pre-build" event to the bootstrap project that calls NetEncryptor.exe to encrypt each of the application assemblies. The sample projects demonstrate this technique.
If you are looking for a way of protecting your .NET code from decompilation without the hassles of obfuscation then .NET Encryptor may be the solution you are looking for.
.NET Encryptor is designed for protecting .NET desktop applications and associated assemblies. It does not protect ASP.NET apps or standalone .NET library assemblies that are not distributed as part of an application.
Unlike obfuscators and some protectors .NET Encryptor does not modify your assemblies. It encrypts them and then decrypts and loads them dynamically when your application is run. A major issue with obfuscators and other protectors is that code that relies on .NET Reflection (as much data binding and serialization code does) will often not work correctly or behave differently when protected. This means that often bugs will only show up after the code has been protected. Because the code is obfuscated/protected this can make debugging the source of the problem very difficult.
Many code protection products wrap your .NET assemblies up into a native Win32 bootstrap application. While this can seem like a good thing it actually has the potential to cause problems because the entry .NET assembly (returned by Assembly.GetEntryAssembly) may be null or not associated with a file location. This can cause code that relies on this (such as settings code or control licensing) to fail when the code is protected. Another issue with this approach is that you can not compile a single AnyCPU application that will run on both Win32 and Win64 platforms in the appropriate mode (ie 32 bit on Win32 platforms and 64 bit on Win64 platforms). Many protectors don't even support managed x64 applications at all. The entry point for .NET Encryptor applications is a small bootstrap assembly written in either VB.NET or C#. You can fully customize this bootstrap assembly as required for your application. You can create x86 specific applications (that will also run on Win64 platforms using WOW64), x64 specific applications or Any CPU applications.
When evaluating code protection software it is important to try it on your real application. Some code protection products that work well on small sample projects can cause major issues when used for real, complex applications that use data binding, serialization or reflection. In particular you should consider how the product handles error reporting. If you are using an obfuscator then, unless it provides a stack decryption mechanism, the stack trace will be meaningless.
All code encryption products are vulnerable to attack at the point at which the code is decrypted and executed. If a cracker is able to intercept your code at this point they can dump the unencrypted code. Infralution .NET Encryptor employs anti-debugging techniques to make this more difficult and prevent the use of generic cracking/dumping tools. Beware of code protection tools that promise 100% code security as there is simply no way to achieve this when the code is executed on a computer that you don't have control over. You may end up paying a lot more for a solution that offers no real increase in security.
.NET Encryptor can be used in conjunction with an obfuscator to provide a double layer of protection. In this case you would obfuscate your assemblies first and then encrypt them using .NET Encryptor.