This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

■

Note

There is one point to be made regarding the abbreviation “IL.” During the development of .NET, the offi-

cial term for IL was Microsoft intermediate language (MSIL). However with the final release of .NET, the term was

changed to common intermediate language (CIL). Thus, as you read the .NET literature, understand that IL, MSIL,

and CIL are all describing the same exact entity. In keeping with the current terminology, I will use the abbreviation

“CIL” throughout this text.

C H A P T E R   1  

■

T H E   P H I L O S O P H Y   O F   . N E T

11

8849CH01.qxd  10/1/07  10:30 AM  Page 11

---

When a *.dll or an *.exe has been created using a .NET-aware compiler, the resulting module

is bundled into an 

assembly. You will examine numerous details of .NET assemblies in Chapter 15.

However, to facilitate the discussion of the .NET runtime environment, you do need to understand

some basic properties of this new file format.

As mentioned, an assembly contains CIL code, which is conceptually similar to Java bytecode

in that it is not compiled to platform-specific instructions until absolutely necessary. Typically,

“absolutely necessary” is the point at which a block of CIL instructions (such as a method imple-

mentation) is referenced for use by the .NET runtime.

In addition to CIL instructions, assemblies also contain 

metadata that describes in vivid detail

the characteristics of every “type” living within the binary. For example, if you have a class named

SportsCar, the type metadata describes details such as SportsCar’s base class, which interfaces are

implemented by SportsCar (if any), as well as a full description of each member supported by the

SportsCar type.

.NET metadata is a dramatic improvement to COM type metadata. As you may already know,

COM binaries are typically described using an associated type library (which is little more than a

binary version of Interface Definition Language [IDL] code). The problems with COM type informa-

tion are that it is not guaranteed to be present and the fact that IDL code has no way to document

the externally referenced servers that are required for the correct operation of the current COM

server. In contrast, .NET metadata is always present and is automatically generated by a given .NET-

aware compiler.

Finally, in addition to CIL and type metadata, assemblies themselves are also described using

metadata, which is officially termed a 

manifest. The manifest contains information about the cur-

rent version of the assembly, culture information (used for localizing string and image resources),

and a list of all externally referenced assemblies that are required for proper execution. You’ll

examine various tools that can be used to examine an assembly’s types, metadata, and manifest

information over the course of the next few chapters.