Debugging Classic ASP Code

  • Article

Since shipping Visual Studio 2005, we have heard from some users complaining about the fact the Visual Studio 2005 doesn’t support debugging classic ASP code. Today I want to talk about what we recommend you do to debug your ASP code.

 

Visual Studio 2003

If you have Visual Studio 2003 already, why not continue to use it? Visual Studio 2005 can run on the same machine as Visual Studio 2002 or Visual Studio 2003. While Visual Studio 2005 has loads of new features, they aren’t aimed at the classic ASP developer. So we recommend that you continue using Visual Studio 2003 for your ASP debugging needs.

 

Visual Studio 2005

However, if you insist on using Visual Studio 2005 for your classic ASP debugging needs, I have some good news -- while harder to setup, with a little bit of help from this blog, you can still have a nice experience debugging your class ASP code with Visual Studio 2005. There are four features that we cut from Visual Studio 2005 that affect ASP debugging:

  1. Project system support for configuring IIS
  2. ASP Auto-attach, which the debugger used to find the ASP worker process
  3. Remote script debugging
  4. Debugging managed code and script code at the same time

Let's go through how we can work around these cuts.

#1. The project system provided support to automatically configure your machine for ASP debugging. However, since it is only a one-time deal, you can always manually configure your machine. From technet:

1.

In IIS Manager, double-click the local computer, right-click the Web Sites folder or an individual Web site folder, and then click Properties.

  Note

Configuration settings made at the Web Sites level are inherited by all of the Web sites on the server. You can override inheritance by configuring the individual site or site element.

2.

Click the Home Directory tab, and then click Configuration.

3.

Click the Debugging tab, and then select the Enable ASP server-side script debugging check box.

4.

Click Send detailed ASP error messages to client if you want to send the client very detailed debugging information, or click Send the following text error message to client and type the text you want to send to the client.

5.

Click OK.

If you intend to debug client-side script as well, you might also want to set the ASPCLIENTDEBUG cookie. See MSDN.

 

#2. Since the debugger doesn’t have support for ASP Auto-Attach, you can’t just press F5. But what you can do is to hit your page in IE, and use the below macro to automatically start debugging the ASP code. You can assign a macro to a key, so within 2 minutes, you can have Ctrl-Shift-F5 (or whatever key you want), setup to automatically attach to the worker process and get a pretty similar experience to what you have always had.

    Sub ClassicASPAttach()

        Try

            Dim os As System.Version = System.Environment.OSVersion.Version

            Dim IISProcess As String = "w3wp.exe"

            If os.Major = 5 And os.Minor < 2 Then

                IISProcess = "dllhost.exe"

            End If

            Dim processFound As Boolean = False

            Dim process As EnvDTE80.Process2

            For Each process In DTE.Debugger.LocalProcesses

                'Determine if the process could the IIS worker process

                Dim processName As String = process.Name.ToLowerInvariant()

                Dim processBaseName As String = System.IO.Path.GetFileName(processName)

                If Not processBaseName = IISProcess Then

                    If Not processBaseName = "inetinfo.exe" Then

                        Continue For

                    End If

                End If

                'Determine if the process contains asp.dll

                Dim aspLoaded As Boolean = False

                Dim diagProcess As System.Diagnostics.Process = System.Diagnostics.Process.GetProcessById(process.ProcessID)

                Dim diagModule As System.Diagnostics.ProcessModule

                For Each diagModule In diagProcess.Modules

                    Dim moduleName As String = System.IO.Path.GetFileName(diagModule.FileName).ToLowerInvariant()

                    If moduleName = "asp.dll" Then

                        aspLoaded = True

                        Exit For

                    End If

                Next

   'If the process contains asp.dll, attach to it

                If aspLoaded Then

                    process.Attach2("Script")

                    processFound = True

                End If

            Next

            If Not processFound Then

                MsgBox("Could not find this IIS process. Hit a web page containing classic ASP script so that the process will start.")

            End If

        Catch ex As System.Exception

            MsgBox(ex.Message)

        End Try

    End Sub

 

#3. Sadly, there just isn’t any way to do remote script debugging. If you need remote script debugging, my only suggestion would be to use Remote Desktop and run Visual Studio on your server.

#4. Again, there just isn’t any way to debug both script code and managed code at the same time. My only suggestion here would be to switch back and forth between managed debugging and script debugging.

 

Explaining our decision

That said, I wanted to try and explain why we made the decision to cut classic ASP support. There are a couple of technical reasons why we don't support it:

  • Debugging script and managed code at the same time was really difficult to keep working, so we really wanted to cut it. However, the only web project system in Visual Studio is the ASP.NET project system. We didn't really want to have an option that would turn off managed debugging in an ASP.NET project.
  • In Visual Studio 2005, we removed the debugger service (MDM), which was the right thing to do for many reasons. However, the MDM service was integral to the way we supported auto-attach in Visual Studio 2002/2003, and so we would have to completely redo it if we still wanted it to work.
  • OS changes made remote script debugging really difficult to configure. Specifically I am thinking of the creation of the Windows Firewall and the DCOM changes that happened in Windows XP SP2.

But I think the biggest reason we wanted to cut classic ASP support was time. Every software project has limited resources. Keeping classic ASP debugging would have required significant resources. Instead of spending those resources on ASP debugging, we wanted to spend it on making all the other scenarios that we support better. We spent many years writing tools that did support classic ASP debugging, and we feel that those tools still do a good job debugging classic ASP script. I hope you will understand.