Types that access the Windows Registry and provide access to system events (such as low memory, changed display settings, and user logout).
System
Core system types, including:
- Implementations for Visual Basic .NET's fundamental types.
- Common custom attributes used throughout the .NET Framework class library as well as the Attribute class, which is the base class for most (although not all) custom attributes in .NET applications.
- Common exceptions used throughout the .NET Framework class library as well as the Exception class, which is the base class for all exceptions in .NET applications.
- The Array class, which is the base class from which all Visual Basic .NET arrays implicitly inherit.
- The Convert class, which contains methods for converting values between various types.
- The Enum class, from which all enumerations implicitly derive.
- The Delegate class, from which all delegates implicitly derive.
- The Math class, which has many shared methods for performing common mathematical functions (e.g., Abs, Min, Max, Sin, and Cos). This class also defines two constant fields, E and PI, that give the values of the numbers e and pi, respectively, within the precision of the Double data type.
- The Random class, for generating pseudorandom numbers.
- The Version class, which encapsulates version information for .NET assemblies.
System.CodeDom
Types for automatically generating source code (used by tools such as the wizards in Visual Studio .NET and by the ASP.NET page compiler).
System.Collections
Types for managing collections, including:
ArrayList
Indexed like a single-dimensional array and iterated like an array, but much more flexible than an array. With an ArrayList, it is possible to add elements without having to worry about the size of the list (the list grows automatically as needed), insert and remove elements anywhere in the list, find an element's index given its value, and sort the elements in the list.
BitArray
Represents an array of bits. Each element can have a value of True or False. The BitArray class defines a number of bitwise operators that operate on the entire array at once.
Hashtable
Represents a collection of key/value pairs. Both the key and value can be any object.
Queue
Represents a queue, which is a first-in-first-out (FIFO) list.
SortedList
Like a Hashtable, represents a collection of key/value pairs. When enumerated, however, the items are returned in sorted key order. In addition, items can be retrieved by index, which the Hashtable cannot do. Not surprisingly, SortedList operations can be slower than comparable Hashtable operations because of the increased work that must be done to keep the structure in sorted order.
Stack
Represents a stack, which is a last-in-first-out (LIFO) list. Be aware that in addition to these types, there is also the Array type, defined in the System namespace, and the Collection type, defined in the Microsoft.VisualBasic namespace. The latter is a collection type that mimics the behavior of Visual Basic 6 collection objects.
System.ComponentModel
Support for building components that can be added to Windows Forms and Web Forms.
System.Configuration
Support for reading and writing program configuration.
System.Data
Support for data access. The types in this namespace constitute ADO.NET.
System.Diagnostics
Support for debugging and tracing.
System.Drawing
Graphics-drawing support.
System.EnterpriseServices
Transaction-processing support.
System.Globalization
Internationalization support.
System.IO
Support for reading and writing streams and files.
System.Net
Support for communicating over networks, including the Internet.
System.Reflection
Support for runtime type discovery.
System.Resources
Support for reading and writing program resources.
System.Security
Support for accessing and manipulating security information.
System.ServiceProcess
Types for implementing system services.
System.Text
Types for manipulating text and strings.
Note in particular the StringBuilder type. When strings are built from smaller parts, the methods on the StringBuilder class are more efficient than similar methods on the String class. This is because the instances of the String class can't be modified in place; every time a change is made to a String object, a new String object is actually created to hold the new value. In contrast, the methods in StringBuilder that modify the string actually modify the string in place.
System.Threading
Support for multithreaded programming.
System.Timers
Provides the Timer class, which can generate an event at predetermined intervals. This addresses one of the limitations of the Visual Basic 6 Timer control: it had to be hosted in a container and therefore could be used only in an application with a user interface.
System.Web
Support for building web applications. The types in this namespace constitute Web Forms and ASP.NET.
System.Windows.Forms
Support for building GUI (fat client) applications. The types in this namespace constitute Windows Forms.
System.Xml
Support for parsing, generating, transmitting, and receiving XML.
Configuration
System and application configuration is managed by XML files with a .config extension. Configuration files exist at both the machine and application level. There is a single machine-level configuration file, located at runtime_install_path\CONFIG\machine.config. For example, C:\WINNT\Microsoft.NET\Framework\v1.0.2914\CONFIG\machine.config. Application-configuration files are optional. When they exist, they reside in the application's root folder and are named application_file_name.config. For example, myApplication.exe.config. Web applicationconfiguration files are always named web.config. They can exist in the web application's root folder and in subfolders of the application. Settings in subfolders' configuration files apply only to pages retrieved from the same folder and its child folders and override settings from configuration files in higher-level folders.
Configuration files should be used for all application-configuration information; the Windows Registry should no longer be used for application settings.
Configuration File Format
Configuration files are XML documents, where the root element is <configuration>. For example:
To be as flexible as possible, .NET configuration files use a scheme in which the application developer can decide on the names of the subelements within the <configuration> element. This is done using the <configSections>, <section>, and <sectionGroup> elements. Example 3-2 shows how this is done using the <configSections> and <section> elements; the <sectionGroup> element is discussed later in this section.
Example 3-2. Defining a section in a configuration file
The name attribute of the <section> element specifies the name of an element that will (or could) appear later in the file. The type attribute specifies the name of a configuration section handler, which is a class that knows how to read an XML section that's formatted in a particular way. The .NET Framework provides stock configuration section handlers (notably the SingleTagSectionHandler and the NameValueSectionHandler classes, both of which will be discussed later in this section), which are sufficient for the majority of cases. Although it's beyond the scope of this book, a custom configuration section handler can be created by writing a class that implements the IConfigurationSectionHandler interface.
The SingleTagSectionHandler configuration section handler reads XML sections that are of the form:
The element can contain any number of key/value pairs.
The configuration section handler class is not used directly in code. To read information from an application's configuration file, use the GetConfig method in the ConfigurationSettings class (defined in the System.Configuration namespace). The syntax of the GetConfig method is:
Here's how the mechanism works (an example will follow):
- The application calls the GetConfig method, passing it the name of the configuration section that is to be read.
- Internally, the GetConfig method instantiates the configuration section handler class that is appropriate for reading that section. (Recall that it is the values found in the <configSections> portion of the configuration file that identify the appropriate configuration section handler class to use.)
- The Create method of the configuration section handler is called and is passed the XML from the requested configuration section.
- The configuration section handler's Create method returns an object containing the values read from the configuration section.
- The object returned from the Create method is passed back to the caller of the GetConfig method.
The type of object returned from GetConfig is determined by the specific configuration section handler that handles the given configuration section. The caller of the GetConfig method must have enough information about the configuration section handler to know how to use the object that is returned. Two stock configuration section handlers—and the objects they create—will be discussed in this section. Example 3-3 shows how to read the configuration file shown in Example 3-2. To run this example, do the following:
- Create a new directory for the application.
- Save the code from Example 3-3 into a file named ConfigurationTest.vb.
- Compile the code with this command line: The reference to the System assembly is required because the System assembly contains the definition of the ConfigurationSettings class. The compiler creates an executable file named ConfigurationTest.exe.
- Save the configuration file from Example 3-2 into a file named ConfigurationTest.exe.config. Run the executable from the command prompt. The application prints the configuration values to the command window.
Example 3-3. Reading the configuration file shown in Example 3-2
To read the configuration settings, the code in Example 3-3 calls the GetConfig method of the ConfigurationSettings class. The SingleTagSectionHandler configuration section handler creates a Hashtable object (defined in the System.Collections namespace) to hold the key/value pairs found in the configuration file. That is why the code in Example 3-3 calls the CType function to convert the reference returned by the GetConfig method to a Hashtable reference. After that is done, the code can do anything appropriate for a Hashtable object, including retrieving specific values by key (as shown in Example 3-3) or iterating through the Hashtable object's items. Also note that because Hashtable objects store values of type Object, the object references retrieved from the Hashtable have to be converted to the appropriate reference type, which in this case is String. The Visual Basic CStr function could have been used here, although in this case the Visual Basic CType function is called instead.
The application does not specify the name of the configuration file in which to look for the configuration information. The system automatically looks in the application_file_name.config file found in the application's directory. If the requested section is not found in that file, the system automatically looks for it in the machine-configuration file.
Another stock configuration section handler is the NameValueSectionHandler class. This handler also reads key/value pairs, but in a different format. Example 3-4 is the same as Example 3-2, but rewritten to use NameValueSectionHandler.
Example 3-4. Using the NameValueSectionHandler configuration section handler
Example 3-5 shows the code that reads this configuration section.
Example 3-5. Reading the configuration file shown in Example 3-4
The main difference to note in Example 3-5 is that the NameValueSectionHandler creates an object of type NameValueCollection (defined in the System.Collections.Specialized namespace).
Configuration Section Groups
If application-configuration information is to be stored in the machine-configuration file, it is a good idea to introduce configuration section groups into the picture. (Recall that if the runtime doesn't find the requested section in the application-configuration file, it automatically looks for it in the machineconfiguration file.) This simply groups an application's settings into an enclosing group element in the configuration file, so that the contained elements won't potentially conflict with like-named elements for other applications. Example 3-6 shows how to introduce a section group. It is identical to the configuration file shown in Example 3-2, except that a section group is defined.
Example 3-6. Creating a section group
Example 3-7 shows how to read this configuration file in code.
Example 3-7. Reading the configuration file shown in Example 3-6
The only difference between Example 3-7 and Example 3-3 is the path-style syntax in Example 3-7 used to specify the section name: "myGroupName/mySectionName". Group definitions can be nested, if desired.
The <appSettings> Section
Most applications just need a simple way to store key/value pairs. To support this, the machine.config
file contains a predefined section definition called <appSettings>. It is always legal to include an
<appSettings> section in any configuration file. The configuration section handler for the
<appSettings> section is the NameValueSectionHandler class, so the section should be in this form:
Although the <appSettings> section can be read using the GetConfig method just like any other section, the ConfigurationSettings class has a property that is specifically intended to assist with reading the <appSettings> section. The read-only AppSettings property of the ConfigurationSettings class returns a NameValueCollection object that contains the key/value pairs found in the <appSettings> section. Example 3-8 shows how to read the settings shown in the previous code listing.
Example 3-8. Reading the <appSettings> section
The name/value pairs in the <appSettings> section are developer-defined. The CLR doesn't attribute any intrinsic meaning to any particular name/value pair.
No comments:
Post a Comment