I just validated .Net Native on VS2015 & Windows 8.1 (when configured correctly, examine .proj to validate) and building for a particular architecture (may be overkill, haven t validated), will produce a native file which will give you the "harder to reverse engineer" code you are looking for which for me was unabled to read .dll via DotPeek(free .Net decompiler from JetBrains).

That s not how ngen.exe works. It merely runs the JIT compiler up front to generate the .ni.exe or .ni.dll module. That binary file does not contain metadata, only the machine code generated from the IL for the method bodies. The CLR still must find the original assembly. Only then can it determine that there is an ngen-ed image available so that it can use the machine code from it rather than generate it from the assembly s IL.

Ngen.exe speeds up the warm startup time of your app, that s all.

My usual advice to anybody that might be interested in disassembling my assemblies is to point them to sourceforge.net. It has terabytes of source code, written and maintained by programmers that are usually better than me. Sometimes even with good comments. If your obfuscator doesn t work well then shop around for a better one. There are many.

Yesterday, at Build 2014, Microsoft announced .NET Native. According to the FAQ, "... Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications."

If you want to protect your code, an obfuscator is the typical approach. Dotfuscator has been in an arms race with reflector for a while and we use it on our products. In practice, however, a skilled human can easily read obfuscated code.

Compiling to native code defeats the purpose of having a managed language. The main benefit is to allow the target runtime to JIT the IL into something that is optimally palatable for the target CPU. If you want otherwise, you would use something like the ahead-of-time option in mono.

Other answers mention Microsoft s .NET Native compiler but do not tell you how to do that.

Here is a tutorial using CoreRT on how to compile your C# project to native code.

Note: I also had to comment out the following line for everything to work:

<!-- <add key="helloworld" value="https://api.helloworld.org/v3/index.json" /> -->

The output is a roughly 4MB sized executable:

Indeed, the code is no longer readable with .NET decompilers and IDA Pro (a native code disassembler) recognizes it as native code.

Spoon (previously Xenocode) has a product that might fit your needs. We use it for a WPF based installer UI so we don t have to bootstrap .net in order to load the setup program itself.

NGEN adds native code, but it does not remove the MSIL. Therefore, any tool operating on the MSIL can still work. You also need this for reflection, something that would be very hard for a true native compiler.

This is finally possible using Microsoft s .NET Native compiler

It automatically compiles the release version of apps that are written in managed code (C# or Visual Basic) and that target the .NET Framework and Windows 10 to native code.

..

•Your apps will provide the superior performance of native code.

•You can continue to program in C# or Visual Basic.

•You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory management and garbage collection, and exception handling.

For users of your apps, .NET Native offers these advantages:

•Fast execution times

•Consistently speedy startup times

•Low deployment and update costs

•Optimized app memory usage

But .NET Native involves more than a compilation to native code. It transforms the way that .NET Framework apps are built and executed. In particular:

•During precompilation, required portions of the .NET Framework are statically linked into your app. This allows the app to run with app-local libraries of the .NET Framework, and the compiler to perform global analysis to deliver performance wins. As a result, apps launch consistently faster even after .NET Framework updates.

•The .NET Native runtime is optimized for static precompilation and thus is able to offer superior performance. At the same time, it retains the core reflection features that developers find so productive.

•.NET Native uses the same back end as the C++ compiler, which is optimized for static precompilation scenarios.

https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx

This is only available with VS.NET 2015.

this is a free obfuscator, which is quiet good: eazfuscator

I might step back and ask why you are looking for this type of protection. I m not trying to argue that you don t need the protection, but I think it is worth understanding the motivation.

For instance, if you want protection because you have an algorithm in your system where it would be devastating to security if someone reverse-engineered it, then you might need to consider a different approach. It means there is a flaw in the algorithm and no amount of obfuscation or native compiling will help you there.

If is a matter of IP, then I think obfuscation is probably your best approach here. It is kind of like putting a lock on your door. Someone can break the lock and get in, but they are intentionally doing it as opposed to just walking in the door.

This is possible using the IL2CPU compiler. IL2CPU is developed by the same people who make COSMOS (C# Open Source Managed Operating System) and is only available by downloading cosmos. IL2CPU produces ASM files which can be compiled through Nasm (some other assemblers may work but it is best to use nasm). the only problem with IL2CPU is that it is built in to the Cosmos Project and it is quite difficult to get it to run on its own.