Microsoft's .NET is a broad family of products representing the company's next generation of services, software, and development tools. At the core of the .NET strategy lives the Common Language Runtime. The CLR is a platform for software development that provides services by consuming metadata. It is standards-based and component-oriented. Like any platform, the important pieces are the runtime, the libraries that provide access to them, and the languages that can target the platform.
But what exactly is .NET? Although the precise meaning can be a little hard to isolate by reading the prolific marketing literature, a little digging reveals that .NET is in fact Microsoft's grand strategy for how all of their software, systems, and services will fit together. It includes development tools (like the new version of Visual Studio, dubbed Visual Studio.NET), future versions of their Windows operating systems, new Internet-based services (like a stepped-up version of their Passport web authentication service), and an entirely new beast called the Common Language Runtime.
The Common Language Runtime is the single most important piece of the .NET product strategy, because it is in essence the engine that pulls the train - the CLR is how developers will write software in the brave new .NET world (see figure 1).
The CLR as a development platform
The CLR is a development platform. Like any platform, it provides a runtime, defines functionality in some libraries, and supports a set of programming languages.
The CLR is a platform for developing applications. A platform is a set of programmatic services, exposed through some API to developers using one or more languages. Development generally targets a single platform;
The CLR is not an operating system in the strict sense of the term - it does not, for example, provide a file system, relying instead on the underlying OS (such as Windows) to implement that feature.
break down the feature set of the platform (CLR) into three fundamental areas: the runtime that the platform offers, the libraries it defines, and the languages I'm going to use. These aspects of the platform overlap (see figure 2), and understanding each of them and the ways in which they interact is crucial to becoming an effective CLR programmer.
Runtime
A runtime provides services to software that you write. The CLR provides a runtime.
A runtime is a piece of code, written by the platform vendor, which provides your code with a set of services. What sorts of services? Well, it depends on the platform - it might be anything from checking security for you to implementing a file system to providing access to some piece of hardware.
Almost every program written these days takes advantage of some sort of runtime. Very few programmers start a project by writing their own file system or database engine. Rather, they make use of already-written pieces of software, like Windows 2000 or Oracle. Both of these platforms (yep, they're both platforms) have a runtime that provides services. In the case of Windows 2000, the runtime is the operating system kernel, and it provides services like thread management. In the case of Oracle, the runtime is the database engine, and the services include things like a SQL engine and transactions. We say that we write code that "runs on" a platform because it uses the services provided by the platform. The CLR provides these services using a layered architecture that is shown in figure 3.
Libraries
The CLR's Base Class Library allow us to interact with the runtime, and provide additional useful functionality.
Languages
The CLR supports programming in one of about two dozen languages. The most popular of these are likely to be C# and Visual Basic.NET.
In two areas, the CLR really shines: its support for component-based programming, and its extensive use of open, standards-based technologies.
Components
The CLR has extensive support for component-based programming.
A fairly recent trend in software development is that of component-oriented programming, although the idea behind component development is not a new one. In fact, it's not even unique to software engineering: we stole it from the hardware guys. The basic concept is that systems are built out of discrete parts that can be assembled to make a larger whole.
A software component is a discrete piece of functionality that can be plugged into different applications. For example, I might develop a calendar component that allows the user to pick a day of the month.
Of course, components do not have to be visual - a reusable piece of logic for calculating sales tax could also be written as a component. The imp