Monday, June 6, 2011

Classic ASP Debugging with VS 2005

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.


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()


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


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

If aspLoaded Then


processFound = True

End If


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


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. ... "

No comments: