ASP.NET, Coding

Configuring IIS & VS 2005

Earlier versions of Visual Studio required the use if IIS when developing web based applications. Visual Studio 2005 includes a built-in web server, negating the need for a developer to have a local installation of IIS. For new ASP.NET application development, developers should not need to have IIS 5.1 installed on their machine. However, for those developers that are going to be migrating applications from ASP to ASP.NET 2.0 there exists the need for IIS 5.1 to be installed so that classic ASP code can still operate.

Configuring IIS
There are several steps that need to be taken to get Visual Studio 2005 and IIS working together.

  1. Grant the local ASPNET user read access to the C:InetPubwwwroot folder.
  2. Verify that the ASPNET user has Read/Write access to C:WINNTMicrosoft.NETFrameworkv2.0.50727Temporary ASP.NET Files
  3. Verify that the ASPNET user has Read access to C:WINNTSystem32
  4. Verify that the ASPNET user has Read/Write/Delete access to C:WINNTTemp
  5. Verify that the ASPNET user has Read access to C:WINNTMicrosoft.NETFrameworkv2.0.50727
  6. Change the version of the .NET Framework that the Default Web Site is running under so that it is using version 2.0.50727. This can be done by accessing the ASP.NET tab from the properties dialog of the Default Web Site.
  7. Change the port number for the “Default Web Site that IIS listens on to 8181. If you use port 80 (the default) the Symantec Client Firewall will block it.
  8. “URLScan” is installed as part of the IIS Client installation. This is a security feature that helps prevent malicious use of your local IIS server. As installed, URLScan does not allow the DEBUG verb. The DEBUG verb must be allowed or order to debug ASP.NET pages. Modify the urlscan.in file in the C:winntsystem32inetsrvurlscan folder so that DEBUG is in the AllowVerbsSection.
  9. Because .NET Framework 2.0 was installed before IIS they arent in sync. To fix this, open up the Visual Studio 2005 Command Prompt from your programs menu and run aspnet_regiis.exe i”.
  10. Run iisreset from the command prompt to get IIS into a good, stable state.

At this point IIS should be configured correctly to allow an ASP.NET 2.0 application to be run and debugged.

Creating a New ASP.NET Web Site
The recommended approach for working with Visual Studio 2005 is to use a File System type project as opposed to HTTP. By using the File System it allows your web site to run under either the built-in web server or IIS. Because you will eventually stop using IIS once your classic ASP code has been migrated, this option allows you to use the same project for the life of your application.

The following steps outline an approach for making a file system based site available through IIS so that you can then add your classic ASP pages to it during your migration.

  1. Open Visual Studio 2005 and create a new web site using the File System. Make note of the folder location in which you are creating the site.
  2. As configured the built-in web server will be used to run/debug the site. If you are going to be supporting a migration with this new site then you will want to change this so that IIS hosts the site. In Visual Studio, with your website loaded, go to “website–>start options” and choose the “Use Custom Server” option and set the “BaseURL” to your site: http://localhost:8181/DemoSite1/ as an example.
  3. IIS doesn’t know about this site yet, however, so you need to configure a new virtual directory. The easiest way to do this is from the file explorer. Open your file explorer and navigate to the directory containing the folder that contains the content for your site. Right click on the web sites folder and choose properties. Click on the Web Sharing tab and choose the Share this folder option. Accept the defaults and click until all dialogs have been closed. A virtual directory has now been created in IIS.
  4. Make sure that the ASPNET user has read access to the folder you just web shared. Also, make sure that if you are going to be storing any data in the App_Data folder that the ASPNET user has read/write access to that folder.
  5. Go to IIS Manager and select the properties for your site. Select the Documents tab and add Default.aspx to your list of default pages. This will allow you to browse to your root without needing to specify a file name.

At this point your site should now work running under IIS.

Debugging Classic ASP
Because the ASP runtime isn’t hosted in the same process as the aspnet_wp, a dllhost is used. As such, there are a couple of other modifications that need to be made to get an ASP page to work and be debuggable.

  1. Add the IWAM_machinename account to Debugger Users Group. Machine name is the name of your local development machine.
  2. Ensure that the Debugger Users Group has Local Launch and Local Activation rights for the Machine Debug Manager. Open the Component Services console (Administrative Tools -> Component Services) and drill down into the DCOM Config folder. Select the Machine Debug Manager component and right-click to select Properties. Select the Security tab and then click the Edit button in the Launch and Activation Permissions section. If the Debugger Users group does not have Local Launch and Local Activation privileges then add it.
  3. Ensure that ASP debugging has been enabled in IIS for the virtual directory.
  4. Run iisreset from the command prompt just to make sure all settings take effect.

At this point your machine is configured to be able to debug a classic ASP page. However, the Visual Studio 2005 IDE doesn’t automatically attach to the dllhost.exe process. Rather, it attaches to whatever process the .net code is running in which, on Windows XP SP2, is the aspnet_wp.exe process. As such, it is necessary to manually attach to the dllhost.exe process.

Attaching to this process can be done within Visual Studio 2005 by selecting Debug -> Attach to process. Once the dialog appears, make sure the two check boxes at the bottom are selected otherwise you won’t see all the processes on the machine. Select the dllhost.exe process that has a user of machinenameIWAM_machinename. You may have several dllhost.exe processes on your machine this is the one you want.

If you don’t see this process it is because you’ve recently done an iisreset and the process hasn’t spun up. Simply open a browser and navigate to one of your ASP pages and the process will start. You can then attach to it using the steps just described.

With this step completed you can now set breakpoints in either classic ASP code or ASP.NET 2.0 code and the debugger will stop on those breakpoints.

Macros to the Rescue
Although this approach works, and works well, one of the drawbacks is that manually attaching to the process is cumbersome. I wrote a macro that you can add to your Visual Studio 2005 environment that, when executed, looks for the process running under the correct user and attaches to it. The code for this macro follows:

Sub AttachDebugger()
Try
  Dim attached As Boolean = False
  Dim proc As EnvDTE80.Process2
  Dim user As String = My.Computer.Name + “IWAM_” + My.Computer.Name
  For Each proc In dte.Debugger.LocalProcesses
  If (proc.Name.EndsWith(”dllhost.exe”)) And (proc.UserName.Equals(user)) Then
  proc.Attach()
  attached = True
  Exit For
  End If
  Next
  If attached = False Then
  MsgBox(”ASP dllhost.exe is not running”)
  End If
  Catch ex As System.Exception
  MsgBox(ex.Message)
  End Try
End Sub

While you can execute this macro by double-clicking on it from within the macro explorer, you can also add it to your toolbar or make it accessible via a keyboard shortcut. To set it up as a keyboard shortcut, after creating the macro, right-click in your toolbar and choose customize. After doing so choose the commands tab and then click the keyboard button. From the listbox containing the Show commands containing options choose the macro you just created Macros.MyMacros.Module1.AttachDebugger.

Then, in the press shortcut keys textbox choose an unused shortcut. You may have to try a few key combinations before you find one that’s not assigned to some other feature. Now, when you want to debug ASP, just press your key combination and you’re automatically attached. I find that starting up the application using the standard F5 (start with debugging) is nice because it opens up a browser instance and gets your ASP.NET stuff attached and ready to go. After the browser window is launched just go back to Visual Studio and run your macro and now you’re attached to ASP as well.