A Closer Look at the .NET Framework

Okay, you have looked at .NET and the .NET Framework in general terms. Now, let's break it into the elements that are relevant to a Managed C++ programmer and then look at each element in some detail. There are five major elements that a Managed C++ developer should have at least a basic knowledge of before attempting to code:

• Assemblies

• CLR

• Common type system (CTS)

• Common Language Specification (CLS)

• .NET Framework class library

Each element impacts the Managed C++ programmer differently. Assemblies are a new form of binary distribution. The CLR is a new way of executing. The CTS is a new way of defining data-storage types. CLS is a specification of language-neutral support. The .NET Framework class library is a whole new set of development objects to learn. I discuss each of these elements in more detail in the following sections.

Assemblies

You need a basic understanding of assemblies before you can learn about any other element of the .NET Framework. I cover some basic information about assemblies in this chapter and then discuss working with them in detail in Chapter 17.

Assemblies are the core building blocks for all .NET Framework application distribution and execution. They are generated after compiling Managed C++ code. Like pre-.NET application deliverables, they end with either .exe or .dll, but that is as far as the similarities go.

Basic Structure

Assemblies are a self-describing collection of functionalities stored in an intermediate language and/or resources needed to execute some portion of an application. Assemblies are made up of four sections: the assembly metadata, type metadata, Microsoft intermediate language (MSIL) code, and resources (see Figure 1-2). All of the sections but the assembly metadata are optional, though an assembly made up of just this section won't do anything.

Figure 1-2: The basic assembly structure

Assemblies can be either private or shared. Private assemblies reside in the same directory as the application itself or in one of its child directories. Shared assemblies, on the other hand, are stored in the global assembly cache (GAC). The GAC is really nothing more than a directory structure that stores all the assemblies that are globally available to the computer (see Figure 1-3). A neat feature of the GAC is that more than one version of the same assembly can reside in it.

Figure 1-3: The global assembly cache

A key feature of all assemblies is that they are self-describing. In other words, all information needed to understand how to use the assembly can be found within the assembly itself. An assembly does this by including metadata directly within itself. There are two different metadata sections in an assembly: the assembly metadata and the type metadata.

Metadata

The assembly metadata is also known as the assembly manifest. As its name suggests, the assembly metadata describes the assembly. Here is a list of the assembly metadata's contents:

• The name of the assembly.

• The version number.

• The culture used by the assembly (i.e., language, currency, number formatting, and so on).

• Strong name information. This is a uniquely identifiable name that can be used for shared assemblies.

• A list of all files that make up the assembly.

• A list of all reference assemblies.

• Reference information for all exported classes, methods, properties, and so on found in the assembly.

The type metadata, on the other hand, describes the types within the assembly. The type metadata generated depends on the type being created. For example, if the type were a method, then the metadata generated would contain things such as the name, return types, number of arguments and their types, and access level. A property, on the other hand, would reference the get and set methods; these methods in turn would contain names, return types, and so on.

A nice feature of metadata is that it can be used by many of the tools available to the Managed C++ developer. For example, Visual Studio .NET's IntelliSense statement completion functionality (see Figure 1-4) is actually driven using the reference assembly's metadata and not some secondary description file. Because it comes directly from an assembly, IntelliSense will also work for assemblies you have written yourself without any additional effort on your part.

Figure 1-4: Visual Studio .NET's IntelliSense using metadata

Versioning

Application assemblies are very version-aware when they're referencing strong-named assemblies (usually out of the GAC). Every assembly has a version number. Also, every referencing assembly stores the version number of any assembly that it references. It's not until the referenced assembly is strong named that the referencing assembly automatically checks when executing, via the CLR, that the versions match before it continues to execute. You should note there's nothing stopping you from coding your referencing assembly to do this check manually. I cover assembly versioning in detail in Chapter 17.

Microsoft Intermediate Language

A major change that you are going to have to get used to as a Managed C++ programmer is that Managed C++ code gets compiled to Microsoft intermediate language (MSIL) and not machine code. MSIL is a CPU-independent set of instructions similar to an assembly language. For example, it contains arithmetic and logical operators and flow control. But, unlike the average assembly language, it also contains higher-level instructions to load, store, initialize, and call class objects.

Just for some grins and giggles, here is an example of some MSIL generated from a simple Managed C++ program. See if you can figure out what it does.

 IL_0000:  ldarg.0 IL_0001:  ldarg.1 IL_0002:  add IL_0003:  stloc.0 IL_0004:  ldstr     "{0} + {1} = {2}" IL_0009:  ldarga.s  val1 IL_000b:  call      instance string [mscorlib]System.Int32::ToString() IL_0010:  ldarga.s  val2 IL_0012:  call      instance string [mscorlib]System.Int32::ToString() IL_0017:  ldloca.s  total IL_0019:  call      instance string [mscorlib]System.Int32::ToString() IL_001e:  call      void [mscorlib]System.Console::WriteLine(string,                                                               object,                                                               object,                                                               object) IL_0023:  ret 

For those of you who are curious, the preceding code adds two numbers together and then writes the result out to the console.

MSIL is easily converted to native code. In fact, when the MSIL code is loaded by the CLR, it gets rapidly compiled to native code.

Note

The MSIL in an assembly is compiled prior to execution. It is not interpreted at runtime.

One key characteristic of MSIL is that it is an object-orientation-based language with the restriction of single class inheritance, though multiple inheritance of interfaces is allowed. All types, both value and reference, used within the MSIL must conform to the CTS. Any exposed types must follow the CLS. I cover both CTS and CLS later in this chapter. Error handling should be done using exceptions.

MSIL is the key to .NET's capability to be language neutral. All code, no matter what the programming language, gets compiled into the same MSIL. Because all languages ultimately compile to the same MSIL, it is now possible to have things such as encapsulation, inheritance, polymorphism, exception handling, debugging, and so on be language neutral.

MSIL will also be one of the keys to .NET's capability to be platform independent. With MSIL, you can have "write once, run anywhere" ability, just as you do with Java. All that is required for an assembly to run on a non-Windows platform is for the ported CLR to compile MSIL into non-Windows-specific code.

With the combination of MSIL and metadata, .NET is capable of providing a high level of security. For example, strong names found in metadata can ensure that only trusted assemblies are run. If you add to this code verification of MSIL, then the CLR can ensure that only managed code running with valid commands gets executed.

Resources

In .NET, resources (i.e., string tables, images, cursors, and so on) can be stored in two places: in external .resources files or directly within an assembly. Accessing the resources in either location is extremely easy, as the .NET Framework class library provides three straightforward classes for access within the System::Resources namespace. I cover these classes in detail in Chapter 17, but if you want to get a head start and look them up yourself, here they are:

• ResourceManager: Use to access resources from within an assembly

• ResourceWriter: Use to write resources to an external .resources file

• ResourceReader: Use to read resources from an external .resources file

In addition to these classes, the .NET Framework provides the utility resgen.exe, which creates a .resources file from a text file containing key/value pairs.

The resgen.exe utility is very useful if you wish to make your Windows applications support multiple (human) languages. It's easy to do this. Simply create multiple .resources files, one for each language. From these, build satellite assemblies for each language. Then the application will automatically access the correct language resource based on the current culture specified on the computer. You'll learn how to do this in Chapter 17.

Common Language Runtime

Runtimes are hardly a new concept when it comes to code execution. Visual Basic has msvbvm60.dll, and Java, of course, has the Java Virtual Machine (JVM). The common language runtime (CLR) is .NET's runtime system.

Do we need another runtime? What makes this one that much better than all the rest? It is simply the fact that the CLR is designed to be the runtime for all languages and (possibly) all platforms. Or, in other words, you no longer need a myriad of different runtimes to handle each programming language and platform. Instead, all you need is the CLR.

It's a pretty big claim. Does it hold water?

There are two common roles for runtimes: to execute code and/or to add common functionality used by most applications. The CLR performs both of these roles for the .NET Framework. But these roles are only the tip of the iceberg. The CLR also performs several other services, such as code verification, access security, garbage collection, and exception handling, and it also handles multilanguage support and compiles MSIL into the native language of the platform (see Figure 1-5).

Figure 1-5: The CLR start-up process flow

Starting up an application in .NET is conceptually very simple. The CLR loads the application assembly, any referenced developer assemblies, and any referenced class library assemblies. Then, the application is optionally verified for type safety and valid access security. Next, the loaded MSIL, with the help of information found in the metadata from the assemblies, is compiled into native code. Finally, the application is executed.

The CLR was designed to provide

• Simple, fast development: This is possible through a large, consistent, reusable framework.

• Simplified programming infrastructure: Much of the plumbing (memory management, local and remote process communication, and so on) is handled automatically or hidden unless access is needed.

• Scalability: Areas that allow for scalability (memory management, process communication, component management, and so on) are contained, already optimized, within the framework.

• Simple, safe deployment: A simple xcopy is usually all that is required for deployment.

Managed Code

Basically, managed code is code targeted for the .NET Framework's CLR. Managed code must supply the metadata needed by the CLR to handle things such as memory management, code access security, and multilanguage integration. Essentially, if the code is compiled into MSIL within assemblies, then you can be confident that you are creating managed code.

Conversely, unmanaged code is any code not targeted for the CLR. It is possible for the .NET Framework to access C DLLs, COM, and COM+ services, even though all of these are unmanaged.

All of the compilers that come with the .NET Framework default to generating managed code except C++. To create managed code in C++, you need to add the command-line switch /CLR when compiling. When you use Visual Studio .NET, simply select one of the managed C++ project templates, as these will set the switch for you.

Managed Data

Managed data is data that is allocated by an application and then deallocated by the CLR's garbage collector. Like managed code, all .NET languages except C++ default to managed data, even if you use C++'s /CLR switch. To create managed data in C++, you must use the keyword __gc in your source code.

Common Language Runtime Services

Along with loading and executing an assembly, the CLR provides several other services. Code verification and code access verification are optional services available before the assembly is loaded. Garbage collection, on the other hand, is always active while the assembly is being executed.

Code Verification

The code verification service is executed prior to actually running the application. Its goal is to walk through the code, ensuring that it is safe to run. For example, it checks for things such as invalid pointer references and array indexes. The goal of code verification is to ensure that the code does not crash, and that if an error happens to occur, it is handled by the CLR by throwing an exception. This gives the application more control over how to recover or exit gracefully.

Code Access Verification

Code access verification also walks through the code and checks that all code has the permission to execute. The goal of this service is to try to stop malicious attacks on the user's computer.

A simplified way of looking at how this service works is that the CLR contains a list of actions that it can grant permission to execute, and the assembly contains a list of all the permissions it requires to run. If the CLR can grant all the permissions, then the assembly runs without problems. If, on the other hand, the CLR can't grant all the permissions, then it runs what it can but generates an exception whenever it tries to do something that it doesn't have permission to do.

Garbage Collection

Garbage collection is the mechanism that allows a computer to detect and remove managed objects from the heap that are no longer being accessed by an application. The .NET Framework's garbage collector has the added bonus of compacting the memory after it removes the unused portion, thus keeping the fingerprints of the applications as small as possible. This bonus also has a downside. Managed objects in .NET do not have a fixed location, but you can overcome this with the __pin keyword. I cover __pin in Chapter 3. Also, pointer arithmetic is gone except in unsafe sections of the code.

Garbage collection presents a big change to average C++ programmers, as it means an end to most of those annoying memory leaks that plague them while developing. It also has an added bonus: Programmers no longer have to figure out where to call the delete command to the classes that they've created using the new command.

Garbage collection is not the default for C++. Because this is the case, there are a few things (covered in Chapter 3) that Managed C++ programmers need to learn before they can use garbage collection—in particular, the keyword __gc. Also, programmers have no control of when a managed object that is no longer referenced gets deleted.

Attributes

Attributes are a way for developers to provide additional information about the classes, methods, or data types to the assemblies they are creating. This additional information is stored within the assembly's metadata.

There are several predefined attributes that the compiler can use to help during the compile process. For example, the System::Obsolete attribute causes the compiler to generate a warning when it encounters an obsolete method in a class library assembly.

You will see in Chapter 17 how to work with attributes and how it is possible to add your own custom attributes to the assembly metadata.

All attributes, developer code-created and compiler-generated, can be extracted using reflection.

Reflection

An interesting service provided by the CLR is reflection. This is the ability to programmatically examine the metadata within an assembly, including the one executing the reflection code. This service allows access to the metadata information, such as details about classes, methods, properties, and so on, contained within the assembly.

Most likely, you will use reflection to get attribute information out of the assembly metadata. For more advanced Managed C++ developers, reflection provides the ability to extract type information within a class so that they can use it to generate types dynamically.

Reflection is accomplished using the myriad classes in the System::Reflection namespace. Chapter 17 covers reflection.

Multiple Language Support

.NET had the ambitious goal of creating a completely language-neutral environment for developing software. Some of the features the .NET Framework and Visual Studio .NET developers had in mind when it came to being language-neutral were as follows:

• Common data types should be shared by all languages.

• Object pointers and/or references from any language should be able to be passed as an argument to a method.

• Calling methods from classes created in other languages should be possible.

• Classes should be able to contain instances of other classes created in a different language.

• Inheriting from classes created in another language should be possible.

• The development environment for all languages should be the same.

• Debugging all languages should be possible using the same environment.

• Debugging should be able to navigate between languages.

Believe it or not, every one of those features is now supported by the .NET Framework within the Visual Studio .NET development environment.

The idea is to pick the best language for the job. Each language has its strong and weak points when it comes to software development. With language-neutral development, you can select the language that best suits the type of development needed.

Will developers accept this concept? In this age of computer-language holy wars, it seems a little doubtful. Plus, allowing the use of multiple languages during the development of a project does add complexity. Having said that, though, I've worked on a large project that used, alphabetically, C, C++, COBOL, HTML, Macro (Assembler), and SQL, plus an assortment of batch scripting languages. To make things worse, each of these languages had different tools for development, and debugging was a nightmare. I don't even want to talk about passing data between modules created in different languages. What I would have given for .NET back then.

How does the .NET Framework create a language-neutral environment? The key is a combination of MSIL and metadata. Basically, the MSIL code tells the CLR what to do (which commands to execute), and the metadata tells it how to do it (which interfaces and calling conventions to use). For a language to be .NET Framework compliant, it obviously needs to be compiled into MSIL code and metadata, and placed in an assembly (see Figure 1-6).

Figure 1-6: Many compilers, one output

Because all languages have this requirement, Microsoft was able to tweak each language they developed so that it created code to conform to their MSIL and metadata language-neutral requirements. These tweaks mostly enabled the languages to support true objects and exception handling, as these are the main characteristics of MSIL. Also, all languages were changed to conform to the common type system (CTS). I cover the CTS later in this chapter.

Multiple Platform Support

By its architecture, the .NET Framework is conducive to multiple platform support. The CLR enables platform independence by providing a runtime layer that sits between the operating system and the application. The just-in-time (JIT) compiler generates machine-specific native code. JIT is covered in the next section, "Just-in-Time Compilation." The MSIL and metadata allow for the "write once, run anywhere" capability that is the claim to fame of Java.

Currently, the only multiple platform support provided by the .NET Framework is for Windows-based platforms such as Windows 2000 and Windows XP. Microsoft says that they plan to support other platforms such as UNIX and Mac OS, but as of now Microsoft is not disclosing any details on when this support will be forthcoming.

What does platform independence mean to C++ programmers? It means a new way of looking at things. C++ programmers think of multiple platform support as coding generically and recompiling on each new platform. With the .NET Framework, developers only need to develop the code and compile it once. The resulting assembly could be run on any supported platform without change.

True, to develop true platform-independent code, developers must only use managed code. If a developer were to use unmanaged code, the assembly generated would become closely coupled with the architecture it was compiled on.

Note

This book focuses on creating code that is platform independent.

Just-in-Time Compilation

Even though .NET applications are stored in an intermediate language, .NET applications are not interpreted. Instead, they are compiled into a native executable. It is the job of the JIT compiler, a key component of the CLR, to convert MSIL code into machine code with the help of metadata found in the executable assembly.

The JIT compiling process is, in concept, very easy. When an application is started, the JIT compiler is called to convert the MSIL code and metadata into machine code. To avoid the potentially slow start-up time caused by compiling the entire application, the JIT compiler only compiles the portions of code that it calls, when they are called (hence the name "just-in-time compiler"). After the code is compiled, it is placed in cached memory and then run. The compiled code remains in the cached memory for as long as the application is executing. This way, the portion of code can be grabbed from cached memory, instead of having to go through the compile process each time it is called. There is a bonus in compiling this way. If the code is not called, it does not get compiled.

Microsoft claims that managed code should run faster than unmanaged code. How can Microsoft make this claim? The JIT compiler is amazingly fast, but there still is the overhead of having to compile the application each time it is run. This leads one to believe that managed code would be slower.

The key to Microsoft's claim is that JIT compilers generate code specific to the processor type of the machine they are running on. On the other hand, traditional compilers generate code targeting a general range of processor types. For example, the Visual Studio 6.0 C++ compiler generates generic Pentium machine code. A JIT compiler, knowing that it is run on, let's say, a quad processor Pentium IV, would generate code specific to that processor. The execution time between these two sets of machine code will in many cases be quite different and always in the favor of the JIT compiler-generated code. This increase in speed in the managed code should offset the JIT compiling overhead and, in many cases, make the overall execution faster than the unmanaged code.

Common Type System

The common type system (CTS) defines how all types are declared, used, and managed within the .NET Framework and, more specifically, the CLR. It is also a key component for the CLR's multiple language support. The CTS was designed to perform the following functions:

• Provide an object-oriented data model that can support the data types of all .NET Framework-compatible programming languages

• Provide a set of constraints that the data types of a .NET-compatible language must adhere to so that it can interact with other .NET-compatible programming languages

• Provide a framework for .NET-compatible interlanguage integration and data type safety

There are two categories of data types defined by the CTS: the value type and the reference type. Value types, such as int, float, or char, are stored as the representation of the data type itself. Reference types, such as pointers, classes, or arrays, on the other hand, are stored as references to the location of the data type.

As you can see in Figure 1-7, all data types fall into one of these two categories.

Figure 1-7: CTS hierarchy

Let's briefly walk through the hierarchy of all CTS types:

• Arrays: A single or multidimensional indexed grouping of types

• Boxed value types: A temporary reference to a value type so that it can be placed on the heap

• Built-in value types: Primitive value types that represent integers, real numbers, Booleans, and characters

• Class types: A user-defined grouping of types and methods

• Delegates: A type that holds a reference to a method

• Enumerations: A list of named integer constants

• Interface types: A class type where all methods are abstract

• Pointer types: A reference to a type

• User-defined value types: User-defined expansion to the standard, primitive value types

A point worth mentioning is that the CLS defines all .NET-compatible language data types, but a .NET-compatible language does not need to support all CLS-defined data types. You can see this in practice by comparing the built-in value and reference types supported by Visual Basic .NET, C#, and Managed C++ (see Table 1-1).

Table 1-1: Built-in Value and Reference Types and Their Language Keywords

BASE CLASS	VISUAL BASIC .NET	C#	MANAGED C++
System::Byte	Byte	byte	unsigned char
System::Sbyte	Not supported	sbyte	char
System::Int16	Short	short	short
System::Int32	Integer	int	int or long
System::Int64	Long	long	__int64
System::UIntl6	Not supported	ushort	unsigned short
System::UInt32	Not supported	uint	unsigned int or unsigned long
System::UInt64	Not supported	ulong	unsigned __int64
System::Single	Single	float	float
System::Double	Double	double	double
System::Object	Object	object	object*
System::Char	Char	char	__wchar_t
System::String	String	string	String*
System::Decimal	Decimal	decimal	Decimal
System::IntPtr	IntPtr	IntPtr	IntPtr
System::UIntPtr	UIntPtr	UIntPtr	UIntPtr
System::Boolean	Boolean	bool	bool

Caution

You should take care when using UInt64, as unpredictable results are possible on Intel 32-bit platforms because they are not thread safe and do not load the registers automatically.

Common Language Specification

As shown in Table 1-1, not all of the CTS data types are supported by every .NET-compatible language. How then does the .NET Framework maintain that these languages are in fact compatible? This is where the Common Language Specification (CLS) comes in. The CLS is a minimum subset of the CTS that all languages must support to be .NET compatible (see Figure 1-8).

Figure 1-8: CLS intersection diagram

To ensure interlanguage operability, it is only the CLS subset that can be exposed by assemblies. Because you can be assured that all languages' building assemblies are using this subset, you can thus also be assured that all languages will be able to interface with it.

Note

When you develop your .NET code, it is completely acceptable to use the entire CTS. It is only exposed types that need to adhere to the CLS for interlanguage operability.

There is no imposed restriction on using the CLS. If you know that your assemblies will only be used by one language, then it is perfectly acceptable to use all the types available to that language, even those that are exposed. Just be aware that if there comes a time when you want to use your assemblies with another language, they may not work because they do not adhere to the CLS.

If you want to view the CLS, you can find it in the .NET documentation. Just search for "What is the Common Language Specification?" The key points that you should be aware of as a C++ programmer are as follows:

• Global methods and variables are not allowed.

• The CLS does not impose case sensitivity, so make sure that all exposed types differ by more than their case.

• The only primitive types allowed are Byte, Int16, Int32, Int64, Single, Double, Boolean, Char, Decimal, IntPtr, and String.

• Variable-length argument lists are not allowed. Use fixed-length arrays instead.

• Pointers are not allowed.

• Class types must inherit from a CLS-compliant class. System::Object is CLS compliant.

• Array elements must be CLS compliant.

Some other requirements might also affect you, if you get fancy with your coding. But you will most likely come across the ones in the previous list.

.NET Application Development Realms

.NET application development falls into one of four realms: Web applications, Web services, Windows applications, and console applications. Using languages such as C#, Visual Basic .NET, and Visual Studio .NET provides a simple, powerful, and consistent environment to develop all four. Unfortunately, for C++, only three are fully supported: console applications, Windows applications, and Web services.

Although Web applications aren't supported by Visual Studio .NET, this doesn't mean that you can't develop them. It just means you have to do more—in some cases, a lot more—legwork to get things done. But hey, you're a C++ programmer. You're used to this.

Console Applications

Console applications are basically extinct as a final software delivery. But as a developer tool, there is nothing like them. If you need to figure out how to do something, write out a console application. There is nothing simpler and nothing with less overhead. This book is full of console applications for just those reasons.

The key elements of all console applications are the main() function and the System::Console::WriteLine() method. In fact, that is almost all you need to write a console application.

Windows Applications

Windows applications may be the biggest change for C++ programmers. Managed C++ does not support MFC. Wow, don't panic—believe it or not, the .NET Framework has a better solution. It's called Windows Forms and I'm sure you'll think, as I do, that it's a godsend. With Windows Forms, you get the ease of Visual Basic along with the power of C++ when you develop Web applications. I cover Windows applications in Chapters 9 and 10.

When you create Windows Forms, you will use the massive System::Windows::Forms namespace. Though this namespace is large, it is consistent and well laid out. It will not take you long to get good at using it.

Just to add some variety to your Windows applications, .NET also provides a new and improved Graphical Device Interface (GDI) called, conveniently, GDI+. With GDI+, you can play with fonts, change colors and, of course, draw pictures. GDI+ is almost worth learning just for one class, System::Drawing::Image, which allows an application to load almost any commonly supported graphic file formats, including GIF, JPEG, and BMP, into memory, where they can be manipulated and drawn to the screen. To implement GDI+ in the .NET Framework, you need to explore the System::Drawing namespace. I cover GDI+ in Chapter 11.

Web Applications

ASP.NET is a large part of developing Web applications. But unlike traditional Web application development, .NET has changed things. Web applications no longer are run using interpreted scripts. Now they use full-blown compiled applications. These applications are usually written using C# and Visual Studio .NET, but Managed C++ will work as well.

When a user calls on a Web site, he will no longer be looking for .html or .asp files; instead, he will be looking for an .aspx file, a fully compiled Web application. I go into the details of Web applications in Chapter 14, but here are some of the high points.

With Web applications, you will, along with Managed C++, get exposed to ASP.NET, HTML, and ADO.NET. This book will not make you an expert on any of these technologies, but there are other great Apress books that will help you along with that goal. The .NET Framework supports Web applications predominately by using the System::Web namespace and its children. The most important class with Web applications is the System:Web:UI::Page class, which you will need to have intimate knowledge of when you code in Managed C++.

Web Services

You might want to think of a Web service as programmable functionality that you execute over the Internet. Talk about remote programming! Using a simple HTTP request, you can execute some functionality on some computer on the opposite side of the world. Okay, there are still some kinks, such as the possible bandwidth problems, but they will be overcome with the current technology advancement rate—that much I am certain of. Chapter 15 covers Web services.

Web services are based on the technology XML and, more specifically, the XML-derived Simple Object Access Protocol, better known as SOAP. SOAP was designed to exchange information in a decentralized and distributed environment using HTTP. For more technical details about SOAP, peruse the World Wide Web Consortium's Web pages on SOAP (http://www.w3.org/TR/SOAP).

When you code Web services, you will be working primarily with the System::Web::Services namespace. You also get to look at attributes again.

Web services are a key part of Microsoft's plans for .NET because, as you may recall, .NET is about delivering software as a service.

.NET Framework Class Library

Everything you've learned so far is all fine and dandy, but the thing that is really most important, and where Managed C++ programmers will spend many a day, is the massive .NET Framework class library. There are literally hundreds of classes and structures contained within a hierarchy of namespaces. Managed C++ programmers will use many of these classes and structures on a regular basis.

With such a large number of elements in the class library, you would think that a programmer would quickly get lost. Fortunately, this is not true. The .NET Framework class library is, in fact, well organized, easy to use, and virtually self-documenting. Namespaces, class names, properties, methods, and variable names usually make perfect sense. The only real exceptions to this that I have found are class library wrapped native classes. I am sure there are other exceptions, but by and large most namespaces and classes are understandable just by their names. This, obviously, differs considerably from the Win32 API, where obscure names are more the norm.

With the .NET Framework class library, you can have complete control of the computer, because the class library functionality ranges from a very high level, such as the Calendar class, which displays a single month of a calendar on a Web page, down to a very low level, such as the PowerModeChangedEventHandler, which notifies the application when the computer is about to be suspended, resumed, or changed from AC to battery or vice versa.

There are two hierarchies of namespaces in the .NET Framework class library: the platform-neutral System namespace and the Microsoft-specific (and aptly named) Microsoft namespace. Table 1-2 shows a brief subset of the namespaces that the average Managed C++ programmer will run into.

Table 1-2: Common .NET Framework Class Library Namespaces

NAMESPACE	DESCRIPTION
Microsoft::Win32	Contains classes to handle events raised by the operating system and to manipulate the system registry
System	Contains classes that handle primitive types, mathematics, program invocation, and supervision of applications
System::Collections	Contains classes that define collections of objects, such as lists, queues, arrays, hashtables, and dictionaries
System::Data	Contains classes that handle database access
System::Data::OleDb	Contains classes that handle access to OLE DB databases
System::Data::SqlClient	Contains classes that handle access to Microsoft SQL Server databases
System::Diagnostics	Contains classes that allow you to debug your application and trace application execution
System::DirectoryServices	Contains classes to access Active Directory
System::Drawing	Contains classes to handle the GDI+ graphics functionality
System::Drawing::Drawing2D	Contains classes that handle advanced two-dimensional and vector graphics functionality
System::Drawing:Imaging	Contains classes to handle advanced GDI+ imaging functionality
System::Drawing::Printing	Contains classes to handle custom printing
System::Globalization	Contains classes that define culture-related information, such as language, currency, and numbers
System::IO	Contains classes to handle reading and writing of data streams and files
System::Net	Contains classes to handle many of the protocols and services found on networks
System::Reflection	Contains classes that examine loaded types, methods, and fields, and also dynamically create and invoke types
System::Resources	Contains classes to create, store, and manage various culture-specific resources
System::Runtime::InteropServices	Contains classes to access COM objects and native APIs
System::Runtime::Remoting	Contains classes to create and configure distributed applications
System::Security	Contains classes to handle the CLR security system
System::Threading	Contains classes to handle multithreaded programming
System::Web	Contains classes to handle browser/server communication
System::Web::Mail	Contains classes to create and send an e-mail using the SMTP mail service built into Microsoft Windows 2000
System::Web::Security	Contains classes to handle ASP.NET security in Web applications
System::Web::Services	Contains classes to build and use Web services
System::Web::UI	Contains classes to create controls and pages in Web applications
System::Windows::Forms	Contains classes to create Windows-based applications
System::XML	Contains classes to handle XML