Between the Microsoft .NET Framework and Microsoft Visual Studio .NET (the tool that helps developers build .NET applications), developers have never had so much exciting power at their fingertips. But with this exciting developer technology comes the daunting task of providing a solid, secure platform on which to deploy these new applications. Before you can build and administer such a platform, you must understand the key features of the .NET Framework—the Common Language Runtime (CLR) and the .NET Framework class library—and the implications of installing the .NET Framework in your production environment.
What's the .NET Framework?
The Microsoft marketing machine spent more than 2 years trying to explain to the technology masses just what .NET is. I've found that the objectives the .NET Framework attempts to accomplish best describe it. As the .NET Framework software development kit (SDK) documentation states, the .NET Framework is designed to fulfill these objectives:
- Provide a consistent, object-oriented programming environment whether object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely.
- Provide a code-execution environment that minimizes software deployment and versioning conflicts.
- Provide a code-execution environment that guarantees safe execution of code, including code created by an unknown or semitrusted third party.
- Provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments.
- Make the developer experience consistent across widely varying types of applications, such as Windows-based applications and Web-based applications.
- Build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code.
The .NET Framework has two main components: the CLR and the .NET Framework class library.
The CLR, which is the foundation of the .NET Framework, is a negotiator that manages code at execution time. The CLR provides core services, such as
- memory management—The CLR's garbage collector automatically manages the allocation and release of memory for an application. This management is a big win for IIS administrators who have suffered Web server crashes and subsequent memory leaks because of developer mistakes.
- thread management—Threads are the basic unit to which the OS allocates CPU time. The OS uses processes to separate the different applications that it executes, and more than one thread can be executing code within those processes.
- remoting—Remoting enables different applications to communicate with one another.
- enforcement of strict type safety—Type-safe code is code that accesses types (e.g., memory) in well-defined, structural ways and has strict rules that help prevent mistakes.
The concept of code management is a fundamental principle of the CLR, and applications that the CLR manages are called managed applications. Applications such as Active Server Pages (ASP) applications that aren't targeted to the CLR (i.e., aren't written on the .NET Framework) are called unmanaged applications. Managed applications benefit from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.
When you compile a managed application, a .NET language compiler translates your source code into Microsoft intermediate language (MSIL) code. You can write the source code in any .NET-compliant language—that is, a language for which a .NET language compiler exists. Currently, compilers exist for the languages of Visual Basic .NET, JScript .NET, C#, and managed C++.
MSIL code is a CPU-independent set of instructions. Before the MSIL code can execute, the CLR must convert it to CPU-specific code, usually with a just-in-time (JIT) compiler. JIT compilation takes into account that the runtime engine might never call some code during execution. Therefore, rather than using processing time and memory to convert all the MSIL code to native (i.e., CPU-specific) code at one time, the JIT compiler converts the MSIL code on an as-needed basis during execution. The compiler stores the resulting native code so that it's accessible for subsequent calls. Because the CLR supplies JIT compilers for each computer architecture that the CLR supports, the same MSIL code can be JIT-compiled and executed on any supported architecture.
The .NET Framework Class Library
The class library, the second main component of the .NET Framework, is a comprehensive, object-oriented collection of reusable data types that developers use to write .NET applications. You can parallel the class library to the Win32 API set, which historically developers have used to leverage resources such as OS functionality. The .NET Framework includes classes, interfaces, and value types that optimize the software-development process by making it easier to build powerful software. The class library, like the Win32 API set, provides access to system functionality such as editing the IIS metabase and stopping the Web server.
The .NET Framework types are the foundation on which developers build .NET applications, components, and controls. The .NET Framework types use a hierarchical dot naming scheme. This scheme groups related types into namespaces so that developers can more easily search and reference them. The first part of the full name (i.e., up to the rightmost dot) is the namespace name. The last part of the name is the type name. For example,
shows the SessionState type, which belongs to the System.Web namespace. Developers can use the types in System.Web to manipulate collections of objects. The System.Web namespace provides support for Web server and client management, communication, and design. It also provides core infrastructure for ASP.NET, including Web Forms support. Hundreds, if not thousands, of namespaces are available to .NET application developers.
The System namespace is the root namespace for fundamental data types in the .NET Framework. This namespace includes classes that represent the base data types that all applications use: Object (the root of the inheritance hierarchy), Byte, Char, Array, Int32, String, and so on. Many of these types correspond to the primitive data types (e.g., Boolean types, decimal types) that a .NET programming language uses. For example, in Visual Basic .NET, you use the code
DIM testString as String
to declare a variable as a String primitive data type.
Now you have a good understanding of the .NET Framework and the components it encompasses. Let's take a look at installing the .NET Framework and the resulting implications.
The .NET Framework has both client and server installation requirements.
Client-side installation requirements. On the client side, you can install the .NET Framework on Windows XP Home Edition, Windows NT Workstation 4.0 , and Windows 98. The .NET Framework requires a 90MHz Pentium processor or the minimum speed that the OS requires, whichever is greater. The .NET Framework also requires 32MB of RAM, but Microsoft recommends 96MB of RAM.
Server-side installation requirements. On the server side, the .NET Framework requires one of these OSs:
- Windows 2000 Server, Win2K Advanced Server, Win2K Professional, or Win2K Datacenter Server—all with Service Pack 2 (SP2)
- Windows XP Professional Edition
Microsoft will include the .NET Framework with the entire Windows .NET server family, which is due to ship in late 2002. The .NET Framework requires a 133MHz Pentium processor or the minimum speed that the server OS requires, whichever is greater. The .NET Framework also requires 128MB of RAM, but Microsoft recommends 256MB of RAM.
Server-side .NET Framework installation has a few additional requirements. First, to use the Microsoft SQL Server .NET data provider (and your developers most likely will use it), you must install Microsoft Data Access Components (MDAC) 2.7. I mention MDAC because your developers might encounter problems with legacy ASP applications when running in side-by-side mode. (Side-by-side mode isn't a true mode; rather, it's a technique for implementing both old- and new-style code simultaneously. For example, ASP and ASP.NET are both Internet Server API—ISAPI—filters, so they can run on the same IIS machine.) Although MDAC installations often strike fear in the hearts of IIS administrators, MDAC 2.7 installation is painless because it's simply an installation of ADO.NET, which has full XML support. Second, ASP.NET requires IIS 5.0 or later. So, ASP.NET won't run on NT 4.0 servers.
Installing the .NET Framework
Installing the .NET Framework on a server is no small chore, and the implications of putting that much code into the OS are spectacular. (For information about acquiring the .NET Framework, see the sidebar "Obtaining the .NET Framework.") Microsoft has a bootstrapper sample application that shows developers how to embed the .NET Framework into their .NET applications' setup code so that the .NET Framework installs automatically when their Web application installs. But can you imagine a software developer trying to convince you to let him or her install an application that includes tens, maybe hundreds, of megabytes of .NET Framework and Windows Component Update files necessary to install the .NET Framework?
The .NET Framework is included in the installation of the Windows Component Update. The Windows Component Update contains all the components that the .NET Framework installs and upgrades on an OS. Installation is a simple process requiring little or no decision-making, but it can take a long time on an inferior machine and will require a server reboot. Consider this requirement when you deploy the .NET Framework on your production servers.
Having a good understanding of the .NET Framework before you even consider installing it into your production environment is imperative. You now know how to obtain the .NET Framework and what's required to install it. You should also have a good understanding of the .NET Framework's CLR and class library.
Next month, I'll continue this three-part series about integrating IIS and ASP.NET. In particular, I'll introduce you to ASP.NET's web.config file—the .NET equivalent of ASP's global.asa file.