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:
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.
Click the Home Directory tab, and then click Configuration.
Click the Debugging tab, and then select the Enable ASP server-side script debugging check box.
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.
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. ... "