Professional ASP.NET 3.5 in C# and Visual Basic Part 63 pdf

Hierarchical ConfigurationThe new IIS7 and ASP.NET 3.5 integrated configuration system consists of a hierarchy of configuration files where lower-level configuration files inherit the co

Hierarchical Configuration

The new IIS7 and ASP.NET 3.5 integrated configuration system consists of a hierarchy of configuration files where lower-level configuration files inherit the configuration settings from higher level configura-tion files The lower-level configuraconfigura-tion files can override only those inherited configuraconfigura-tion settings that are not locked in the higher level configuration files

In this section, you’ll learn how the IIS Manager takes the hierarchical nature of the IIS7 and ASP.NET 3.5 integrated configuration system into account Let’s begin with the ASP.NET 3.5 configuration settings

Launch the IIS Manager again, select the node that represents the local Web server in the Connections

pane and switch to the Features View tab in the workspace pane The result should look like Figure 11-11 Now double-click the Session State icon in the workspace pane You should see what is shown in

Figure 11-12

Note that the workspace now displays the GUI that allows you to change the session state configuration settings Go to the Session State Mode Settings section, change the mode to Not enabled, and click the

Apply link in the Tasks pane to commit the changes Now open the rootweb.configfile located in

the following directory on your machine:

%SystemRoot%\Microsoft.NET\Framework\versionNumber\CONFIG\

Figure 11-12

577

You should see the highlighted portion shown in the following listing:

<configuration>

<system.web>

<sessionState mode="off" />

</system.web>

</configuration>

As this example shows, you can use IIS Manager to specify the ASP.NET configuration settings as you

do for the IIS settings The tool is smart enough to know that the machine-level ASP.NET configuration

settings should be saved into the machine levelweb.configfile (known as the rootweb.configfile)

instead ofapplicationHost.config

The previous example changed the session state configuration settings at the machine level Now let’s

change the session state configuration settings at the site level Go back to the Connections pane, open

the node that represents the local Web server, open the Sites node, and select the Default Web Site node

You should see the result shown in Figure 11-13 Be sure you select the Web Site node and not the node for the

entire Web Server.

Figure 11-13

578

Now double-click the Session State icon Change the Session State Mode settings to Not enabled and click the Apply link on the tasks panel to commit the changes Now open theweb.configfile in the following directory on your machine:

%SystemDrive%\inetpub\wwwroot

You should see the highlighted portion of the following code listing:

<configuration>

<system.web>

<sessionState mode="off" />

</system.web>

</configuration>

As this example shows, the IIS Manager stores the site-level ASP.NET configuration settings to the

site-level configuration file If you repeat the same steps for application level ASP.NET configuration

settings, you’ll see that the IIS Manager stores these configuration settings into the ASP.NET application level configuration file

So far you’ve seen that IIS Manager handles the hierarchical nature of the ASP.NET 3.5

config-uration settings Next, you’ll see that the IIS Manager also takes the hierarchical nature of the IIS7

configuration settings into account

Launch the IIS Manager, click the node that represents the local Web server in the Connections pane,

switch to the Features View tab in the workspace, and select the Area option from the Group by combo box to group the items in the workspace by area You should see the result shown in Figure 11-14

Now double-click Default Document The result should look like Figure 11-15

Notice that the workspace now contains a text box that displays the list of default documents Add a new

default document named Welcome.htm to the list and click the Apply button in the task panel to commit

the changes

If you open theapplicationHost.configfile, you should see the highlighted portion shown in

Listing 11-4 Notice that the < files > element now contains a new<add>element whose value

attribute is set toWelcome.html

Listing 11-4: The applicationHost.config file

<configuration>

<system.webServer>

<defaultDocument enabled="true">

<files>

<clear />

<add value="Welcome.htm" />

<add value="Default.asp" />

<add value="index.htm" />

<add value="index.html" />

<add value="iisstart.htm" />

<add value="default.aspx" />

</files>

</defaultDocument>

</system.webServer>

</configuration>

579

Figure 11-14

Figure 11-15

580

Now select the Default Web Site node from the Connections pane of the IIS Manager and double-click the Default Document icon to go to the page that displays the list of default documents Note that the list con-tains theWelcome.htmldefault document that you added before This makes sense because the Default Web Site inherits all the default documents settings from the machine-levelapplicationHost.config

file Now go ahead and remove theWelcome.htmlfile from the list, add a new default document named

Start.html, and click the Apply button to commit the changes If you open theweb.configfile located in the Default Web Site’s root directory, you should see the result shown in Listing 11-5

Listing 11-5: The root web.config file

<configuration>

<system.webServer>

<defaultDocument>

<files>

<clear />

<add value="Start.htm" />

<add value="Default.asp" />

<add value="index.htm" />

<add value="index.html" />

<add value="iisstart.htm" />

<add value="default.aspx" />

</files>

</defaultDocument>

</system.webServer>

</configuration>

Delegation

As Listing 11-5 shows, a site- or application-levelweb.configfile now can contain both ASP.NET and

IIS configuration sections This is one of the great new features of IIS7, which provides the following two benefits among many others:

❑ It allows you to configure IIS7 to meet your application-specific requirements

❑ Since these IIS7 custom configuration settings are all stored in theweb.configfile of your appli-cation, which is located in the same directory with the rest of your appliappli-cation, you can xcopy

this configuration file together with the rest of your application to the test machine, and from

there to the production machine This will allow your testers and clients to start testing and using your applications right away, without going through the tedious task of reconfiguring their Web servers to match the configuration you had on your Web server when you were developing the application

You may be wondering whether it is a good idea to allow site and application administrators or

developers to mess with the Web server settings from a security perspective IIS7 and ASP.NET 3.5

integrated configuration system has taken this security issue into account Because of the hierarchical

nature of the configuration files, changes made to a configuration file at a certain level of hierarchy apply only to that level and the levels below it For example, if you make some configuration changes in the

web.configlocated in the root directory of a site, it will affect only the applications and virtual directo-ries in that site Or if you make changes in theweb.configlocated in the root directory of an application,

it will affect only the virtual directories in that application

In addition most IIS configuration sections are locked by default at installation, which means that by

default only the machine administrator can change these locked IIS configuration sections However, the

581

machine administrator can remove the lock from selected IIS configuration sections to allow selected sites,

applications, or virtual directories to change these configuration sections This is known as delegation

Let’s take a look at an example

Recall from the previous example (see Listing 11-5) that the Default Web Site administrator was allowed

to reconfigure the IIS7 default documents for all the applications and virtual directories of the Default

Web Site This was possible because by default there is no lock on the IIS7 default documents feature To

see this, take the following steps:

1. Launch the IIS Manager.

2. Click the node that represents the local Web server in the Connections pane.

3. Switch to the Features View tab in the workspace.

4. Select the Area option from the Group by combo box of the workspace

The result should look like Figure 11-16

Figure 11-16

Now double-click the Feature Delegation icon in the Management section of the workspace to go to

the Feature Delegation page shown in Figure 11-17 As the name implies, the Feature Delegation page

582

allows the machine administrator to delegate the administration of the selected IIS features to site and

applications administrators Select the Delegation option from the Group by combo box and go to the

Read/Write section of this page as shown in Figure 11-17 As the title of this section implies, this section contains IIS7 features that can be read and written from the lower-level configuration files Note that this section contains the Default Document feature

Figure 11-17

Select the Default Document from the Feature Delegation page as shown in Figure 11-17 Notice that the task pane contains a section titled Set Feature Delegation This section contains six links named:

❑ Read/Write

❑ Read Only

❑ Not Delegated (on Windows Server 2008) or Remove Delegation (on Windows Vista)

❑ Reset to inherited

❑ Reset All Delegation

❑ Custom Web Site Delegation (This link only exists on Windows Server 2008.)

Note that the Read/Write link in the Actions Pane is grayed out (as is the content-menu item), which

means that the lower-level configuration files have the permission to change the IIS7 Default

583

Document feature Click the Read Only link and open theapplicationHost.configfile You should

see the highlighted portion shown in Listing 11-6 Some parts have been omitted for brevity

Listing 11-6: The applicationHost.config file

<configuration>

<location path="" overrideMode="Deny">

<system.webServer>

<defaultDocument enabled="true">

<files>

<clear />

<add value="Welcome.htm" />

<add value="Default.asp" />

<add value="index.htm" />

<add value="index.html" />

<add value="iisstart.htm" />

<add value="default.aspx" />

</files>

</defaultDocument>

</system.webServer>

</location>

</configuration>

As Listing 11-6 shows, the IIS Manager has added a new < location > tag whoseoverrideMode

attribute is set toDeny to signal that the machine administrator does not want any lower-level

configuration file to change the IIS7 default document feature This means that every site,

applica-tion, and virtual directory running on the machine inherits these authorization rules and has to live

by them

Moving an Application from IIS6 to IIS7

If you add a standard ASP.NET application into an IIS application pool that is configured for the

Integrated Pipeline, rather than the Classic Pipeline and it contains entries in itsweb.configfor

< system.web > / < httpModules >, you’ll get an informative error message like the one in Figure 11-18

At this point you have two choices, as clearly outlined in the error message You can either change the

application’s web.configto move the modules into the IIS7 integrated pipeline, or you can

run the application in Classic mode

The error message actually includes the command line you need to migrate yourweb.config:

%systemroot%\system32\inetsrv\APPCMD.EXE migrate config "Default Web Site/DasBlog2"

When you run that statement from an administrator command line, you’ll see the following

output:

%systemroot%\system32\inetsrv\APPCMD.EXE migrate config "Default Web Site/DasBlog2"

Successfully migrated section "system.web/httpModules"

Successfully migrated section "system.web/httpHandlers"

584

Figure 11-18

Be sure to make a copy of yourweb.configfor backup purposes, but also for education as you can

compare the two with your favorite diff tool Notice the creation of a newsystem.webServersection in the following snippet:

<system.webServer>

<modules>

<add name="UrlMapperModule"

type="newtelligence.DasBlog.Web.Core.UrlMapperModule, newtelligence.DasBlog.Web.Core" preCondition="managedHandler" />

removed for brevity

</modules>

<handlers>

<add name="*.blogtemplate_*" path="*.blogtemplate" verb="*"

type="System.Web.HttpForbiddenHandler"

preCondition="integratedMode,runtimeVersionv2.0" />

585

removed for brevity

</handlers>

</system.webServer>

Notice also thepreConditionattribute that was automatically created by the migration tool for both the

handlers and the modules When it is set tomanagedHandler, this means that by default all registered

managed modules will be applied only to those requests whose handlers are managed handlers, that is,

requests for ASP.NET content

Summar y

IIS7 is easier to install than IIS6 was When you choose only those modules required for your application,

you create a more secure Web Server IIS7 is easier to configure than IIS6 There’s a much richer graphical

interface, and command-line interface, and a transparent and hierarchical XML-based configuration

system that feels familiar to professional ASP.NET developers Applications are trivial to migrate and

run faster under IIS7

The skills you’ve developed writing HttpHandlers and HttpModules can be immediately leveraged

within IIS7 You should check out IIS7 on Vista or Windows Server 2008 and pick up Professional IIS 7 and

ASP.NET Integrated Programming from Wrox for an in-depth look at the IIS 7 programming model.

586