The .NET Framework Class Library

I l @ ve RuBoard

The .NET Framework incorporates a comprehensive library of classes and other types that are essential for building applications. This library provides access to the underlying operating system and adds a level of abstraction that allows you to write portable code that can run on any machine that has the common language runtime installed.

In developing the .NET Framework Class Library, Microsoft paid particular attention to the fact that the routines and objects contained in it had to be usable by a wide (and indeterminate) range of programming languages. Therefore, as much functionality as possible had to be made available using only CLS-compliant types and methods . Microsoft also met the following goals:

• The library has functionality at least equivalent to that of the ISO C standard library. This is the library that many C and C++ programmers are familiar with, and it is widely acknowledged as the benchmark for portable libraries designed to remove dependencies on the operating system.

• The structure of the library is consistent, allowing it to be factored into smaller, self-contained units with as few interdependencies as possible. The rationale behind this is twofold: First, the library can be split into mandatory and optional components for porting to mobile environments in which resources are at a premium. Second, the library can be implemented as a series of relatively independent assemblies. This reduces the runtime overhead of applications using it, because applications load only the assemblies containing the needed routines rather than the entire library.

• The library supports modern programming paradigms that go beyond those of the ISO C standard. Examples include support for a consistent model for events, delegates (callbacks), and consistent properties across all languages.

• The library provides consistent APIs for networking, processing XML, handling runtime type information, dynamic object creation, and dynamic method dispatching. These last three items give applications a high level of flexibility, postponing many decisions about object creation and method invocation until run time, which is useful when interoperating with COM.

The .NET Framework Class Library also includes additional utility objects and methods, including implementations of useful collection classes, classes for building Windows GUI applications (called Windows Forms), classes for interacting with the graphics subsystems, and many others. These features are optional and might be partially present or not present at all in any given implementation of the .NET Framework. The .NET Compact Framework, which is aimed at mobile and other devices, contains a stripped-down version of the library, for example.

Namespaces

The .NET Framework Class Library is split into namespaces. A namespace is a logical partitioning of the library. The namespace scheme used in the library is hierarchical and can be further subdivided into child namespaces. Each namespace contains a set of related types, resulting in the division into namespaces that is functional, and which makes a large library easier to understand.

Microsoft uses the following convention for namespace names . You should adopt the same approach when defining your own namespaces, especially if you're going to publish them:

 <Company>.<Technology>[.<Feature>][.Design] 

Features can be split into subfeatures. You use the Design suffix only for namespaces that implement design-time functionality. Some examples of namespaces in the .NET Framework Class Library are Microsoft.Win32 , System.Web.Services , System.Security.Cryptography.Xml , and System.Windows.Forms.Design . Notice that Microsoft makes extensive use of the pseudocompany System . You should not use System for your own namespaces.

From a J# perspective, a namespace is treated syntactically like a Java package: You can use the import statement to bring the contents of a namespace into scope. However, unlike regular Java packages, a namespace is purely a logical organization of types and does not imply any physical directory structure.

The relationship between assemblies and namespaces can be confusing. A single assembly can implement more than one namespace. For example, the primary runtime assembly, mscorlib.dll, contains code for the System namespace as well as System.Collections , System.Reflection , System.Security , System.Threading , and several others.

Frequently Used Namespaces

The most important namespace is System . This namespace contains the fundamental base classes, types, and other services exposed by .NET.

The System Namespace and the System Object

Although the .NET Framework is designed to provide cross-language support, its use of namespaces and how they are mapped to Java packages can lead to confusion for the unwary developer. An example of this is the System namespace.

In the .NET Framework Class Library, the System namespace contains the fundamental types and objects, plus some utility classes. However, the Java language also defines its own core set of class libraries; to maintain interoperability with programs written in Java, Microsoft has tried to support many of these in J#. In the java.lang package of the Java class libraries, you'll find an object that is also called System . It contains a field named out . The out field exposes a method called println that you can use to display data on the console screen, using the following statement:

 System.out.println("Hello,World"); 

The J# compiler has to use its knowledge of the System namespace and the System object in the java.lang package to determine which particular "System" it should be using in any given context. For example, the following statement refers to the System namespace rather than the java.lang.System object:

 System.Console.WriteLine("Hello,World"); 

This can all be very confusing. I'm afraid you just have to live with it and make sure you know which System is which! This ambiguity occurs elsewhere as well. The Java language and .NET both have their own Object and String types, for example. Chapter 3 describes in more detail how the Java language class libraries and types are reconciled with those of .NET.

The System.Collections and System.Collections.Specialized namespaces define useful utility classes for maintaining collections of data. Examples include lists, queues, dictionaries, dynamic arrays, and hash tables.

System.Reflection provides classes that allow you to examine the metadata of objects found in assemblies. You can use this information to dynamically create objects, invoke methods, and process attributes.

The System.Security namespace and its child namespaces System.Security.Cryptography , System.Security.Permissions , System.Security.Policy , and System.Security.Principal give you access to the security system underlying the runtime.

The System.Threading namespace implements the .NET multithreading primitives and synchronization objects.

System.Data and its child namespaces contain the classes needed to manipulate databases using ADO.NET and SQL.

System.Net and System.Net.Sockets provide low-level programmatic access to the Internet and the Web.

System.Runtime.Remoting and its child namespaces contain classes and methods useful for building distributed applications.

System.Web and its subnamespaces implement classes that support Web server and Web browser interaction and well as Web services. This namespace contains child namespaces that you can use for defining specialized Web controls and for building GUI applications running using a Web browser.

The System.Windows.Forms and System.Windows.Forms.Design namespaces provide classes for building GUI applications and controls that are designed to run using the Windows operating system.

System.Xml and its child namespaces contain classes for handling XML, XML Schemas, XSL/T Transformations, XPath expressions, XML namespaces, and SOAP.

I l @ ve RuBoard