Before we can start talking about obfuscation, we need to understand the basics of the .NET Framework. The .NET Framework consists of a large class library that provides solutions to common problems. The other major component of the .NET Framework is a virtual machine called Common Language Runtime (CLR). It abstracts out the computer architecture so that the compiled code can be executed on any CPU architecture having .NET Framework installed. CLR also provides security, exception handling, and my favorite feature: memory management.
When a code written in a .NET language (C#, VB, VC++, etc) is compiled, it is translated into an object-oriented assembly language called Common Intermediate Language (CIL). This allows the code to be portable and executable on any CPU running .NET Framework virtual machine (CLR). During program execution, the Just-in-time compilation is performed where the CIL code is translated into the machine code to be executed on the CPU.

Disassembling
CIL is an assembly language and therefore it is human readable. There are even tools that can perform the reverse translation, from CIL to the source .NET language. The process of reverse translation is called disassembling. In certain situations where a class library documentation is scarce, disassembling an assembly in order to understand inner workings of the assembly can be helpful. One of the most popular free tools used for disassembling assemblies is called Reflector.
It is simple to use and very powerful. There are even tens of free add-ins available for it. They perform function such as code analyses, comparing two versions of the assembly, etc. Here is what a disassembled assembly I wrote for one of the previous posts looks like:

Ability to disassemble an assembly may not always be desirable. In some cases, we prefer to protect the intellectual property and deny unauthorized access the source code. This is where the obfuscation comes into the play.

Obfuscation
Obfuscation is a process of scrambling the CIL code in order to make it difficult to read and understand. The scrambling is done utilizing different techniques such as renaming variables, removing white spaces, rewriting loops, removing new line characters, etc. Besides protecting intellectual property, obfuscation reduces security exposure, and potentially reduces the code size. There are also disadvantages to obfuscation. It does not prevent reverse engineering; it only makes it more difficult. Any highly sensitive code should be encrypted if security is imperative.
The basic version of DotFuscator utility is part of Visual Studio 2008. It provides some basic obfuscation which is not very useful. The commercial version is much more powerful and valuable. A much better, simple free obfuscation tool is EazFuscator. It nicely integrates with Visual Studio as DotFuscator does. Once the Visual Studio project is selected, it obfuscates the assembly for the release builds on every build. EazFuscator does what it is suppose to do without any developer’s control. Lack of the obfuscation control may make it inappropriate for certain commercial use.
Here is how the same assembly from the above picture looks like after EazFuscator has performed its magic:

Conclusion
Obfuscation makes it harder, but not impossible to reverse engineer the CIL code. Some people do not bother obfuscated their code either because they are not aware of the fact that CIL code can be disassembled or just because obfuscation is not foolproof. I have never used obfuscation for personal use since I do not write commercial code that requires intellectual property protection.

Next week
I will cover a productivity tip in “Eliminating repetitive typing”.