views:

14

answers:

1

I have IIS 7.5 on Windows 7 x64 and IIS 7.0 on Windows 2008 SP2 x86. In both cases, all the IIS 6 Compatibility features have been installed.

In IIS Manager, I have created a virtual directory named TestAccess with the physical path

c:\inetpub\wwwroot\TestAccess

I am trying to read the AccessFlags properties using VB.NET code like this:

Dim de As New DirectoryEntry("IIS://localhost/W3SVC/1/Root/TestAccess")
Console.WriteLine(de.Properties("AccessRead").Item(0))
Console.WriteLine(de.Properties("AccessWrite").Item(0))
Console.WriteLine(de.Properties("AccessExecute").Item(0))
Console.WriteLine(de.Properties("AccessSource").Item(0))
Console.WriteLine(de.Properties("AccessScript").Item(0))

Unfortunately, this code appears to grab the (inherited) information from

c:\Windows\System32\inetsrv\config\applicationHost.config

but if I go into IIS Manager, select the virtual directory, select Handler Mappings, click Edit Feature Permissions and make any changes, the actual changes are written to

c:\inetpub\wwwroot\TestAccess\web.config

If not DirectoryServices, what instrumentation code should I use to get a combined view of the applicationHost.config and the specific directory's web.config files so I can read the effective values of those properties? I would prefer something that works with both IIS 6.0 and 7.x.

+1  A: 

As you're aware the System.DirectoryServices bits wrap the IIS6.0 compatibility layer. But the compatibility layer simply provides a mapping to features that were supported in IIS6 only.

IIS6 had no real knowledge of ASP.NET other that it being a script mapping to one or two ISAPI filters (and a minor update to the IIS MMC to permit switching en-mass the script maps from one version of ASP.NET to another).

IIS6 stores much of its configuration in the metabase so the API's are designed to manipulate the metabase store. The IIS6 metabase is ignorant of ASP.NET and web.config, again ASP.NET is just a script map.

There were never any settings to control IIS6 in a site's web.config file. IIS 6 is blind to this file and so the compatibility layer is also blind and doesn't take into account additional settings that might be configured in the <system.webServer> section of a site's web.config file.

The IIS6 compatibility layer emulates the metabase by modifying equivalent settings in applicationHost.config only.

IIS7 changes the game and settings in web.config files (under the <system.webServer> section are now assimilated into the overall runtime configuration of a site when it starts.

So the bottom line is if you want an aggregated view of an IIS7 site's configuration you'll need to use the new managed API's Microsoft.Web.Administration and Microsoft.Web.Management. You can also use the appcmd.exe command line configuration tool as well.

Using these tools you can specify where you want to read or modify settings e.g. at the Application Host level or at the local site level.

It should be noted that many settings are always assumed to be inherited unless overridden by a configuration file at a more specific location (e.g. site or subdirectory).

The IIS7 MMC console tends to place changes (such as to handler mappings, mime types etc) in the site local web.config file. If you need to ensure these changes are more persistent and not at risk of being deleted then you can commit them to the applicationHost.config file, but you need to use either appcmd.exe (with the /commit:apphost switch or work with the managed API's using tools such as VB.NET, C# or PowerShell.

Kev
Yes, I knew about the Administration and Management APIs but was hoping for something that would allow me to handle IIS 6 and IIS 7 alike with the same piece of code. Thank you for your comprehensive answer.
Joergen Bech