You’ve already met the Common Language Runtime (CLR) because this is the part of .NET that manages your code as it runs, providing services such as garbage collection. The CLR is a run-time execution engine that is responsible for executing code within the .NET environment, providing services such as security, memory management, and remoting (communication between objects in different domains, processes, or computers). Code that is run by the CLR is known as managed code; code that executes outside the control of the CLR is unmanaged code. All Microsoft Visual Basic and C# code is managed, but it’s possible to write both managed and unmanaged code in Microsoft Visual C++ and to have both types of code working together in the same application.

All .NET languages compile down into an intermediate form called Microsoft Intermediate Language (MSIL, or just IL.)

IL is similar to Java bytecode in that it’s an intermediate form of code produced by the compiler that can’t be directly executed on a target system. IL code is also portable and is always converted into native code before it’s executed, which is done by a Just-In-Time (JIT) compiler. This conversion might happen on demand, function-by-function as an application executes, or all at once when an application is installed.

One of the great innovations of IL is that it isn’t simply a low-level, machine-independent object code. In fact, support for object-oriented functionality—such as the ideas of classes, encapsulation and data-hiding, polymorphism, and inheritance—is built into IL, so you can view it as a type of object-oriented assembler language. This functionality makes it far more powerful than Java bytecode, and it makes it possible for you to perform cross-language object-oriented programming, easily calling members in C++/CLI classes from Visual Basic, and vice-versa, and even inheriting from a C++/CLI class in Visual Basic.

The Common Type System (CTS) provides a specification for how types are defined, managed, and used, which is an important part of the .NET cross-language integration. The CTS provides a set of rules that languages must obey, which helps to ensure that types created in different languages can interoperate with one another.

The Common Language Specification (CLS) is a set of rules and constraints that compiler and library writers need to follow to ensure that the languages and code they produce will interoperate with other .NET languages. The CLS forms a subset of the CTS, and if a language or a library is CLS-compliant, it will completely interoperate with other CLS-compliant languages.

You’ll see in the online documentation that some .NET member functions are marked as not CLS-compliant, which means that they might not be accessible from some .NET languages. For example, functions that use unsigned integers are not CLS-compliant because unsigned integers aren’t supported by Visual Basic. As a result, unsigned integers are not included in the types specified by the CLS.

The .NET Framework class library is an object-oriented library of classes that provides all the tools you need to write a wide variety of applications.

Since Windows was first released, programmers have written Windows applications using the Windows API (application programming interface). This API gives you a large number of C functions—several thousand, in fact—that you can call from your applications to interact with Windows. However, there are two main problems with the Windows API: first, it isn’t object-oriented, and second, it’s a C library, so it can’t easily be used from every language.

One of the benefits of object-oriented programming is the help that it gives in structuring and managing large-scale projects. The Windows API has grown to several thousand functions, and it becomes harder and harder to manage such a large collection of unstructured routines. In addition to its other benefits (such as encapsulation and polymorphism), object-oriented programming lets you impose a structure on code. So, for example, a Dialog class can contain all the functions relating to dialog boxes. This ability makes it much easier to use a library the size of the Windows API.

The second problem with the Windows API is that it’s basically written for C programmers, so it uses many features that are unique to C, such as pointers and null-terminated strings, which makes it hard—and sometimes impossible—to use some functionality from languages other than C or C++. You also tend to need a lot of ugly “plumbing” to interface between languages such as Visual Basic and the API.

The .NET Framework class library provides a set of classes that can be used from any .NET language because it works at the IL level. All .NET languages compile down to the same intermediate code, and because they all use references and agree on the basic set of value types, they can all use the classes defined in the class library. This is a huge advantage and provides language interoperability on a scale never seen before.

Assemblies are the basic building blocks with which .NET applications are constructed, and they’re the fundamental unit of deployment and versioning. Assemblies contain IL code, metadata that describes the assembly and its contents, and any other files needed for run-time operation. An assembly is therefore much more self-contained than a standard Windows executable or Component Object Model (COM) object because there is no reliance on external sources of information such as the Windows Registry. Every .NET type is part of an assembly, and no .NET type can exist outside an assembly.

There are several aspects by which assemblies are fundamental to the .NET world:

.NET classes are self-describing, which means that they carry descriptive information with them in the .exe or .dll file. This information, called metadata, includes the following:

Most of the metadata is standard and is created by the compiler when it produces the IL code, but you can use attributes to add extra metadata information.

The following exercise shows you how to modify the standard metadata produced by the compiler.

C++/CLI applications employ the #using preprocessor directive to import metadata into applications. Remember that metadata is information that describes the types in an assembly, and it includes the fully qualified names of all the types. For example, if the compiler sees a line such as

#using <mscorlib.dll>

it loads the .dll file and reads the metadata for all the types that are defined there. Because mscorlib.dll contains most of the core .NET Framework classes, it imports the metadata for a very large number of types.

The #using keyword means that you have to know which .dll file holds the class or classes that you want to use. Your typical source for this information is the online help.

Some of the fully qualified names can get rather long. Thus, it’s common to use a traditional using directive to specify namespace names so that you can use unqualified names, as shown here:

// Read the metadata for MSCORLIB
#using <mscorlib.dll>

// Import all the names
using namespace System::Collections::Generic;

// Now you can use List without having to qualify it
List<int> ^pal = gcnew List<int>();

The System namespace, defined in mscorlib.dll, contains a lot of fundamental classes, including the following:

You’ve already seen a lot of types from System in earlier chapters, and some of the other classes are rather obscure, so I won’t go through them in detail. There are a few points that are worth mentioning about some of the classes in System; these are covered in the following sections.

double top = 1.0;
double bottom = 0.0;

double result = top/bottom;

if (result == Double::PositiveInfinity)
    Console::WriteLine("+infinity");
else if (result == Double::NegativeInfinity)
    Console::WriteLine("-infinity");
else if (result == Double::NaN)
    Console::WriteLine("Not a number");

Chapter 12, looks at the Collections namespaces, in particular System::Collections::Generic. System::Collections::Generic is implemented in mscorlib.dll, so to use it, you’ll have to include a #using statement, as demonstrated here:

#using <mscorlib.dll>

The following table lists the main classes that you’ll find in the System::Collections::Generic namespace.

The System::Collections::Generic namespace also defines a series of interfaces that are used to define the behavior of the collection classes. The collection classes themselves implement one or more of these interfaces, and you can use them as the basis for writing your own collection classes. The main interfaces are listed in the following table.

The System::Diagnostics namespace provides a number of classes with which you can do the following:

All the classes in System::Diagnostics are implemented in system.dll.

The System::IO namespace, defined in mscorlib.dll, provides the classes that implement the .NET input/output (I/O) functionality. The main classes in this namespace are described in the following table.

As with all the .NET Framework class library classes, these classes are language-independent. They can be used alongside or in place of the C++ stream classes. Chapter 19, delves deeper into some of the System::IO classes. The System::IO classes are in mscorlib.dll.

The System::Windows prefix identifies 50 namespaces that together provide the functionality of Windows Presentation Foundation (WPF), an advanced user interface (UI) framework for .NET introduced in version 3.0. WPF provides all the tools you need to create modern UIs, including support for forms-based applications, 2D and 3D graphics, typography and printing, run-time animation, and comprehensive support for playing media.

One key feature of WPF is its use of XAML, an XML markup language, to define user interfaces. This makes it possible to separate the UI from the code, which allows teams to use design tools such as Microsoft Expression Blend in addition to coding tools such as Microsoft Visual Studio.

Networking support is provided by a number of namespaces in the System::Net family. System::Net itself provides an interface to many of the protocols commonly used today, such as manipulating IP addresses, making DNS lookups, talking to HTTP and FTP servers, managing cookies, and authentication.

System::Net::Sockets provides an implementation of the Berkeley Sockets protocol and provides a .NET wrapper around the Windows WinSock API, whereas System::Net::WebSockets provides a managed implementation of the WebSocket interface.

The System::ServiceModel namespaces (over 30 of them) together implement Windows Communication Foundation (WCF), a technology introduced in .NET 3.0 for creating distributed, service-oriented applications.

With WCF, you can build applications out of components hosted in other processes, and even on other computers. This has long been possible, but the technologies used were very different, depending on where your components were located (same process, different process on the same computer, or different process on another computer) and the communication mechanism you wanted to use (TCP/IP, HTTP, messaging).

WCF provides an integrated framework for creating, deploying, and managing distributed components and their clients. Chapter 19 shows you how to write a web service by using WCF.

XML is heavily used throughout the .NET Framework, and several namespaces provide support for creating and manipulating XML, including the following:

Using these classes, it’s possible to perform all the manipulation of XML that you’ll ever need to do. These classes make the .NET Framework one of the most productive environments for XML programming. You can find the XML classes in System.Xml.dll, with the LINQ classes in System.Xml.Linq.dll.

The System::Data namespaces hold the classes that implement ADO.NET, a framework with which you can build components to manage data from a number of data sources. Data from different data sources is provided by data providers, five of which are shipped with the .NET Framework.

The most important class in the System::Data namespace itself is DataSet, which represents an in-memory cache of data retrieved from a data source. A DataSet consists of one or more DataTable objects, and these in turn consist of a collection of DataColumn and DataRow objects. You can use DataSets to work in disconnected mode. This means retrieve data from a database into a DataSet, disconnect from the database server and work with the data locally, and then update the database from the DataSet later.

Because one of the main reasons for introducing the .NET Framework was to make it easier to build web applications, it’s perhaps no surprise that the .NET Framework contains a number of namespaces related to web programming. These are all related to Microsoft ASP.NET, the latest version of Microsoft Active Server Pages technology that is optimized to work in the .NET environment.

The most significant of the Web namespaces are listed here:

The features provided by two of these namespaces merit particular mention. A web service is a programmable entity living on a web server that can be accessed by using standard Internet protocols. What this means in practice is that you can expose a function on a web server that others can call. Communication between client and server uses standard protocols such as HTTP, and data is usually passed to and from the web service in XML format by using Simple Object Access Protocol (SOAP). The use of XML over HTTP makes it possible to access web services easily from clients written in just about any programming language on any platform. It’s also possible to find out what services a web server supports, and it’s very easy in Visual Studio 2012 to write clients that make use of web services.

With the System::Web::UI namespaces, you can build server-side controls. You program these as if they were normal controls, but their code executes on the server. The System::Web::UI::HtmlControls namespace contains classes that represent HTML server controls that map directly to standard HTML elements such as buttons and forms. System::Web::UI::WebControls is more abstract, and you can use it to program server-side controls that might not map directly to HTML.