Managed C++ and .NET Development: Visual Studio .NET 2003 Edition

It's unlikely that you'll use every namespace in the .NET Framework class library. (That's not to say you won't—it's just unlikely.) Instead, you'll probably work with the subset of namespaces that follow.

I will start with the root namespace System and then progress alphabetically through the most common namespaces. This chapter will not provide you everything you need to implement the classes within a namespace. Instead, it will give you an understanding of what functionality resides within it. If you want a deeper understanding of all the details of the classes within a namespace, and I do not cover the namespace in the subsequent chapters, then I suggest you peruse the documentation provided with the .NET Framework, as it is remarkably well done.

System

The System namespace is the root of the .NET Framework class library namespace hierarchy. The namespace is defined within the mscorlib.dll assembly.

Unlike the other namespaces of the .NET Framework class library, which focus on a particular area of functionality, the System namespace is more a mishmash of core data types and basic functionality that is needed by the rest of the namespace hierarchy.

The most important class within the System namespace would probably be the Object class because it is the root of all other classes found within the class library. When you create managed (__gc) classes of your own, the Object class is inherited by default if you do not specify a parent class. Remember, because managed (__gc) classes can only inherit from other managed (__gc) classes, ultimately your class will inherit the Object class.

Some of the other common functional areas covered by the System namespace are as follows:

• Primitive types, such as Byte, Int32, Double, and String

• Arrays

• Data type conversion

• Attributes

• Delegates

• Enums

• Events

• Exceptions

• Garbage collection

• Math

• Operating system information

• Random numbers

As you can see, you have already covered most of these areas in prior chapters.

Normally, a developer would allow garbage collection to be handled automatically by the CLR because it's a well-tuned process. For some applications, there might be occasions when garbage collection simply doesn't run often enough or at the times wanted by the developer. For these cases, the .NET Framework class library provides the System::GC class. This class doesn't allow the programmer the ability to change the garbage collection process, but it changes the triggering process and helps determine what memory is garbage.

The Math class is an important class that I haven't yet covered. It's made up of a set of static data type overloaded member methods such as Abs(), Exp(), Max(), and Sin(). These methods are easy to use. For example, to find the square root of a number, simply code the following:

double val = 16, root; root = System::Math::Sqrt( val );

Another class that can come in handy is System::OperatingSystem. This class provides information such as the version and platform identifier. The System::Version class is used to hold the four-part version (Build, Major, Minor, and Revision) used by the .NET Framework.

Being a games program developer at heart, one of the first classes I went in search of was the random number generator. System::Random provides random numbers in both integer and floating-point formats.

System::Random &rand = *new System::Random(); Int32 Int32RandomNumber = rand.Next(1, 10); // between 1 and 10 inclusive Double DoubleRandomNumber = rand.NextDouble(); // between 0.0 and 1.0

System::Collections

There are, in fact, two sets of collections available to the .NET Framework programmer: System::Collections and System::Collections::Specialized. As the namespaces suggest, the first set contains generic collection types and the second contains collection types with a more specific purpose. You will find the more common and frequently used System::Collections in the mscorlib.dll assembly, whereas the less frequently used System::Collections::Specialized is in the system.dll assembly.

Because collections are an integral part of most .NET software development, Chapter 7 goes into many of these collections in much greater detail.

Table 5-1 shows you at a quick glance what collection types are found in the System::Collections namespace.

Table 5-2 lists all the collection types that you will find in System::Collection::Specialized. As you can see, you will probably use these collections less often, but the .NET Framework class library is nice enough to provide them if you ever end up needing to use one of them.

System::Data

The System::Data namespace is the root for all ADO.NET classes found in the .NET Framework class library. ADO.NET is a new data access technology written for the .NET Framework and meant to replace the use of ADO where it is important to remain entirely within .NET. Accessing a database is a very common practice in software development, so you might think that it would be included in the mscorlib.dll default assembly, but you would be wrong. You need to reference two different assemblies. The first is the System.Data.dll assembly, which makes sense now that you know that it's a separate assembly. The second is the System.Xml.dll assembly. I'll go into detail about why this assembly is needed later in Chapter 12. A simple reason is that ADO.NET uses a lot of XML and exposes member methods that use XML. To include these assemblies, if you don't remember, simply add these lines to the top of your source:

#using <System.data.dll> #using <System.Xml.dll>

The System::Data namespace comprises most of the classes that make up the ADO.NET architecture. The classes that represent the specific databases to which ADO.NET will connect are missing. These classes are known in ADO.NET-speak as data providers. Currently, ADO.NET supports multiple data providers. The data providers found in the System::Data namespace are

• System::Data::SqlClient: For Microsoft SQL Server database access

• System::Data::Odbc: For ODBC database access

• System::Data::OleDb: For OLE DB database access

• System::Data::OracleClient: For Oracle database access

Many classes are contained within the System::Data namespace. Depending on your database needs, you may require the use of many of these classes. Most likely, though, you'll only have to rely on a few. Table 5-3 provides a list of the more common classes that you may encounter. But don't despair immediately if the specific database access functionality you require isn't in this table. Chances are that there's a class within this namespace that does what you need because System::Data is quite thorough.

You will look at the System::Data and its two data provider namespaces when you learn about ADO.NET in great detail in Chapter 12.

System::Diagnostics

Executing a program in the CLR environment has its advantages, one of those being readily available diagnostic information. True, it is possible to code your traditional C++ to capture diagnostic information but, with .NET, you get it virtually free with the classes within the System::Diagnostics namespace. The only catch is that because this namespace is not used that frequently, you need to implement the system.dll assembly:

#using <System.dll>

The diagnostic functionality available ranges from simply allowing viewing of event log files and performance counters to allowing direct interaction with system processes. An added bonus is that this namespace provides classes to handle debugging and tracing.

Two main classes handle event logs in the System::Diagnostics namespace. Event Log provides the ability to create, read, write, and delete event logs or event sources across a network. EntryWrittenEventHandler provides asynchronous interaction with event logs. Numerous supporting classes provide more detailed control over the event logs.

It is possible to monitor system performance using the class PerformanceCounter. It is also possible to set up your own custom performance counters using the class PerformanceCounterCategory. You can only write to local counters, but the restriction is eased when it comes to reading counters. Of course, you need to have the right to access the remote machine from where you want to read the counter.

The System::Diagnostics namespace provides an amazing amount of power when it comes to processes. For example, the Process class has the ability to start, monitor, and stop processes on your local machine. In fact, the Process class can also monitor processes on remote machines. Added to this are the ProcessThread and ProcessModule classes, which allow you to monitor the process threads and modules. It is also possible to control how a process runs by having control over things such as arguments and environment variables, and input, output, and error streams using the ProcessStartInfo class.

Almost every programmer uses debug and/or trace statements within his code. So common is the practice that the .NET Framework class library includes the Debug and Trace classes to ease your coding life. Syntactically, the Debug and Trace classes are nearly identical. The difference between them lies in the time of compilation and the current development environment being used. Trace statements are executed no matter what the environment (unless you code otherwise), whereas debug statements are only included and executed while within the Debug environment.

Table 5-4 provides you with a quick lookup table of the classes you might find useful within the System::Diagnostics namespace.

System::DirectoryServices

System::DirectoryServices is a small namespace providing easy access to Active Directory. Not the most commonly used namespace, it has been placed in its own assembly, System.Directoryservices.dll. To add the namespace, you require the following code at the top of your source:

#using <System.Directoryservices.dll>

It is assumed that you have prior knowledge of Active Directory before you use the class but, in a nutshell, here is how to use the class. First, you use the class DirectoryEntry constructor to get access to a node or object within Active Directory. Then, with the DirectoryEntry node and some help classes, you are now capable of activities such as creating, deleting, renaming, setting passwords, moving a child node, and enumerating children.

You can use the classes in this namespace with any of the Active Directory service providers. The current providers are

• Internet Information Services (IIS)

• Lightweight Directory Access Protocol (LDAP)

• Novell NetWare Directory Service (NDS)

• Windows NT

Another class that you might find of some use in System::DirectoryServices is the DirectorySearcher class. This class allows you to perform a query against an Active Directory hierarchy. Unfortunately, as of now only LDAP supports DirectorySearcher.

System::Drawing

Computer software without some form of graphics is nearly a thing of the past, especially in the PC world. The .NET Framework relies on a technology named GDI+ to handle graphics. GDI+ is easy to use. It is designed to handle the myriad of graphic adapters and printers in a device-independent fashion, thus saving you from having to worry about coding for each graphic device on your own. Of course, this is not a new concept as Windows has had a Graphical Device Interface (GDI) since its earliest versions. Those of you from the GDI world should see a considerable simplification of how you now have to code graphics. But you will also find a huge increase in added functionality.

System::Drawing provides the core graphic classes of GDI+, whereas the following four other child namespaces provide more specialized graphics capabilities:

• System::Drawing::Drawing2D: Adds advanced two-dimensional (2D) and vector graphics

• System::Drawing::Imaging: Adds advanced GDI+ imaging

• System::Drawing::Printing: Adds print-related services

• System::Drawing::Text: Adds advanced GDI+ typography

Every System.Drawing namespace requires that you add the System.Draw.dll assembly to the top of your source:

#using <System.Drawing.dll>

I'll go into GDI+ software development in detail in Chapter 11, but for those of you who can't wait that long, here's a brief summary of the functionality.

The core of all GDI+ classes can be found in the System::Drawing namespace. This large namespace contains classes to handle things ranging from a point on the graphics device all the way up to loading and displaying a complete image in many graphic file formats, including BMP, GIF, and JPEG.

The key to all graphics development is the aptly named Graphics class. This class basically encapsulates the graphics device—for example, the display adaptor or printer. With it you can draw a point, line, polygon, or even a complete image. When you use the Graphics class with other System::Drawing classes, such as Brush, Color, Font, and Pen, you have the means to create amazing and creative images on your display device.

Though you can do almost any 2D work you want with System::Drawing, the .NET Framework class library provides you with another set of classes found within the System::Drawing::Drawing2D that allows for more fine-tuned 2D work. The basic principle is similar to the "connect-the-dots" pictures that you did as a kid. The image you want to draw is laid out in 2D space by drawing straight and curved lines from one point to another. Images can be left open or closed. They can also be filled. Filling and line drawing can be done using a brush and/or using a color gradient.

The System::Drawing namespace can handle most imaging functionality. With the System::Drawing::Imaging namespace, you can add new image formats that GDI+ does not support. You can also define a graphic metafile that describes a sequence of graphics operations that can be recorded and then played back.

GDI+ can display (or, more accurately, print) to a printer. To do so is very similar to displaying to a monitor. The difference is that a printer has many different controls that you will not find on a monitor—for example, a paper source or page feed. All these differences were encapsulated and placed into the System::Drawing::Printing namespace.

Nearly all the functionality to handle text is located within the System::Drawing namespace. The only thing left out and placed in the System::Drawing::Text namespace is the ability to allow users to create and use collections of fonts.

System::Globalization

The System::Globalization namespace contains classes that define culture-related information, such as language, currency, numbers, and calendar. Because globalization is a key aspect of .NET, the namespace was included within the mscorlib.dll assembly.

You will cover globalization when you learn about assembly programming in Chapter 17. The CultureInfo class contains information about a specific culture, such as the associated language, the country or region where the culture is located, and even the culture's calendar. Within the CultureInfo class, you will also find reference to the date, time, and number formats the culture uses. Table 5-5 shows some of the more common classes within the System::Globalization namespace.

System::IO

If you are not using a database to retrieve and store data, then you are most probably using file and/or stream input and output (I/O). Of course, it is completely possible that you are using a database and file and stream I/O within the same application. As you can guess by the System::IO namespace's name, it handles the .NET Framework library class's file and stream I/O. To access System::IO, you need to reference the mscorlib.dll assembly:

#using <mscorlib.dll>

Typically when you deal with the System::IO namespace's classes, you are working with files and directories on your local machine and network, or streams of data probably via the Internet. These, however, are not the only uses of the classes found within the System::IO namespace. For example, it is possible to read data from and write data to computer memory, usually either a string buffer or a specific memory location.

You will be going into the .NET Framework class library's I/O capabilities in some detail in Chapter 8. For now, Table 5-6 shows some of the more common classes that you might come across in the System::IO namespace.

System::Net

This namespace will be hidden from most Web developers using .NET, as they will most likely use ASP.NET's higher-level extraction of Internet communication. For those of you who are more intimate with the networks, the .NET Framework class library has provided the System::Net and System::Net::Sockets namespaces. To access both the System::Net and System::Net::Sockets namespaces, you need to reference the system.dll assembly near the top of your code:

#using <system.dll>

The System::Net namespace provides a simple programming interface for many of today's network protocols. It enables you to do things such as manage cookies, make DSN lookups, and communicate with HTTP and FTP servers.

If that is not intimate enough for you, then the System::Net::Sockets namespace provides you with the ability to program at the sockets level.

For those of you who want to program your network at this lower level, Table 5-7 shows some of the more commonly used System::Net and System::Net::Sockets classes.

System::Reflection

Most of the time when you develop code, it will involve static loading of assemblies and the data types found within. You will know that, to execute properly, application X requires class Y's method Z. This is pretty standard and most programmers do it without thinking.

This is the normal way of developing with the .NET Framework class library as well. There are times, though, that a developer may not know which class, method, or other data type is needed for successful execution until the time that the application is running. What is needed is dynamic instance creation of data types. With the .NET Framework class library, this is handled by the classes within the System::Reflection namespace found within the mscorlib.dll assembly:

#using <mscorlib.dll>

The System::Reflection namespace provides a class that encapsulates assemblies, modules, and types. With this encapsulation, you can now examine loaded classes, structures, methods, and so forth. You can also create dynamically an instance of a type and then invoke one of its methods, or access its properties or member variables.

You will explore System::Reflection in more detail when you examine assembly programming in Chapter 17. Table 5-8 shows some of the more common classes that you might use within the System::Reflection namespace.

System::Resources

The .NET Framework can handle resources in several different ways: in an assembly, in a satellite assembly, or as external resource files and streams. The handling of resources within the .NET Framework class library for any of these three ways lies in the classes of the System::Resources namespace. Handling resources is a very common task, so it was placed within the mscorlib.dll assembly:

#using <mscorlib.dll>

Resources can be fixed for an application divided by culture. You will examine resources programming when you cover assembly programming in Chapter 17. You will be dealing mostly with three classes within the System::Resources namespace, as shown in Table 5-9.

System::Threading

Multithread programming can be a very powerful feature, as it allows for more optimal CPU usage and better response time. Very seldom is a computer at 100 percent usage, and running more than one thread concurrently can help you get more out of your CPU.

The .NET Framework has built-in multithreading. In fact, an important feature of .NET, garbage collection, is handled using multithreading. The .NET Framework exposes its multithreading capabilities with the classes found in the System::Threading namespace. Multithreading, being an important and frequently used feature of the .NET Framework, is found in the mscorlib.dll assembly:

#using <mscorlib.dll>

The System::Threading namespace provides a class to manage groups of threads, a thread scheduler, a class to synchronize mutually exclusive threads, and an assortment of other functionalities to handle multithreading. I will cover multithreading in Chapter 16. For now, Table 5-10 lists all the common classes in the System::Threading namespace that you might use.

System::Web

The System::Web namespace and the hierarchy of namespaces below it make up a major portion of the .NET Framework class library. This makes sense, as .NET came into being because of the Internet and the World Wide Web.

The System::Web hierarchy is too massive to cover fully here, so I'll leave it to the .NET Framework documentation to provide any detailed explanations you need of any particular class. The .NET Framework breaks Web development into two pieces: Web applications and Web services, which you'll examine in Chapters 14 and 15, respectively. These chapters really just scratch the surface of the functionality available to you as a .NET Web developer.

Table 5-11 will help you to navigate through the myriad of classes provided by the System::Web namespace hierarchy by providing you with a list of some of the more common namespaces (you read that right, namespaces) that you might use.

System::Windows::Forms

Visual Basic has been using forms for many versions, and Windows Forms is modeled on Visual Basic's form technology, but with a much finer grain of control. Normally you will create Windows Forms using a drag-and-drop tool but you also have full access to all aspects of the Win form within your code.

As of the current release, Windows Forms and Windows-based GUI applications are pretty much synonymous. On the other hand, if the .NET Framework starts to get ported to other platforms, as it can be, then a Windows Form will be more equivalent to a GUI application.

First off, all the classes that make up the .NET Windows Forms environment are actually found within the System::Windows::Forms namespace. This namespace is large, containing around 400 different types (classes, structures, enumerations, and delegates). You probably will not use every type within the namespace, but there is a good chance that you may use a large number of them, especially if your Windows Form has any complexity involved.

You will cover Windows Forms in detail in Chapters 9 and 10, but you will also see them used many times in subsequent chapters. For those of you who want a head start, Table 5-12 shows a good number of common classes that you will become quite familiar with if you plan to build Windows Forms.

System::Xml

XML is a key component of the .NET Framework. Much of the underlying technological architecture of .NET revolves around XML. No matter what type of application you plan on developing, be it for the Web or a local machine, there is a good chance that somewhere in your application XML is being used. You just might not be aware of it. Because of this, there are a lot of specialized XML classes available to a .NET developer.

To provide XML support to your .NET applications requires the addition of the System.Xml.dll assembly to the top of your source code:

#using <System.Xml.dll>

The .NET Framework provides a developer two different methods of processing XML data: a fast, noncaching, forward-only stream, and a random access in-memory Document Object Model (DOM) tree. You will cover both methods in Chapter 13. You will also see a little bit of XML in Chapter 15.

Table 5-13 shows all of the .NET Framework class library's XML-related classes that fall within the System::Xml namespace hierarchy.