Introducing the Building Blocks of the .NET Platform (the CLR, CTS, and CLS)

Now that you know some of the benefits provided by .NET, let’s preview three key (and interrelated)
entities that make it all possible: the CLR, CTS, and CLS. From a programmer’s point of view, .NET can
be understood as a runtime environment and a comprehensive base class library. The runtime layer is
properly referred to as the Common Language Runtime, or CLR. The primary role of the CLR is to locate,
load, and manage .NET types on your behalf. The CLR also takes care of a number of low-level details
such as memory management, application hosting, handling threads, and performing various security
checks.
Another building block of the .NET platform is the Common Type System, or CTS. The CTS
specification fully describes all possible data types and programming constructs supported by the
runtime, specifies how these entities can interact with each other, and details how they are represented
in the .NET metadata format (more information on metadata later in this chapter; see Chapter 15 for
complete details).
Understand that a given .NET-aware language might not support each and every feature defined by
the CTS. The Common Language Specification, or CLS, is a related specification that defines a subset of
common types and programming constructs that all .NET programming languages can agree on. Thus, if
you build .NET types that only expose CLS-compliant features, you can rest assured that all .NET-awarelanguages can consume them. Conversely, if you make use of a data type or programming construct that
is outside of the bounds of the CLS, you cannot guarantee that every .NET programming language can
interact with your .NET code library. Thankfully, as you will see later in this chapter, it is very simple to
tell your C# compiler to check all of your code for CLS compliance.