I have debugged Classic ASP in Visual Studio 2005. Also, Visual Studio 2008 was supposed to make it better, but I never had a chance to try or to find out the details.
Your biggest problem is that Visual Studio 2005 took away the ability to "Start With Debug" an ASP application.
In VS 2005, Microsoft completely changed the way the debugger connected to IIS. The old way (for both ASP and ASP.NET) which was used by everything from InterDev (remember InterDev?) through VS 2003 was orchestrated via the "Machine Debug Manager", a sort of intermediary helper service. The whole thing was... arcane, trying to solve a complex problem that was made harder by the fact that IIS and Visual Studio run under separate accounts and in some cases, different machines. This was a very delicate process that was very prone to break at the slightest configuration change.
Every single one of my machines stopped being able to debug Classic ASP at some point or another for reasons that appeared related to the alignment of the stars. I used to have at hand a 14 page checklist printout that described the whole "incantation", jumping from IIS Manager to Visual Studio to User Account Manager, to COM+ Explorer... and even that didn't always work. It makes me shiver just thinking about it.
Ultimately, they gave up. In Visual Studio 2005, Microsoft came up with a different architecture for debugging IIS applications (sorry; I don't know how it works now). At the time, MS decided that not enough people were using ASP anymore, and prioritized other work on top of it. Enabling ASP debugging through the new architecture was a significant amount of work especially for a technology on its way out, so it got chopped. I don't blame them; they made a sound business decision. Would you rather have no ASP debugging in VS 2005? Or yes ASP debugging on VS "2006"?
Anyway, not all is lost.
First, you can't "launch" the debugger with F5 anymore, but you can still attach manually to an already running ASP process and it will work, as long as you enable debugging in IIS Manager by hand. The experience in Visual Studio 2005 is sometimes better, sometimes worse than under older versions. It's certainly more stable and very much doable. More details below.
Second, I heard at some point that Visual Studio 2008 was supposed to make a come back and get ASP debugging back in the product, or at least bring some improvement, or some such -- I could never quite get a clear picture. Then I lost track of the whole thing because by some miracle I've kept myself out of dealing much with ASP projects for a few years now.
I'll try to find more references on VS 2008 and classic ASP. If I find something, I'll edit this post with it (sorry -- it might take me a few days to get to it).
More details can be found in these posts:
Full instructions on how to debug by manual attaching in this Gregg Miskelly post: Debugging Classic ASP Code
Other related information can be found here and at other Mikhail Arkhipov posts.
Hope this helps.
You can make a macro in VS2005 to do this.
http://blogs.msdn.com/jimgries/archive/2005/11/30/498264.aspx
Contains an example of attaching to the Calc process.
Sub AttachToCalc()
Try
Dim dbg2 As EnvDTE80.Debugger2 = DTE.Debugger
Dim trans As EnvDTE80.Transport = dbg2.Transports.Item("Default")
Dim dbgeng(1) As EnvDTE80.Engine
dbgeng(0) = trans.Engines.Item("Native")
Dim proc2 As EnvDTE80.Process2 = dbg2.GetProcesses(trans, "JIMSMACHINE").Item("calc.exe")
proc2.Attach2(dbgeng)
Catch ex As System.Exception
MsgBox(ex.Message)
End Try
End Sub
Best Answer
The most likely reason for this is because the process hasn't spun up yet. You need to hit an ASP page first before IIS spins up the DLLHOST.exe in which it runs an application if you have that application set to have high isolation (recommended for debugging purposes).
Hence debugging bia attachment requires the you use the browser to ping an ASP page in your site first, then open the Attach to process list.