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> .

Note

The value of path requires that you provide [site name ]/[application path] . The value for [site name] is the description value of the web site. The description value can be obtained by opening the IIS MMC, right-clicking on a web site, selecting Properties, and selecting the Web Sites tab. The description value is then visible in the Description textbox.

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="[truefalse]">  

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.




Professional ASP. NET 1.1
Professional ASP.NET MVC 1.0 (Wrox Programmer to Programmer)
ISBN: 0470384611
EAN: 2147483647
Year: 2006
Pages: 243

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net