When we were all developing programs in MS-DOS, you could look at a Windows 3.1 screen and see that this was how computing was supposed to be: lots of color, beautiful fonts, and a high-resolution windowing system that took care of most of the nasty stuff that made MS-DOS development hard. Because the differences are more architectural than visual, it's a little more difficult to see the advantages of .NET, but for developers, most of the features of .NET are at least as compelling as those of Windows compared to MS-DOS.
One purpose of the .NET Framework is to simplify application development and deployment in the distributed Internet environment. This extends to applications that are run locally or remotely or that are distributed over the Internet. This simplification is achieved through a common language runtime (CLR) that provides a managed execution environment available to any language that targets the runtime. The functionality this execution environment provides is made available to these languages through the .NET Framework class library. Figure 1-1 illustrates how the CLR relates to the .NET Framework.
The Common Language Specification (CLS) defines what a .NET-compliant language must provide to the system. The common type system (CTS) ensures that any types created by a language conforming to the CLS can be consumed by any other CLS-compliant language.
Languages that target the CLR are compiled to Microsoft Intermediate Language (MSIL). These applications are compiled as PE (portable executable) files and DLLs, so to users they look just like any Windows-based applications. The MSIL code in these files is then JIT-compiled to machine instructions locally at run time. All of this means that any CLS-compliant language that targets the CLR will look like any other language to the runtime and can act and be treated as a first-class citizen. For example, a Visual Basic .NET program will have the same base functionality as a Visual C# program or even a managed C++ program.
Tip
For a detailed look at the architecture of .NET, take a look at Applied Microsoft .NET Framework Programming by Jeffrey Richter (Microsoft Press, 2002).
The managed CLR environment provides some other significant advantages. It's designed to help eliminate versioning conflictsthe infamous DLL Hell. It's designed to provide an environment that ensures that code is executed safely. And finally, it's designed with an API that is targetable from both Windows-based and Web-based applications.
You don't need to think about the .NET Framework as a monolithic virtual machine that requires constant care and feeding. The .NET Framework provides an environment that can be hosted by unmanaged components. The unmanaged components (such as Internet Explorer and the ASP.NET runtime) load the CLR and execute the managed code. The managed CLR provides garbage-collection services and security on a number of levels.
For corporate developers, this runtime solves a huge problem. In many shops, the Visual Basic programmers, the C/C++ programmers, and the COBOL programmers are all segregated. They meet to figure out how to functionally interoperate, but in a number of ways they work as individual teams inside the same space. In a shop that targets the CLR, development becomes a little more manageable. The same .NET Framework class library is available across languages. The CTS in the class library ensures that components can be easily shared between .NET languages, as shown in Figure 1-2. These components can even be exposed as XML Web services.
The CLR provides a target that's available from most of the major programming languages used today. Visual Studio .NET has support for Visual C++, Visual Basic .NET, Visual J# .NET, and Visual C# out of the box. You can add support for a growing number of languages that are available from third-party software vendors, including COBOL, Eiffel, Python, and Perl.