Web Connection on IIS 7 and Vista
June 09, 2006 •
IIS 7 and Web Connection
I’ve been working with Vista and IIS 7 for the last week and a half and the good news is that Web Connection works just fine on Vista and IIS 7. Even automatic configuration works in most cases, when IIS 7 has been set up to include for IIS6 Metabase Compatibility:
Although IIS 7 seems to work without any big problems, here’s a guide to manually configuring IIS 7 with the important things required for Web Connection configurations.
The steps involved in this are pretty much the same as in IIS 5 and 6, but it’s a bit more complicated to find the right options as everything in the IIS Mangement UI has been moved and renamed. I suppose I’ll get used to this, but I was hunting around a long time for many options – there are lot of settings that have similar names or names that could be construed for other things.
Enabling up the Application Extension
Like in IIS 6.0, IIS 7.0 is locked down and cannot execute arbitrary ISAPI or CGI extensions. Even ASP classic and ASP.NET are locked down by default and you have to enable them. To do this you need to explicitly enable the application extension:
Go to the machine root (this is a MACHINE wide setting, not a Web Site wide setting) and go to the IIS settings. Find ISAPI and CGI Restrictions and add a new mapping:
Creating a Virtual Directory – er, Application
The biggest change here is that you’ll want to create an Application, not a Virtual Directory. Previous versions of IIS had the concept of Applications vs. just Virtuals but pretty much when you created a Virtual through IIS it always created an Application. An Application in IIS’s sense is that it has its own copy of web.config that configures as a sub-application of the Web Site. This web.config then holds the Application settings for that virtual directory.
The good news here is: Web.config is a text file that you can edit and logically at that. Making a change to the file directly affects the configuration settings for the Application! This means for one that you can configure the virtual directory in the web.config file and then simply copy the web.config file with the application: Voila the application settings now are portable.
Other than the Application Pools and Virtual Directory Configuration itself (which is stored in a master ApplicationHost.config file in the IIS Configuration directory) you can make any directory level settings in a local web.config file and carry those configuration settings with your applications simply by copying the files. Yay. So setting up the right type of Authentication, setting up script maps (now called Handler Mappings), and anything else that relates to the virtual directory specifically can be set in web.config locally to the app.
Scriptmap or Handler Mapping Configuration
So one of the more important things that need to be done with Web Connection is to create Handler Mapping so that you can execute a .WCSX or .BLOG page using a custom extension. In IIS 7 you do this via Handler Mappings on a Virtual Directory or Web Root:
One change here is that you can give the extension a descriptive name which is what displays in the list as the name. In addition, you’ll also want to carefully look at the Request Restrictions:
By default the restrictions are mapped to a file, which means the request needs to find a file on disk or it will throw a 404 – Not Found error before it ever hits your code.
If you’re creating mappings to Web Control Framework Pages (WCSX pages for example) then using the File default is Ok, since you will always need a file present. However, if you create classic Web Connection applications that use Process methods and pure code, without a file present, you’ll want to create the handler and uncheck the box as shown above. If at any time you need to execute a request with this extension that doesn’t have a matching page use the unchecked option. I suggest always using this and letting Web Connection handle the file mapping.
Note though, that unless this box is checked, Windows Authentication against file system permissions will not work. So if you want to set file system permissions on files and retrieve authentication information from those files you need have this option checked.
That’s pretty much it. I’ve been going through running all of my existing Web Connection applications without any problems. Even nicer I didn’t have to recreate my script maps manually in the UI or even using the Web Connection ScriptMaps.prg utility which lets you quickly create scriptmaps by running a small application. Rather I created one map, then simply edited the local web.config file:
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
<system.webServer>
<handlers>
<clear />
<add name="Web Connection Demo" path="*.wwd" verb="*" modules="IsapiModule" scriptProcessor="c:\westwind\wconnect\wc.dll" resourceType="Unspecified" requireAccess="Script" />
<add name="Web Connection WebLog" path="*.blog" verb="*" modules="IsapiModule" scriptProcessor="c:\westwind\wconnect\wc.dll" resourceType="File" requireAccess="Script" />
<add name="West Wind Web Control Framework" path="*.wcsx" verb="*" type="" modules="IsapiModule" scriptProcessor="C:\Westwind\wconnect\wc.dll" resourceType="File" requireAccess="Script" preCondition="" />
<add name="West Wind Admin" path="*.wst" verb="*" modules="IsapiModule" scriptProcessor="c:\westwind\wconnect\wc.dll" resourceType="Unspecified" requireAccess="Script" />
<add name="West Wind Soap" path="*.wwsoap" verb="*" modules="IsapiModule" scriptProcessor="c:\westwind\wconnect\wc.dll" resourceType="Unspecified" requireAccess="Script" />
<add name="ASPClassic" path="*.asp" verb="GET,HEAD,POST" type="" modules="IsapiModule" scriptProcessor="C:\Windows\system32\inetsrv\asp.dll" resourceType="File" requireAccess="Script" preCondition="" />
<add name="OPTIONSVerbHandler" path="*" verb="OPTIONS" type="" modules="ProtocolSupportModule" scriptProcessor="" resourceType="Unspecified" requireAccess="None" preCondition="" />
<add name="StaticFile" path="*" verb="*" type="" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" scriptProcessor="" resourceType="Either" requireAccess="Read" preCondition="" />
</handlers>
</system.webServer>
</configuration>
Unfortunately, it looks like some settings must be made at the ApplicationHost.config level, such as the authentication settings. ApplicationHost.config lives in the <windows>\system32\inetsvr directory and the section in there looks like this:
<location path="Default Web Site/wconnect">
<system.webServer>
<security>
<authentication>
<basicAuthentication enabled="true" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
I haven’t played around with all the settings to see how this breaks out, but I suspect any truly low level settings need to be applied at the ‘server’ level in ApplicationHost.config. For Web Connection the Authentication is likely to be the only one. <shrug>
So the news is good so far with compatibility. I’m looking to build true IIS 7 support using the new WMI providers so hopefully I’ll be able to create the same setup experience as before. I just hope that the process of finding the documentation for this stuff will be a little easier than it was with IIS 6. I seem to remember trying to figure out how to create an Application Pool and set the Script Extension registration was a bitch to figure out without any documentation on the subject.
Joost
August 16, 2006