| The Common Language Infrastructure (CLI) provides a specification for executable code and the execution environment (the Virtual Execution System, or VES) in which it runs. Executable code is presented to the VES as modules. A module is a single file containing executable content in the format specified in Partition II, sections 21 24. | The remainder of this section and its subsections contain only informative text. |
At the center of the Common Language Infrastructure (CLI) is a unified type system, the Common Type System (CTS), that is shared by compilers, tools, and the CLI itself. It is the model that defines the rules the CLI follows when declaring, using, and managing types. The CTS establishes a framework that enables cross-language integration, type safety, and high performance code execution. This section describes the architecture of CLI by describing the CTS. The following four areas are covered in this section: The Common Type System. See Partition I, section 8. The Common Type System (CTS) provides a rich type system that supports the types and operations found in many programming languages. The Common Type System is intended to support the complete implementation of a wide range of programming languages. Metadata. See Partition I, section 9. The CLI uses metadata to describe and reference the types defined by the Common Type System. Metadata is stored ("persisted") in a way that is independent of any particular programming language. Thus, metadata provides a common interchange mechanism for use between tools that manipulate programs (compilers, debuggers, etc.) as well as between these tools and the Virtual Execution System. The Common Language Specification. See Partition I, section 10. The Common Language Specification is an agreement between language designers and framework (class library) designers. It specifies a subset of the Common Type System and a set of usage conventions. Languages provide their users the greatest ability to access frameworks by implementing at least those parts of the CTS that are part of the CLS. Similarly, frameworks will be most widely used if their publicly exposed aspects (classes, interfaces, methods, fields, etc.) use only types that are part of the CLS and adhere to the CLS conventions. The Virtual Execution System. See Partition I, section 12. The Virtual Execution System (VES) implements and enforces the CTS model. The VES is responsible for loading and running programs written for the CLI. It provides the services needed to execute managed code and data, using the metadata to connect separately generated modules together at runtime (late binding).
Together, these aspects of the CLI form a unifying framework for designing, developing, deploying, and executing distributed components and applications. The appropriate subset of the Common Type System is available from each programming language that targets the CLI. Language-based tools communicate with each other and with the Virtual Execution System using metadata to define and reference the types used to construct the application. The Virtual Execution System uses the metadata to create instances of the types as needed and to provide data type information to other parts of the infrastructure (such as remoting services, assembly downloading, security, etc.). ANNOTATION This Common Language Infrastructure standard describes the requirements to which languages and implementations of the Virtual Execution System (VES) must adhere to be in compliance. Although it does not, of course, prescribe implementations, it does define the outcome of the design. The CLI specifies a file format and an instruction set, and it describes how programs written with that file format, using that instruction set, are supposed to work. Implementations of the VES are responsible for making them work. The CLI defines for compilers what they must produce to work with a VES, and what they are required to consume from others. To describe the semantics of the file format, this standard also defines a compiler called the IL assembler (ilasm), although it is intended, of course, to be illustrative. |
6.1 Relationship to Type Safety Type safety is usually discussed in terms of what it does (e.g., guaranteeing encapsulation between different objects) or in terms of what it prevents (e.g., memory corruption by writing where one shouldn't). However, from the point of view of the Common Type System, type safety guarantees that: References are what they say they are Every reference is typed and the object or value referenced also has a type, and they are assignment compatible (see Partition I, section 8.7). Identities are who they say they are There is no way to corrupt or spoof an object, and by implication a user or security domain. The access to an object is through accessible functions and fields. An object may still be designed in such a way that security is compromised. However, a local analysis of the class, its methods, and the things it uses, as opposed to a global analysis of all uses of a class, is sufficient to assess the vulnerabilities. Only appropriate operations can be invoked The reference type defines the accessible functions and fields. This includes limiting visibility based on where the reference is e.g., protected fields only visible in subclasses.
The Common Type System promotes type safety; e.g., everything is typed. Type safety can be optionally enforced. The hard problem is determining if an implementation conforms to a typesafe declaration. Since the declarations are carried along as metadata with the compiled form of the program, a compiler from the Common Intermediate Language (CIL) to native code (see Partition I, section 8.8) can type-check the implementations. 6.2 Relationship to Managed Metadata-Driven Execution Metadata describes code by describing the types that the code defines and the types that it references externally. The compiler produces the metadata when the code is produced. Enough information is stored in the metadata to: Manage code execution not just load and execute, but also memory management and execution state inspection. Administer the code Installation, resolution, and other services. Reference types in the code Importing into other languages and tools as well as scripting and automation support.
The Common Type System assumes that the execution environment is metadata-driven. Using metadata allows the CLI to support: Multiple execution models The metadata also allows the execution environment to deal with a mixture of interpreted, JITted, native and legacy code and still present uniform services to tools like debuggers or profilers, consistent exception handling and unwinding, reliable code access security, and efficient memory management. Auto support for services Since the metadata is available at execution time, the execution environment and the base libraries can automatically supply support for reflection, automation, serialization, remote objects, and interoperability with existing unmanaged native code with little or no effort on the part of the programmer. Better optimization Using metadata references instead of physical offsets, layouts, and sizes allows the CLI to optimize the physical layouts of members and dispatch tables. In addition, this allows the generated code to be optimized to match the particular CPU or environment. Reduced binding brittleness Using metadata references reduces version-to-version brittleness by replacing compile-time object layout with load-time layout and binding by name. Flexible deployment resolution Since we can have metadata for both the reference and the definition of a type, more robust and flexible deployment and resolution mechanisms are possible. Resolution means that by looking in the appropriate set of places it is possible to find the implementation that best satisfies these requirements for use in this context. There are five elements of information in the foregoing: two items are made available via metadata (requirements and context); the others come from application packaging and deployment (where to look, how to find an implementation, and how to decide the best match).
6.2.1 Managed Code Managed code is simply code that provides enough information to allow the CLI to provide a set of core services, including Given an address inside the code for a method, locate the metadata describing the method Walk the stack Handle exceptions Store and retrieve security information
This standard specifies a particular instruction set, the Common Intermediate Language (CIL, see Partition III), and a file format (see Partition II, sections 21 24) for storing and transmitting managed code. 6.2.2 Managed Data Managed data is data that is allocated and released automatically by the CLI, through a process called garbage collection. 6.2.3 Summary The Common Type System is about integration between languages: using another language's objects as if they were one's own. The objective of the CLI is to make it easier to write components and applications from any language. It does this by defining a standard set of types, making all components fully self-describing, and providing a high performance common execution environment. This ensures that all CLI-compliant system services and components will be accessible to all CLI-aware languages and tools. In addition, this simplifies deployment of components and applications that use them, all in a way that allows compilers and other tools to leverage the high performance execution environment. The Common Type System covers, at a high level, the concepts and interactions that make all of this possible. The discussion is broken down into four areas: Type System What types are and how to define them. Metadata How types are described and how those descriptions are stored. Common Language Specification Restrictions required for language interoperability. Virtual Execution System How code is executed and types are instantiated, interact, and die.
ANNOTATION The discussion of the Common Type System starts in section 8, rather than in section 7, which follows. Section 7 introduces the Common Language Specification, which is the set of restrictions on the CTS that ensure interoperability among languages. |
|
