Configuration with Configuration Namespaces

The .NET Framework offers a set of namespaces referred to as the configuration namespaces (seriously). Literally, the grouping is called "the configuration namespaces." This distinguished namespace grouping includes the following:

• System.Configuration

• System.Configuration.Assemblies

• System.Configuration.Install

From this grouping, you will focus on the System.Configuration namespace. As for the other two configuration namespaces, I provide a brief (very brief) intro duction in two later sections. First, you will dig into the System.Configuration namespace.

Using the System.Configuration Namespace

About seven classes (and one interface) are contained in this namespace. I will only mention and demonstrate one of them: ConfigurationSettings or, rather, the System.Configuration.ConfigurationSettings class. The ConfigurationSettings class has one property ( AppSettings ) and one method ( GetConfig ).

You can use the GetConfig method to retrieve values from the <appSettings></appSettings> child element. However, a more typical use of the GetConfig method is to retrieve values from "any" user -defined configuration settings area. For example, if you were to create your own version of the <appSettings></appSettings> child element using a different name , you would use the GetConfig method to retrieve your configuration settings.

As I have not found the need for other user-defined configuration settings, I have yet to find a need to use the GetConfig method. The AppSettings property of the ConfigurationSettings class has worked well for me. The AppSettings property is my choice to read the configuration settings previously stored in the <appSettings></appSettings> child element in the respective config files.

Let's now return to the sample code (MyEnhancedInformativeWinFormCobol and MyEnhancedInformativeWinFormVB) to review the implementation and use of the AppSettings property of the System.Configuration.ConfigurationSettings class. As you can see from the following code snippets, the database connection string information is being retrieved from the respective config files.

Here's the original hard-coded VB .NET code (using the "hard-coded" approach) from the MyInformativeWinFormVB sample project:

 . . . mySqlConnection.ConnectionString = _ "user id=sa;pwd=;Database=northwind;Server=(LOCAL)" . . . 

Next is the updated VB .NET sample code (using a preferred configuration technique) from the MyEnhancedInformativeWinFormVB sample project:

 . . . Dim myConn As String = _ System.Configuration.ConfigurationSettings.AppSettings("MyVBConnectionString") mySqlConnection.ConnectionString = myConn . . . 

The following is the original hard-coded COBOL .NET code (using the "hard-coded" approach) from the MyInformativeWinFormCobol sample project:

 . . . 019970 SET PROP-ConnectionString OF mySqlConnection TO 019980 "user id=sa;pwd=;Database=northwind;Server=(LOCAL)" . . . 

Here's the updated COBOL .NET sample code (using a preferred configuration technique) from the MyEnhancedInformativeWinFormCobol sample project:

 . . . 000413    CLASS CLASS-NAMEVALUECOLLECTION AS  000414          "System.Collections.Specialized.NameValueCollection" 000416    CLASS CLASS-CONFIGURATIONSETTINGS AS  000417          "System.Configuration.ConfigurationSettings" 000418    PROPERTY PROP-APPSETTINGS AS "AppSettings" . . . 019211 WORKING-STORAGE SECTION. 019212 01 MyNewConnectionString PIC X(100). 019213 01 MyNewAppSettings OBJECT REFERENCE CLASS-NAMEVALUECOLLECTION.  . . . 019983    SET MyNewAppSettings TO PROP-APPSETTINGS  019984        OF CLASS-CONFIGURATIONSETTINGS 019985    INVOKE MyNewAppSettings "get_Item"  019986        USING BY VALUE "MyCOBOLConnectionString"  019987        RETURNING MyNewConnectionString 019988    SET PROP-ConnectionString OF mySqlConnection  019989        TO MyNewConnectionString  . . . 

As shown in the preceding VB .NET and COBOL .NET demonstration code, it really is easy to break the old hard-coding habit. Using the XML-based configu ration files (App.config, Machine.config, and Web.config for ASP.NET applications), your application configuration options now include a more modern, maintainable technique.

As previously mentioned, the following two sections provide a brief introduction to the "other" configuration namespaces.

Understanding System.Configuration.Assemblies

Generally speaking, this namespace contains classes used for protecting the integrity of your assembly and for assisting in your version configuration needs. Simply, the namespace contains one structure and two enumerations:

• AssemblyHash structure

• AssemblyHashAlgorithm enumeration

• AssemblyVersionCompatibility enumeration

The AssemblyHash structure is basically a "hash" value of the contents found in your assembly manifest (recall the discussion in the section "Extending Assembly Metadata with Custom Attributes" regarding the assembly manifest). The AssemblyHash structure has an Algorithm property that uses the Assembly- HashAlgorithm enumeration.

The term "hash algorithm" looks familiar, right? Earlier, when you were using the ILDASM tool, you may have noticed the ".hash algorithm" value listed in the assembly manifest (see Figure 18-9).

Figure 18-9: The ILDASM tool provides the ability to view the .hash algorithm value while viewing the assembly manifest

You also use the AssemblyHashAlgorithm enumeration to get or set the chosen hash algorithm, which is then used for generating strong names (using the Sn.exe utility).

You can use the AssemblyVersionCompatibility enumeration for versioning configuration. With this class, you can restrict the side-by-side capabilities of your assembly to not be able to execute with other assemblies based on same domain, same machine, or same process specifications.

Understanding System.Configuration.Install

Going down the path in pursuit of this particular configuration namespace, you will open up an entire new world. In short, this namespace provides classes, dele gates, and enumerations that enable the building of custom installers .    

Other than being relevant to software vendors , the System.Configuration.Install namespace is also of interest to a special group of developers. This special group of developers includes those who specialize in an area of software development known as Windows Management Instrumentation (WMI). The System.Configuration.Install namespace provides support for WMI development.

WMI development (using the .NET managed namespaces System.Management and System.Management.Instrumentation ) involves the cre ation of system-type software (as opposed to business-type software). You can think of WMI applications as being similar to the set of Windows tools (e.g., the various MMC snap-ins). WMI applications provide interfaces to access man agement information for the Windows operating system, hardware devices, and applications.

As I mentioned, pursuit of the System.Configuration.Install namespace will lead you down a long path into another development world. This world includes the topic of WMI. As your needs dictate , feel free to continue your journey down that path.

Cross-Reference  

An entire book has been written on the topic of WMI. Additionally, several Web sites provide information on WMI. Please refer to the "To Learn More" section at the end of this chapter for these related references.

For this chapter's purposes, you will remain on the path of configuration. The next stop for you on the configuration path is code access security.