Professional ASP.NET 1.1 [Electronic resources] نسخه متنی

Advanced Topics

Here, we will cover three advanced topics related to ASP.NET configuration:

Specifying location.

Locking down configuration settings.

Building a custom configuration handler.

Specifying the Location

In all the examples discussed in this chapter, we have either used the

machine.config file to configure settings for the entire server or the

web.config file to configure settings for an individual application.

Another option not discussed previously, is to use a

<location> element within a configuration file. Using the

<location> element, you can specify application-specific settings in

machine.config for different applications on our server, rather than creating a web.config file.

For example, if you have a virtual directory named

Wrox accessible as

http://localhost/Wrox/ , and that virtual directory is marked as an application, you could make the following entry in

machine.config to configure

Session settings for all applications as well as

Session settings specific to the

Wrox application:

<configuration>
<system.web>
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1; user id=sa;password="
cookieless="false"
timeout="20"
/>
</system.web>
<location path="Default Web Site/Wrox"> 
<system.web> 
<sessionState 
mode="StateServer" 
stateConnectionString="tcpip=127.0.0.1:42424" 
sqlConnectionString="data source=127.0.0.1; user id=sa;password=" 
cookieless="true" 
timeout="10" 
/> 
</system.web> 
</location> 
</configuration>

In this snippet from

machine.config , we have specified a default setting for all applications, and have also provided the settings specific to the

Wrox application using the

<location> element.

Setting the Path

The

<location> element requires that you define a path. If a path is not provided, or the path value is set to an empty string, the settings are applied as normal. In the preceding example, it would be an error to define

<location path="> . This would cause

machine.config to have two conflicting settings for

<sessionState> .

In addition to using

<location> to define settings for your application, you can also lock down application configuration settings through the use of

<location> .

Locking Down Configuration Settings

ASP.NET's configuration system is very flexible. For your applications, you can simply create a

web.config file specifying the desired configuration options, and the application will behave appropriately.

However, in some cases, as in a hosted environment, you may want to limit the configuration options a particular application is allowed to control. For example, you may decide that some applications cannot change the settings for

Session state. There are two options for locking down configuration settings:

Use the

<location> allowOverride attribute.

Use the

allowDefinition attribute on the configuration section handler.

Let's look at both of these.

Locking Down via <location>

In addition to supporting a

path attribute, you can additionally specify an

allowOverride attribute in the

<location> tag. The usage of

allowOverride is:

<location path="[site description]/[application path]" 
allowOverride="[true|false]"> 

Let's look at an example to clarify the use. You could define the following in the

machine.config file:

<configuration>
...
<location path="Default Web Site/Wrox" allowOverride="true"> 
<system.web> 
<sessionState 
mode="StateServer" 
stateConnectionString="tcpip=127.0.0.1:42424" 
sqlConnectionString="data source=127.0.0.1; user id=sa;password=" 
cookieless="true" 
timeout="10" 
/> 
</system.web> 
</location> 
</configuration>

Within the

Wrox application, you could then define a

web.config file that provides session state settings, overriding the settings inherited from

machine.config 's

<location> settings:

<configuration>
<system.web> 
<sessionState 
mode="InProc" 
stateConnectionString="tcpip=127.0.0.1:42424" 
sqlConnectionString="data source=127.0.0.1; user id=sa;password=" 
cookieless="false" 
timeout="20" 
/> 
</system.web> 
</configuration>

However, if in

machine.config you set

allowOverride="false" in the

<location> settings for

Wrox , a

web.config file for the

Wrox application that attempted to set

<sessionState> settings would result in an exception. The application is effectively prevented from 'redefining' the settings for

<sessionState> configured by the administrator in

machine.config .

Using the

allowOverride attribute of

<location> allows the administrator to control the default settings of a given application, as well as whether that application can change those settings in a

web.config file. If the default inherited settings from

machine.config are acceptable, you can also lock down using the attributes on the configuration section handler.

Locking Down via Configuration Section Handler

If the settings specified in

machine.config are acceptable defaults, and you don't want those settings changed by applications that inherit those settings, you can use the optional

allowDefinition attribute on the configuration section handler.

Let's look at an example. The following values are taken from

machine.config for the

sessionState section handler as well as the

<sessionState> settings. The section handler is highlighted:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
<configSections>
<sectionGroup name="system.web">
<section name="sessionState" 
type="System.Web.SessionState.SessionStateSectionHandler", 
System.Web 
/> 
</sectionGroup>
...
</configSections>
...
<system.web>
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;
user id=sa;password="
cookieless="false"
timeout="20"
/>
</system.web>
</configuration>

In this configuration, applications can use a

web.config file to redefine the configuration settings for

<sessionState> . To restrict this, you could use the

allowDefinition attribute on the section handler:

<section name="sessionState"
type="System.Web.SessionState.SessionStateSectionHandler,
System.Web"
allowDefinition="MachineOnly" 
/>

Applications that use a

web.config file attempting to change

<sessionState> settings will now receive an error message, and will be prevented from defining

<sessionState> settings, just as was done with

<location> .

The

allowDefinition attribute has three acceptable settings:

Everywhere :Settings for the section handler can be declared in

machine.config or within a

web.config file. The

web.config file may or may not reside within a directory marked as an application.

MachineOnly :Settings for the section handler can be declared only by the

machine.config file and cannot be overridden in a

web.config file.

MachineToApplication :Settings for the section handler can be declared in either

machine.config or a

web.config file residing within a directory marked as an application.

If

allowDefinition is absent, the default setting is

allowDefinition="Everywhere" .

Custom Configuration Handler

Earlier in the chapter, we discussed the use of

<appSettings> for storing our own configuration data. This allowed us to store simple key/value data in the configuration file and later access it through configuration APIs.

While

<appSettings> is definitely useful, in some cases you might want to add more complex configuration data. For this, you can create your own configuration section handler that can read configuration settings. A custom configuration section handler is simply a class that implements the

IConfigurationSectionHandler interface.

The

IConfigurationSectionHandler interface has one method that we are required to implement:

object Create(object parent, object configContext, XmlNode section) 

Let's write a simple example of a configuration section handler.

Simple Configuration Handler

Let's say you want to provide all pages with a default background color. You also want to store the default value in the configuration system. Instead of using

<appSettings> to accomplish this (you could easily use it for this example), you decide to write your own configuration handler.

The following code snippet shows the C# code for the configuration section handler:

using System; 
using System.Collections; 
using System.Xml; 
using System.Configuration; 
using System.Web.Configuration; 
 
namespace Wrox { 
internal class PagePropertiesHandler : IConfigurationSectionHandler { 
public virtual object Create(Object parent, 
Object context, 
XmlNode node) { 
PagePropertiesConfig config; 
config = new PagePropertiesConfig((PagePropertiesConfig)parent); 
config.LoadValuesFromConfigurationXml(node); 
return config; 
} 
} 
 
public class PagePropertiesConfig { 
string _backColor; 
internal PagePropertiesConfig(PagePropertiesConfig parent) { 
if (parent != null) 
_backColor = parent._backColor; 
} 
internal void LoadValuesFromConfigurationXml(XmlNode node) { 
Exception error = null; 
XmlAttributeCollection attributeCollection = node.Attributes; 
_backColor = attributeCollection["backColor"].Value; 
} 
 
public string BackColor{ 
get {return _backColor;} 
} 
} 
} 

In this code, we have implemented a

PagePropertiesHandler class that implements

IConfigurationSectionHandler 's

Create method. We use a public class called

PagePropertiesConfig to retrieve and store the values from the configuration settings.

When this handler is created, it will pass in the

XmlNode node value, and call

LoadValuesFromConfigurationXml to load the

backColor setting.

After compiling the source file and deploying it to the application's

bin directory, the following

web.config file can be written to use this configuration section handler:

<configuration>
<configSections>
<sectionGroup name="system.web">
<section name="pageProperties" 
type="Wrox.PagePropertiesHandler, PageProperties" /> 
</sectionGroup>
</configSections>
<system.web>
<pageProperties backColor="blue" /> 
</system.web>
</configuration>

Next, we can write the following ASP.NET page:

<%@ Import Namespace="Wrox" %> 
 
<Script runat="server"> 
Public backColor As String 
 
Public Sub Page_Load(sender As Object, e As EventArgs) 
Dim _config As PagePropertiesConfig 
 
_config = CType(Context.GetConfig("system.web/pageProperties"), _ 
PagePropertiesConfig) 
backColor = _config.BackColor 
End Sub 
</Script> 
 
<Body bgcolor="<%=backColor%>"> 
<Font face="arial" color="white" size=4> 
This page has its backcolor set from the ASP.NET configuration system! 
</Font> 

Within the ASP.NET page, we first import the

Wrox namespace, as this includes the

PagePropertiesConfig . Next, we use the

Context object's

GetConfig method and request the configuration information for

system.web/pageProperties . The return type is cast to

PagePropertiesConfig . Finally, we are able to access the

BackColor property on the

PagePropertiesConfig class, which returns the value set in the

web.config file,

blue .

As you can clearly see, this is a simple example. However, it does show just how easy plugging into the ASP.NET configuration system is. You could easily write more complex configuration section handlers for personalization features or other extensions that you may want to add to ASP.NET.