that .NET binaries take the same file extension as COM servers and unmanaged Win32 binaries
(*.dll or *.exe), they have absolutely no internal similarities. For example, *.dll .NET binaries do
not export methods to facilitate communications with the COM runtime (given that .NET is not
COM). Furthermore, .NET binaries are not described using COM type libraries and are not registered
into the system registry. Perhaps most important, .NET binaries do not contain platform-specific
instructions, but rather platform-agnostic intermediate language (IL) and type metadata. Figure 1-2
shows the big picture of the story thus far.
■Note There is one point to be made regarding the abbreviation “IL.” During the development of .NET, the official 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.
When a *.dll or *.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 11.
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 implementation) 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 information
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 current 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.
When a *.dll or *.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 11.
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 implementation) 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 information
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 current 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.
No comments:
Post a Comment