The processor cannot directly interpret an assembly. .NET assemblies consist mainly of a second language known as Common Intermediate Language (CIL), or IL for short.13 The C# compiler transforms the C# source file into this intermediate language. An additional step, usually performed at execution time, is required to change the CIL code into machine code that the processor can understand. This involves an important element in the execution of a C# program: the Virtual Execution System (VES). The VES, also casually referred to as the runtime, compiles CIL code as needed (a process known as just-in-time compilation or jitting). The code that executes under the context of an agent such as the runtime is termed managed code, and the process of executing under control of the runtime is called managed execution. The code is “managed” because the runtime controls significant portions of the program’s behavior by managing aspects such as memory allocation, security, and just-in-time compilation. Code that does not require the runtime to execute is called native code (or unmanaged code).

The specification for a runtime is included in a broader specification known as the Common Language Infrastructure (CLI) specification.14 An international standard, the CLI includes specifications for the following:

note

The term runtime can refer to either execution time or the VES. To help clarify the intended meaning, this book uses the term execution time to indicate when the program is executing, and it uses the term runtime when discussing the agent responsible for managing the execution of a C# program while it executes.

Running within the context of a runtime execution engine enables support for several services and features that programmers do not need to code for directly, including the following:

note

This section provides a brief synopsis of the CLI to familiarize you with the context in which a C# program executes. It also provides a summary of some of the terms that appear throughout this book. Chapter 24 is devoted to the topic of the CLI and its relevance to C# developers. Although the chapter appears last in the book, it does not depend on any earlier chapters, so if you are eager to become more familiar with the CLI, you can jump to it at any time.

As mentioned in the introduction of this section, the C# compiler converts C# code to CIL code and not to machine code. The processor can directly understand machine code; therefore, CIL code needs to be converted before the processor can execute it. Given an assembly, it is possible to view the CIL code using a CIL disassembler utility to deconstruct the assembly into its CIL representation. (The CIL disassembler is affectionately referred to by its Microsoft .NET Framework specific filename, Ildasm, which stands for IL Disassembler.) Ildasm will disassemble an assembly and extract the CIL generated by the C# compiler into text.

The output that results from disassembling a .NET assembly is significantly easier to understand than machine code. For many developers, this may raise a concern because it is easier for programs to be decompiled and algorithms understood without explicitly redistributing the source code. As with any program, CLI based or not, the only foolproof way of preventing disassembly is to disallow access to the compiled program altogether (e.g., hosting a program only on a website instead of distributing it out to a user’s machine). However, if decreased accessibility to the source code is all that is required, there are several obfuscators available. Obfuscators read the IL code and transform it so that it does the same thing but in a way that is much more difficult to understand. This technique prevents the casual developer from accessing the code and creates assemblies that are much more difficult and tedious to decompile into comprehensible code. Unless a program requires a high degree of algorithm security, obfuscators are generally sufficient.

AdVanced Topic

CIL Output for HelloWorld.exe

The exact command used for the CIL disassembler depends on which implementation of the CLI is used. Instructions are available at http://itl.tc/ildasm. Listing 1.22 shows the CIL code created from running Ildasm.

Listing 1.22: Sample CIL Output

.assembly extern System.Runtime

{

  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )

  .ver 4:2:0:1

}

 

 

.assembly extern System.Console

{

  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )

  .ver 4:1:0:1

}

 

 

.assembly 'HelloWorld'

{

  .custom instance void [System.Runtime]System.Runtime.CompilerServices.CompilationRelaxationsAttribute::.ctor(int32) = (01 00 08 00 00 00 00 00 )

  .custom instance void [System.Runtime]System.Runtime.CompilerServices.RuntimeCompatibilityAttribute::.ctor() = (01 00 01 00 54 02 16 57 72 61 70 4E 6F 6E 45 78 63 65 70 74 69 6F 6E 54 68 72 6F 77 73 01 )

  .custom instance void [System.Runtime]System.Runtime.Versioning.TargetFrameworkAttribute::.ctor(string) = (01 00 18 2E 4E 45 54 43 6F 72 65 41 70 70 2C 56 65 72 73 69 6F 6E 3D 76 33 2E 30 01 00 54 0E 14 46 72 61 6D 65 77 6F 72 6B 44 69 73 70 6C 61 79 4E 61 6D 65 00 )

  .custom instance void [System.Runtime]System.Reflection.AssemblyCompanyAttribute::.ctor(string) = (01 00 0A 48 65 6C 6C 6F 57 6F 72 6C 64 00 00 )

  .custom instance void [System.Runtime]System.Reflection.AssemblyConfigurationAttribute::.ctor(string) = (01 00 05 44 65 62 75 67 00 00 )

  .custom instance void [System.Runtime]System.Reflection.AssemblyFileVersionAttribute::.ctor(string) = (01 00 07 31 2E 30 2E 30 2E 30 00 00 )

  .custom instance void [System.Runtime]System.Reflection.AssemblyInformationalVersionAttribute::.ctor(string) = (01 00 05 31 2E 30 2E 30 00 00 )

  .custom instance void [System.Runtime]System.Reflection.AssemblyProductAttribute::.ctor(string) = (01 00 0A 48 65 6C 6C 6F 57 6F 72 6C 64 00 00 )

  .custom instance void [System.Runtime]System.Reflection.AssemblyTitleAttribute::.ctor(string) = (01 00 0A 48 65 6C 6C 6F 57 6F 72 6C 64 00 00 )

  .hash algorithm 0x00008004

  .ver 1:0:0:0

}

 

 

.module 'HelloWorld.dll'

// MVID: {05b2d1a7-c150-4f20-bd96-c065e4f97a31}

.imagebase 0x00400000

.file alignment 0x00000200

.stackreserve 0x00100000

.subsystem 0x0003  // WindowsCui

.corflags 0x00000001  // ILOnly

 

 

.class private auto ansi beforefieldinit HelloWorld.Program extends[System.Runtime] System.Object

{

 

 

  .method private hidebysig static void Main(string[] args) cil managed

        {

    .entrypoint

    // Code size 13

    .maxstack 8

    IL_0000: nop

    IL_0001: ldstr "Hello. My name is Inigo Montoya."

    IL_0006: call void

↪ System.Console]System.Console::WriteLine(string)

    IL_000b: nop

    IL_000c: ret

    } // End of method System.Void HelloWorld.Program::Main(System.String[])

 

 

  .method public hidebysig specialname rtspecialname instance void .ctor() cil managed

    {

    // Code size 8

    .maxstack 8

    IL_0000: ldarg.0

    IL_0001: call instance void [System.Runtime]

        System.Object::.ctor()

    IL_0006: nop

    IL_0007: ret

    } // End of method System.Void HelloWorld.Program::.ctor()

} // End of class HelloWorld.Program

The beginning of the listing is the manifest information. It includes not only the full name of the disassembled module (HelloWorld.dll) but also all the assemblies it depends on, along with their version information.

Perhaps the most interesting thing that you can glean from such a listing is how relatively easy it is to follow what the program is doing compared to trying to read and understand machine code (assembler). In the listing, an explicit reference to Console.WriteLine() appears. There is a lot of peripheral information to the CIL code listing, but if a developer wanted to understand the inner workings of a C# assembly (or any CLI-based program) without having access to the original source code, it would be relatively easy unless an obfuscator is used. In fact, several free tools are available (such as Red Gate’s Reflector, ILSpy, JustDecompile, dotPeek, and CodeReflect) that can decompile from CIL to C# automatically.

________________________________________