第 115 页

</system.net>

</configuration>

section: cryptographysettings

Although the .NET Framework contains base implementations for a number of cryptographic

algorithms, such as the hashing function, sometimes it is necessary to override these algorithms.

When this is required, the cryptographySettings section of the configuration file can be included

to remap existing algorithm names, or map new names, to another implementation class.

section: system diagnostics

Debugging is always the hardest part of writing an application. It is made even more difficult when

the application is in production and the error cannot be replicated in the debugging environment. One

technique that is particularly important for debugging this type of error is to use trace statements:

Trace.WriteLine("The application made it this far before crashing.")

Both trace and debug statements work very similarly to events and event handlers. For the preceding

WriteLine statement to have any effect, an object must be listening for this WriteLine. This is

typically done by a TraceListener class. The framework supports a number of default trace listeners

that can be wired up to the application via the diagnostics section of the configuration file, as shown

in the following section in which an EventLog trace listener has been attached to the application:

<configuration>

<system.diagnostics>

<trace autoflush="true" indentsize="0">

<listeners>

<add name="MyEventListener"

type="System.Diagnostics.EventLogTraceListener, system,

version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

initializeData="DeveloperApplicationEventLog"/>

</listeners>

</trace>

</system.diagnostics>

</configuration>

The initializeData attribute specifies a text string to be passed into the constructor for the trace

listener. In the case of the event-log listener, this text corresponds to the name of the event log into

which trace statements will be inserted.

Other elements can also be added to the diagnostics section of the configuration file — for example,

to determine the level of trace logging to perform, which will determine how verbose the trace

messages are; or to control whether or not the debug assertion dialog is displayed for an application.

section: system web

The system.web section of the configuration file is used to control how web applications behave.

This is the section that can have quite a deep hierarchy, because configuration settings can be

780 .

chaPter 36 conFigurATion FileS

specified on a machine, web server, web site, web application, or even subfolder basis. Because this

section controls the security requirements for a web application, it is often used to restrict access to

certain areas of the web application.

webservices

Although web service applications use several configuration settings, such as authentication and

impersonation sections, the system.web section of the configuration file contains some settings

that are particular to the way that web services operate. For example, the following code snippet

enables the use of SOAP and Documentation protocols, but removes the POST and GET protocols for

the application:

<configuration>

<system.web>

<webServices>

<protocols>

<add name="HttpSoap"/>

<remove name="HttpPost"/>

<remove name="HttpGet"/>

<add name="Documentation"/>

</protocols>

</webServices>

</system.web>

</configuration>

By default, only SOAP and Documentation are enabled for web services. Quite often, for debugging

purposes, it is convenient to allow the POST protocol so that the web service can be tested via a

web browser. You should do this on an application basis by including the appropriate section in the

configuration file within the application folder.

section: compiler

The compiler section of the configuration file is used to list the compilers installed on a computer.

The following snippet shows how the VB.NET compiler is referenced in the machine.config file.

Within an application, this information can be accessed via the CodeDomProvider framework class.

<configuration>

<system.codedom>

<compilers>

<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"

type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0,

Culture=neutral, PublicKeyToken=b77a5c561934e089" />

</compilers>

</system.codedom>

</configuration>

configuration attributes

All configuration elements can specify a configSource, which is simply a redirection to a separate

file. This can be useful if a configuration file becomes unwieldy in length. The following code

Configuration schema .

781

snippet illustrates how a section of a configuration file can be extracted and subsequently referenced

by means of this attribute:

<!—Original Configuration File—>

<configuration>

.

<WindowsApplication1.My.MySettings>

<setting name="Button1_Text" serializeAs="String">

<value>Press Me!</value>

</setting>

</WindowsApplication1.My.MySettings>

</configuration>

<!—Reduced Configuration File using configSource—>

<configuration>

.

<WindowsApplication1.My.MySettings configSource="MySettings.Config" />

</configuration>

<!—Code from MySettings.Config—>

<WindowsApplication1.My.MySettings>

<setting name="Button1_Text" serializeAs="String">

<value>Press Me!</value>

</setting>

</WindowsApplication1.My.MySettings>

Note a couple of limitations to using a configSource:

.

There is no merging of configuration sections between the referenced file and the original

configuration file. If you include the section in both files, a configuration error will be

generated when you attempt to run the application.

.

This attribute cannot be applied to configuration section groups. This can be a significant

limitation, because the purpose of a section group is to group items that relate similar

configuration sections. A logical separation could see all items in a particular section group

in a separate configuration file.

.

If the attribute is used within a web.config file, changing the referenced configuration file

will not restart the ASP.NET application. In order for the configuration information to

be reread, you need to either manually restart the ASP.NET application or modify the

web.config file itself.

Each element within the configuration file inherits a number of attributes that can be set to control

whether or not that element can be overridden. To prevent an element, or even an entire section,

from being overridden, you can lock it. Five different locking attributes (outlined in Table 36-1) can

be used to specify any number of configuration attributes and elements that are to be locked.

Being able to lock configuration items is particularly relevant when you’re dealing with

web applications, which might contain a deep hierarchy of configuration inheritance. Windows

applications inherit only from the machine.config file, so it is unlikely that you will need to

lock items.

782 .

chaPter 36 conFigurATion FileS

table 36-1: Locking Attributes

LockItem

Locks the element to which this attribute is applied, including all

other attributes provided on that element and all child elements

LockAttributes

Locks the comma-delimited list of attributes provided

LockAllAttributesExcept

Locks all attributes except those provided in the comma-

delimited list

LockElements

Locks the comma-delimited list of child elements provided

LockAllElementsExcept

Locks all child elements except those provided in the comma-

delimited list

confiGuration eleMent descriPtion

aPPlication settinGs

Applications frequently have settings that do not fit into the default configuration schema. The four

mechanisms for storing this information are discussed in the following sections.

using appsettings

The first technique is to use the predefined appSettings section of the configuration file. This

section can be used to store simple name-value pairs of application settings, which might be useful

for storing the name of the server, as in the following example:

<configuration>

<appSettings>

<add key="Server" value="http://www.builttoroam.com"/>

</appSettings>

</configuration>

This value can easily be accessed within code by means of the AppSettings property of the

ConfigurationManager class (which requires a reference to the System.Configuration

assembly):

Vb

Dim server As String = ConfigurationManager.AppSettings("Server")

c#

var server = ConfigurationManager.AppSettings["Server"];

application settings .

783

One of the weaknesses of this approach is that the name of the setting is specified as a string, rather

than as a strongly typed property. It also assumes that the value will be a string, which is often not

the case.

In the case of web applications, you should use the WebConfigurationManager

class instead of the ConfigurationManager class because it provides access to

additional configuration information specific to ASP.NET applications.

Project settings

Using the Settings tab of the project properties designer, you can defi ne application settings of

a variety of types. Figure 36 - 1 illustrates how the PrimaryServer setting would appear in this

designer.

fiGure 36-1

Adding application settings via this designer does not use the appSettings section as you might

expect. Instead, it defines a new section in the configuration, as discussed earlier in the section on

the configSection element and shown in the following snippet:

< configuration >

...

< ConfigurationApplication.My.MySettings >

< setting name="PrimaryServer" serializeAs="String" >

< value > www.builttoroam.com < /value >

< /setting >

< /ConfigurationApplication.My.MySettings >

< /configuration >

784 .

chaPter 36 conFigurATion FileS

To access this setting in code, you can make use of the generated strongly typed access properties.

Vb

Dim primaryServer as String = My.Settings.PrimaryServer

c#

string primaryServer = Properties.Settings.Default.PrimaryServer;

dynamic Properties

The third mechanism for storing application-specific information is the use of dynamic properties.

These are typically used to dynamically set designer properties. For example, you could set the text

on a Button1 using the following configuration block:

<configuration>

...

<applicationSettings>

<ConfigurationApplication.My.MySettings>

<setting name="Button1_Text" serializeAs="String">

<value>Press Me Now!</value>

</setting>

</ConfigurationApplication.My.MySettings>

</applicationSettings>

</configuration>

You will note that the preceding code uses the same syntax as application settings defined using the

project properties designer. In fact, they are one and the same, the only difference being that in

the InitializeComponent method of the form there is a line of code that sets the button text:

Vb

Me.Button1.Size =

Global.ConfigurationApplication.My.MySettings.Default.Button1_Size

c#

this.button1.Size =

global::ConfigurationApplication.Properties.Settings.

Default.Button1_Size;

When this application is deployed, the text displayed on Button1 is dynamically loaded from the

configuration file. In the following steps, for example, you set the size of a control, Button1, to be

dynamically loaded from the configuration file:

1 Select Button1 on the designer surface and press F4 to display the Properties window.

Locate the ApplicationSettings item within the Data category or in the alphabetic list,

as shown in Figure 36-2.

2 Click the ellipsis button (. . .) next to the PropertyBinding row. This opens a dialog that

lists the available properties for Button1, along with any application settings that have been

assigned, as shown in Figure 36-3.

application settings .

785

fiGure 36-2 fiGure 36-3

3 Select the drop-down next to the Size property

and select New. This opens a dialog in which

you can specify a default value, a name for the

application setting, and the scope of the setting.

4 Specify a name for the application setting — for

example, Button1_Size, and set the scope to

Application. You can modify the default value or

simply accept the value that has been extracted

from the current properties of Button1, as shown

in Figure 36-4. fiGure 36-4

5 Click OK on both dialogs. If you open the app.config file that will be available from the

Solution Explorer window, you will see a section that defines the Button1_Size setting.

custom configuration sections

Developers often want to include more structured information in the configuration file than can

be stored in the appSettings section. To solve this problem and eliminate any need for additional

configuration files, you can create a custom configuration section. The new configuration section

must be defined at the top of the configuration file via the configSection element, complete with a

reference to a class that should be used to process that portion of the configuration file.

In the past this process was fairly complex, because the class needed to implement the

IConfigurationSectionHandler interface. This exposed a simple method, Create, which was called

the first time that section was referenced in code. There was little support from the framework to