Exploring .NET Assemblies

This article is one of a series of articles exploring .NET Assemblies.
Exploring .NET Assemblies
Multi-File Assemblies
Strong Named Assemblies
Placing Assemblies in the Global Assembly Cache (GAC)
Administrative Configuration of Applications
The articles are intended for programmers who are using .NET for a while, and wish to know more about .NET assemblies.

Introduction
Assemblies are the smallest deployment units possible in the .NET environment. Assembly is the term to describe a .NET executable (.exe) or class library (dll) file. A .NET assembly contains two main parts: The Manifest and the IL code. The Manifest contains all the metadata of the assembly: The Version and ID of the assembly, public keys, references and more. The IL code is a binary representation of the intermediate language which is very similar to Assembly language. The fact that an IL code is in the assembly file, and not C# or VB.NET, enable us to program in any .NET language we want (currently there are more than 20 managed languages), and even combine languages. All of the code is compiled into the IL code, which is similar no matter what language you programmed in.

There is not much of a difference between an Exe file and a Dll file. The obvious difference is the fact that an Exe file can be executed, while a Dll cannot be executed. Other than that the only difference is the Main method in the Exe code, which is the entry point of the Assembly. There is nothing else to distinguish between an Exe and a Dll. You can even reference an Exe just as you reference a Dll (It is not supported by the .NET 2003 IDE though, you can use the csc.exe compiler to add references to Exe files).

Solving The Dll Hell
A known problem with native Dlls and COM components was called "Dll Hell". In short, the problem was that no multiple versions were able to be stored at the same time, which caused problems in deployment.
.NET solved the problem by putting versions inside the assemblies manifests. This way two assemblies with different versions can co-exist in the same computer.
Another advantage of .NET is the ease of deployment. In order to run the application, the exe with all referenced dlls should be placed in the same windows folder (This is the most simple scenario). With a simple copy of files the application can be installed in a different location. No need of registry or any additional installations.

Exploring the Assembly
There is a very nice tool to explore the .NET assemblies called ildasm. To run ildasm you need to run the .NET Command Prompt (from the Start->Programs->.NET 2003->.NET Tools folder). Then by typing "ildasm" you start the application. The option "ildasm /adv" will show more properties of the assembly. Opening an Assembly (any .NET exe or dll file), will show its contents in a tree view. First we can see the Manifest file (by double clicking on it). We see the references, followed by the Assembly Info (as it appears in the AssemblyInfo attributes), resources and other information.
After the Manifest we can see the Assembly types. Each type can be expanded to see all the methods, members, properties and events. By double-clicking on a method, for example, we can see the IL code of the method.

Another option is the View->MetaInfo->Show! . Here is all the metadata which is exposed by the Reflection mechanism in .NET, among other things, such as list of constant strings used in the assembly. You can use File->Dump to save the assembly contents to a file.

Reflector
A very nice (and free) tool is Reflector. This tool is a MUST. It can be downloaded from here: http://www.aisto.com/roeder/dotnet/ . The tool has nicer UI than ildasm, and it can show you the code in C# and VB.NET. So you can view Dlls and Exes that you did not write, and even disassemble the code for you. You can even see the code of .NET Framework dlls, such as System.IO, System.Xml etc.
Tons of Add-ins can be found here: http://www.aisto.com/incoming/Reflector/AddIns/ (search Google for more).

Everyone Can See Your Code
Yes, this is true. You cannot hide your code. Everyone with ildasm or Reflector can disassemble your code and see it.
First, this is not such a problem. Even for native assemblies, with some effort the exe and dll files can be disassembled. With the assumption that any hacker can see your code eventually, Microsoft did not bother to make it hard for people to disassemble the code.
What you can do is make the code hard to read. For this there is a tool called Dotfuscator (which is installed with .NET). The tool makes the code less readable. Here is a link to articles about this tool: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dotfuscator/dotf3e5x.asp