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:
- Project system support for configuring IIS
- ASP Auto-attach, which the debugger used to find the ASP worker process
- Remote script debugging
- 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:
In IIS Manager, double-click the local computer, right-click the Web Sites folder or an individual Web site folder, and then click Properties.
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.
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.
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"
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
'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
'If the process contains asp.dll, attach to it
If aspLoaded Then
processFound = True
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.")
Catch ex As System.Exception
#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.