Securing .net app code against reverse engineering

If the debug and walkback support is left in, the runtime code can decompiled very effectively.  You can compile without debug support and walkbacks, but then if anything happens at runtime there is no indication of what the problem is -- and the code can still be decompiled.  A good decompiler such as Snowman or Boomerang can produce code that may not be identical to what you wrote, but is close enough that a good programmer can figure out what is going on.

https://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Decompilers

What is it that you are trying to protect?  There may be a different approach.

You need to obfuscate your code. There are a few tools on the market that will obfuscate your C# code. Have a look at the following:
Dotfuscator | .NET Obfuscator
Redgate's .NET obfuscator
Agile.net
Here is a free version of Skater .NET Obfuscator:
Skater .NET Free Obfuscator
You can also read up more on Dotfuscator Community edition here.

At first do an estimation on how much does your software is worth....if it's high valueble then no matter what someone will always have the skills to crack it...just take a look at the pirated software...every single protection scheme is defeated pretty much in a few days after releasing to market.
Otherwise relax...take your pick on one of the obfuscators and along with the recommendations by the other Experts do the the essential ...also  try to keep it like somewhat as a service... unless you are around accidental user won't go far..or it's meaningless.
Also a good idea is to create some dlls in a low level language like C/C++ which are harder to reverse them and move some crucial elements of your application to them.

I'm just adding my agreement with John. As long as it's .NET, decompiling is easy and obfuscation isn't really good protection. Move critical code into C/C++ libraries (which will perform better, too).

C/C++ can also be decompiled.  Reverse engineering is not illegal in many places and you can't really block it.  You can only mitigate it with licenses, and legal contracts.  It all depends on how you sell it.  Even with the legal contract, if someone not related to the purchasers of the contract gets a hold of your software they can still decompile it because they aren't bound by the license or contract.

> C/C++ can also be decompiled....

Yes, but the result is typically much more abstract / different than the original source, compared to decompiled .NET code. Most decompiled .NET code is so close to the original, it's ridiculous. Not to mention tools like dotPeek will also decompile AND generate a project/solution for you with the decompiled code in about 3 or 4 clicks...

At a certain point it comes down to effort.

It doesn't matter.  You can still recompile that abstract code back to an executable.  You don't have to reproduce the original code.  You can just add on to the abstract code.  There are people that have deep understanding of C code syntax and don't consider the decompiled code to be more effort to understand.

You can only mitigate the reverse engineering with licenses and contracts.  Anyone can decompile code and work with it.  It's the nature of code.

Someone that understands machine code, although far fewer these days, would be able to work in assembly too.  If someone actually understand machine code, they could hex edit the code and make changes that way too.  "Effort" depends on your level of understanding of code.

You make my point. As higher-level languages become more prevalent, you have less people who understand the lower level languages. However, there's really no point at which it's completely impossible. However, as you go lower, it does increase effort, especially since you have to deal with more "little" aspects like proper memory management instead of just patching a value and recompiling (and letting the CLR do all the work).

That said, I don't really understand how licenses and contracts are effective practical measures. If someone is already willing to go down the path of decompiling or reverse engineering, a license isn't likely to stop them. Don't get me wrong - they are good for those who are going to play by the rules but if the concern is about protecting against code theft and decompiling, then the solution should be a out how to make those efforts high enough to discourage all but the most determined people.

For example, I have almost 30 years of programming experience under my belt and can read and write in C, C++, and C# quite well but whereas I can peek at nearly-intact C# code with a couple clicks, I dread the thought of trying to walk through decompiled C or C++ (and if I never have to touch assembly again in my life, I will be a happy person).

My Point is that there's no really good solution to reverse engineering.  It's legally allowed.  It's how the computer industry grew.  The only way to mitigate it is through legal means.  There's no good technical way to block it.

It's not really legally allowed in every circumstance, but legalities are not going to matter to someone who has underhanded intentions. Just look at software piracy - if legal means were effective, we wouldn't have software piracy. Piracy is effectively combated by implementing technical schemes (e.g. software activations). Those mechanisms can be circumvented but they can be complex enough to make it difficult to do. Even after the fact, the cracked software are often tainted with malware so that there's a significant risk in obtaining it. If you think about open-source software that is only protected by licenses, you'll find blatant and rampant misuse of the technology (code used in ways that are prohibited by the licenses), but nobody bothers pursuing the legal suits unless there is something significant at stake (e.g. Google and Oracle's lawsuit regarding the proper use of Java). The costs of that pursuit are so high that it would require a large compensation at the end.

So like any security concept, it's primarily successful by setting up multiple technical layers / barriers to discourage attempts, so that if one barrier is broken through, the next barrier is perhaps too much. You can't be 100% successful if someone is absolutely determined, but again, it's all about cost / effort vs. benefit.

Last but not least....lets assume that we have a killer application ..that worth's millions....we are talking about "big money"...even if its protected by an unbreakable system...there is always the "solution" of instead of targeting the "computer" to target the "human factor"...so instead of inversting thousands of hours/money on cracking the application there is always the possibility of exploiting the human weaknesses to get "access"....

If you think reverse engineering is about piracy, you've been brainwashed.  You just need to look to Zynga  https://en.wikipedia.org/wiki/Zynga#Intellectual_property_infringement

It may be questionable, but it's legally allowed.

I was referring to piracy as an example where legal means are insufficient.

We're detracting from the real conversation.

There is no good solution to reverse engineering.  It's legally allowed and any skilled individual that can read decompiled source can do it.  You can only mitigate it.  It requires that you be vigilant on multiple fronts both technical and legal.   The current modern computer industry would not exist without it.  You're never going to stop it all.  You can only make it more difficult for someone to do it.  It also depends on how popular your software may be.

Your Intellectual Property can be legally protected by Copyright, Trademark and Patents.