If you have browsed through online documentation for the .NET Framework, you've noticed that it is organized hierarchically. This is similar to the way the MFC library is organized; however, the organization of the .NET Framework is not entirely based on class derivation as it is with the MFC library.
The .NET Framework organization begins with the top-level namespaces System and Microsoft, which contain other namespaces, classes, value types, interfaces, delegates, and enumerations. The use of namespaces provides organization of related code elements without the use of derivation. For example, the System::Windows::Forms namespace contains the Form class, which implements the Windows Form, as well as the control classes to use with Windows Forms. This use of namespaces is used throughout the .NET Framework.
The System namespace is the root namespace for the majority of the .NET Framework. It includes all classes and structures that represent the base value types, such as Array, Byte, Object, Int32, String, and so on. It also contains other namespaces that contain classes for Windows Forms, network communications, file I/O, threads, and so on.
Additionally, the System namespace includes other classes to deal with system-level functionality. It also contains other miscellaneous value types or structures, delegates for handling events, The System namespace is the root namespace for the majority of the .NET Framework. some commonly used enumerations, and interface definitions.
Applications can use the The System namespace is the root namespace for the majority of the .NET Framework. classes and structures that provide the basic type support in all .NET applications directly or they can use their native types, which are mapped to the .NET Framework types when compiled. Having the value types defined in the .NET Framework provides a common base that all .NET languages use so they can work with each other without problems missing data types.
When you write managed .NET code in Visual C++ .NET, you can mix and match the usage of the .NET types and the native C++ types; however, it is better to choose one or the other and stick with it for clarity. Table 4.1 lists the .NET value types within the System namespace that represent native C++ types.
|C++ Type||.NET Framework Value Type|
There are other value types, including Decimal, Object, IntPtr, UIntPtr, and String, that don't have native C++ alternatives and are therefore used directly whichever direction you choose for your applications.
The System namespace includes classes for dealing with arrays, system status, controlling the application, and so on. There are too many classes to cover in this hour's lesson. However, you can always refer to online help for a list of classes that are within a namespace the help is organized by namespaces, which makes it easy to find what you need.
There are also delegate definitions within the System namespace to handle events. The most commonly used of those delegates is the EventHandler delegate. Additionally there are also delegate definitions for asynchronous operations and unhandled exceptions.
Enumerations within the System namespace include DayOfWeek, PlatformID, TypeCode, and other global enumerations. These enumerations can be used anywhere within managed code.
Additionally, the System namespace includes interface definitions and other namespaces that also include classes, structures, interfaces, enumerations, and delegates. For more information on the namespace hierarchy, refer to the reference included with this book or the online help shipped with Visual Studio .NET.
The Microsoft namespace includes other namespaces that are related directly to Microsoft's languages and some Win32 features. The Microsoft namespace isn't as vast and encompassing as the System namespace; in fact, it doesn't directly have any classes.
The Microsoft namespace includes other namespaces for specific support of Microsoft's languages, such as CSharp, JScript, VisualBasic, and VSA (Visual Studio for Applications). There isn't much use for these namespaces unless you are trying to compile source code, in which case these namespaces give you access to the compilers.
The other Microsoft namespace is Win32. This namespace is more useful and gives you access to the Registry and system-level events. For the most part, a .NET application shouldn't use the Registry to store information, but you may find it necessary to retrieve information from the Registry when dealing with legacy applications.
Overall, it is possible to write applications for the .NET Framework and never have a need for the classes found within the Microsoft namespaces.