Before you consider ordering any .NET obfuscator you should know that some contemporary .NET disassemblers can find which obfuscator has been used for your app protection and produce a clean assembly which it can reverse easily. So .NET obfuscator software became questionable.
Rustemsoft developed a new type of .NET protection software that transforms .NET code into machine codes.

Guardship is the unique .NET protection tool that proves real security for your production software. Unlike Skater .NET obfuscator that makes the unauthorized reverse-engineering more difficult by symbol renaming, control-flow algorithms, encrypting etc., Guardship completely stops MSIL disassemblers. This is the assurance that no one will see your source code.

When compiling to .NET managed code, the compiler translates your source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code. Guardship is not a .NET code obfuscator. It transforms the revealed MSIL code of your executables into native unmanaged representation that keeps all .NET metadata unaffected. It grants the same layer of protection as native ASM and C++ code.

C# / VB.NET assemblies contain metadata that C++ assemblies do not, which can be helpful in decompilation. C# and VB.NET compile down into MSIL which maps much better to the original source code than does C++'s machine code output. Regular .NET Obfuscator can help, but it cannot prevent reverse-engineering; it can only make it harder. Much more information about your application source code, such as metadata including class structure, methods body etc., can be extracted from scanning the MSIL than from scanning highly optimized binary machine code produced from ASM or C++ compiler. Guardship gives ability to keep coding in high-level OOP languages (C# / VB.NET) but completely secures your intellectual property.

How does the Guardship protect your .NET executables?
It disassembles your .NET code and then compiles the MSIL code of your executable into native unmanaged application by generating new EXE

Your applications (WinForms, WPF, etc.) that target the .NET Framework are compiled to intermediate language (IL). At run time, the just-in-time (JIT) compiler translates the IL to native code. Guardship .NET Protector translates your .NET executable to native code to make it hidden. When you run the protected executable it has all features and functionalities of managed application performing in PC memory. But .NET assembly browsers and decompilers will not be able to read your protected .NET executables.

Why does Guardship convert to unmanaged executable?
There are a few disassemblers for decompiling unmanaged executables written in ASM, C, or C++. However none of them will manage to produce readable enough code to worth the effort. You will spend more time trying to read the decompiled source with assembler blocks inside, than writing the same-functioning application from scratch.

In fact, any executable module can be disassembled and explored. The easiness with which a decipherer can reverse-engineer your application source code depends on how complete metadata about the app?s source code presents inside the exe module. May the decipherer figure out the original class names, methods, work flows, structures, etc.? A compiler basically compacts app?s source code, transforming the output into a format which is much compliant to machine runtime execution. It could be a native machine code or IL byte code that is treated by CLR intermediate runtime. However by and large, a lot of information about your application source code (debugging, comments, etc.) is simply can be lost during the compact compilation.

ASM, C, and C++ ordinarily compile directly to a native machine code. But neither the ASM, C, nor C++ standard describes the layout of a binary executable produced by the compiler. An optimizing C++ compiler, for instance, can do a lot of efforts to increase performance, including optimizing out certain variable declarations or removing entire methods and classes. Not so much info about the original C++ code certainly needs to be present in the binary exe module. A decipherer would still be able to disassemble the code, however extracting any ASM, C, or C++ code out of the assembly would be an act of guessing and puzzling out.

Guardship has a few restrictions only:

The protection can be provided for .exe files only. It does not protect .NET dll libraries.

The final protected output executable will not be able to use related files in the start directory "by default". That means all referenced libraries (dlls) should be registered for whole PC scope in GAC. .NET JIT first search for the dlls in a local folder near exe file. However your exe will run in PC RAM memory not in the start directory. So you have to install the referenced Assemblies into the Global Assembly Cache before using your protected exe. Alternatively the referenced .NET assemblies (managed) can be linked into the final exe. Please use the Linker interface for that.

Also all another data files located in the folder near exe file (non-dlls) should have to have an exact path specified in your executable code.
Alternatively the files can be incorporated into your exe as .NET project's Resources.

How to define in the application code where the protected executable is installed?
During your production .NET executable installation from your Setup package on a client?s PC there will be some data files installed into the same folder near the .exe file. These data files can be useful for your executable run-time implementation. Let say, you will store some settings in that data files. People usually define the path to executable to access that files in the app?s code. Another people access the executable?s related files in the start directory ?by default? without an exact path specified. However your protected exe will run in PC RAM memory not in the start directory. From program YourAppName.exe located in C:/Dir you need to open text file C:/Dir/text.txt. You don't know where YourAppName.exe could be located, but text.txt will always be in the same path. How to define the start directory path from within the program itself so that you can access the text file?
For example, your production exe module has name: YourAppName.exe. The start module after protection will have MS-DOS Application name: YourAppName.com. We need to identify the folder path where the YourAppName.com executable started from.