The .NET Framework is Microsoft's latest environment for running program code. The concept of managed code, running under control of an execution engine, has quickly permeated all major operating systems, including those from Microsoft. The .NET Framework is one of the core technologies in Windows 2003 Server, Microsoft's latest collection of server platforms. Handheld devices and computer-based mobile phones have quickly acquired .NET Framework-based development environments. The .NET Framework is an integral part of both Internet Information Server (IIS) and Internet Explorer (IE). ASP.NET runs on the Windows 2000 version and up of IIS 5.0. Internet Explorer 5.5, and can load and run .NET Framework code referenced by <object> tags embedded in Web pages. Rich .NET Frameworkbased Windows applications, based on the WinForms library that comes with the .NET Framework, may be deployed directly from the Internet and run on Windows-based desktops. So what is it about the .NET Framework that has caused it to catch on?
Managed code has made the .NET Framework so compelling. Development tools produce managed code using .NET Framework classes. Managed code is so named because it runs in an environment produced by mscoree.dll, the Microsoft common object runtime execution engine, which manages all facets of code execution. These include memory allocation and disposal, and class loading, which in traditional execution environments are major sources of programming errors. The .NET Framework also manages error recovery, and because it has complete information about the runtime environment, it need not always terminate an entire application in the face of an error such as an out-of-memory condition, but can instead terminate just a part of an application without affecting the rest of it.
.NET Framework code makes use of code access security that applies a security policy based on the principal running the code, the code itself, and the location from which the code was loaded. The policy determines the permissions the code has. In the .NET Framework, by default, code that is loaded from the machine on which it runs is given full access to the machine. Code loaded from anywhere else, even if run by an administrator, is run in a sandbox that can access almost nothing on the machine. Prior to the .NET Framework, code run by an administrator would generally be given access to the entire machine regardless of its source. The application of policies is controlled by a system administrator and can be very fine grained.
Multiple versions of the .NET Framework, based on different versions of user-written classes or different versions of the .NET base class libraries (BCL), can execute side by side on the same machine. This makes versioning and deployment of revised and fixed classes easier. The .NET Framework kernel or execution engine and the BCL can be written to work with different hardware. A common .NET Framework programming model is usable in x86-based 32-bit processors, like those that currently run versions of Windows 9x, Windows NT, Windows 2000, and Windows XP, as well as mobile computers like the iPaq running on radically different processors. The development libraries are independent of chipset. Because .NET Framework classes can be Just-in-Time compiled (JIT compiled), optimization based on processor type can be deferred until runtime. This allows the .NET Framework to integrate more easily with the new versions of 64-bit processors.
.NET Framework tools compile code into an intermediate language (IL) that is the same regardless of the programming language used to author the program. Microsoft provides C#; Visual Basic .NET; Managed C++; JavaScript; and J#, a variant of the Java language that emits IL. Non-Microsoft languages such as COBOL.NET and Eiffel.NET are also first-class citizens. Code written in different languages can interoperate completely if written to the Common Language Specification (CLS). Even though language features might be radically differentas in Managed C++, where managed and unmanaged code can be mixed in the same programthe feature sets are similar enough that an organization can choose the language that makes the most sense without losing features. In addition, .NET Framework code can interoperate with existing COM (Component Object Model) code (via COM-callable wrappers and runtime-callable wrappers) and arbitrary Windows Dynamic Link Libraries (DLLs) through a mechanism known as Platform Invoke (PInvoke).