One of the key features of any language or run-time environment is its support for types. A language that makes available a limited number of types or that limits the programmer's ability to extend the language's built-in types isn't a language with a long life expectancy. However, having a unified type system has many other benefits as well.
The CTS plays an integral role in allowing language interoperability because it defines the set types that a .NET compiler must support in order to interoperate with other languages. The CTS itself is defined in the Common Language Specification (CLS). The CLS defines a single set of rules for every .NET compiler, ensuring that each compiler will output code that interacts with the CLR consistently. One of the CLS requirements is that the compiler must support certain types defined in the CTS. The benefit being that because all .NET languages are using a single type system, you are assured that objects and types created in different languages can interact with one another in a seamless manner. It's this CTS/CLS combination that helps make language interoperability more than just a programmer's dream.
Singly Rooted Object Hierarchy
As I mentioned earlier, an important CTS characteristic is the singly rooted object hierarchy. In the .NET Framework, every type in the system derives from the System.Object base class. An important diversion from the C++ language, in which there is no implied base class for all classes, this single base class approach is endorsed by OOP theorists and is implemented in most mainstream object-oriented language. The benefits to a singly rooted hierarchy aren't immediately apparent, but over time you'll come to question how languages were designed before this type of hierarchy was adopted.
A singly rooted object hierarchy is the key to a unified type system because it guarantees that each object in the hierarchy has a common interface and therefore everything in the hierarchy will ultimately be of the same base type. One of the main drawbacks of C++ is its lack of support for such a hierarchy. Let's consider a simple example to see what I mean.
Say you've built up an object hierarchy in C++ based on a base class of your own making. We'll call this base class CFoo. Now say you want to integrate with another object hierarchy whose objects all derive from a base class called CBar. In this example, the object hierarchies have incompatible interfaces and it's going to require a lot of effort to integrate these two hierarchies. You might have to use some sort of wrapper class with aggregation or use multiple inheritance to make this work. With a singly rooted hierarchy, compatibility is not an issue because each object has the same interface (inherited from System.Object). As a result, you know that each and every object in your hierarchy-and, crucially, in the hierarchies of third-party .NET code-has a certain minimal set of functionality.