| Libraries and Profiles, defined below, are constructs created for the purpose of standards conformance/compliance. They specify a set of features that shall be present in an implementation of the Common Language Infrastructure (CLI) and a set of types that shall be available to programs run by that CLI. NOTE There need not be any direct support for Libraries and Profiles in the Virtual Execution System (VES). They are not represented in the metadata, and they have no impact on the structure or performance of an implementation of the CLI. Libraries and Profiles may span assemblies (the deployment unit), and the names of types in a single Library or Profile are not required to have a common prefix ("namespace").
There is, in general, no way to test whether a feature is available at runtime, nor is there a way to enquire whether a particular Profile or Library is available. If present, however, the Reflection Library makes it possible to test at runtime for the existence of particular methods and types. 2.1 Libraries A Library specifies three things: A set of types that shall be available, including their grouping into assemblies. A set of features of the CLI that shall be available. NOTE The set of features required for any particular Library is a subset of the complete set of CLI features. Each Library described in Partition IV, section 5 has text that defines what CLI features are required for implementations that support the Library.
Modifications to types defined in other Libraries. These modifications are typically the addition of methods and interfaces to types belonging to the other Library, and additional exceptions that may be thrown by methods of the other Library's types. These modifications shall provide only additional functionality or specify behavior where it was previously unspecified; they shall not be used to alter previously specified behavior. Example (informative): Consider the Extended Numerics Library. Since it provides a new  base data type, Double, it also specifies that the method ToDouble be added to the System .Convert class that is part of the Base Class Library. It also defines a new exception, System.NotFiniteNumberException, and specifies existing methods in other Libraries' methods that throw it (as it happens, there are no such methods).
In the XML specification of the Libraries, each type specifies the Library to which it belongs. For those members (e.g., Console.WriteLine(float)) that are part of one Library (Extended Numerics) but whose type is in another Library (BCL [Base Class Library]), the XML specifies the Library that defines the method. [The class libraries are also published in this series as the .NET Framework Standard Library Annotated Reference.] ANNOTATION Partition I of the standard describes framework developers as one of the audiences of this standard. The term "framework" was used to denote what is traditionally thought of as a library that is a set of data types and the operations upon them. In this section, "library" is more broadly defined. In terms of the CLI, a library definition has three parts: (1) the data types and operations that the programmer sees, (2) the impact of that library on other libraries, and (3) additions to the VES required to support that library. For example, if you add a library like the Extended Numerics Library, which adds the floating point data type, new data converters for that type must be added to the Base Class Library, along with new exceptions for those operations. In addition, floating point instructions must be added to the VES. If you are implementing a VES, you need only implement the parts of the VES that support the libraries you choose to support. A conforming implementation of the CLI must support the CLI, which requires a minimum set of libraries, as shown in the diagram in Partition IV, section 2.3. If you add a library, all you add is functionality in the VES, not user programming libraries. Often what programmers see is not changes to the libraries, but syntax changes that their programming languages provide. For example, if support for multi-dimensional arrays is added, and the languages support it as well, programmers see that the languages allow commas in the brackets for array indexing. If languages do not have the syntax for something, programmers cannot use that thing. However, putting functionality into CLS-compliant frameworks with new classes makes this functionality visible in all programming languages, without requiring languages to add syntax for each addition of new functionality. Certainly, calling base classes from the library is less convenient than if there were supporting language syntax, but it is possible. For a VES developer, deciding to add support for a new library requires several kinds of tasks. For example, if you built a VES that originally supported only the kernel, and then add extended numerics, you would need to add a data type to the verifier, add a set of new rules to the verifier, add a set of instructions to the VES, make sure that all the marshal conventions on the native code side can handle passing floating point numbers, learn how the underlying platform handles floating point numbers, etc. For a compiler writer with a CLI-compliant language, there is no new work in supporting the framework part of the library, because the library is CLS-compliant. But some libraries have a component that requires a new instruction. In this case there are two possibilities. One is that the instruction will be needed for a library that the VES developers are responsible for building. On the other hand, sometimes the language must either add new syntax or modify old syntax to support it. One example is type conversions in C#. If you are adding floating point capability, you must now be able to convert from an integer to a float, and the language will need new syntax not previously required. |
2.2 Profiles A Profile is simply a set of Libraries, grouped together to form a consistent whole that provides a fixed level of functionality. A conforming implementation of the CLI shall specify a Profile it implements, as well as any additional Libraries that it provides. The Kernel Profile (see Partition IV, section 3.1) shall be included in all conforming implementations of the CLI. Thus, all Libraries and CLI features that are part of the Kernel Profile are available in all conforming implementations. This minimal feature set is described in Partition IV, section 4. RATIONALE The rules for combining Libraries together are complex, since each Library may add members to types defined in other libraries. By standardizing a small number of Profiles, we specify completely the interaction of the Libraries that are part of each Profile. A Profile provides a consistent target for vendors of devices, compilers, tools, and applications. Each Profile specifies a trade-off of CLI feature and implementation complexity against resource constraints. By defining a very small number of Profiles, we increase the market for each Profile, making each a desirable target for a class of applications across a wide range of implementations and tool sets.
2.3 Structure of the Standard This standard specifies two Standard Profiles (see Partition IV, section 3) and seven Standard Libraries (see Partition IV, section 5). The following diagram shows the relationship between the Libraries and the Profiles: 
The Extended Array Library and the Extended Numerics Library are not part of either Profile, but may be combined with either of them. Doing so adds the appropriate methods, exceptions, and interfaces to the types specified in the Profile. ANNOTATION The diagram above provides an excellent road map for VES developers, showing the libraries required for a basic VES, and what can be added later in development. A minimal conforming implementation of the CLI includes both Libraries (Base Class and Runtime Infrastructure) in the Kernel Profile. |
|
