Configuring Visual Studio to debug classic asp

I would like to be able to set breakpoints in a large classic ASP application originally developed with Visual Studio 6 (interdev). To date I have put in several days and numerous hours following suggestions all over the web on how to configure my environment to accomplish this. And I have had on and off success...mostly off. The extent of my success was that I was able to set and hit a breakpoint in both a simple one page test script (see below) and in the full application. So I thought my problems were behind me and I could get on with the debugging. However on the following day I could no longer debug.

I have set up two different dev environments:
1. Visual Studio 2010 Pro on Windows XP Pro  (with IIS 5.1 on dev machine)
2. Visual Studio 2013 Pro on Windows 7 Pro (with IIS 7.5 on dev machine)

(I set up two environments b/c there was a lot more info available about debugging ASP with vs 2010 than with vs 2013):

I successfully set breakpoints in both environments and was able to have them fire. But as I said above, now they are not working.  For the same simple test script, each of the two environments is exhibiting a different problem.

In VS 2013, I can no longer set a breakpoint. Instead I get the message "A breakpoint cannot be inserted at this location." It's as if visual studio all of a sudden doesn't recognize the code as vbscript.

In VS 2010, I can set all the breakpoints I want, but after I attach to the appropriate dllhost, the breakpoints are never hit. Yes, I did refresh the page.

There just seem to be too many moving parts, settings, and things to configure in order to get this to work properly. Does anyone out there have in depth experience with this? I am attaching my test script - perhaps you can get debugging working in your environment and then we can compare notes.


============================ ASP Test script =============================

<%@ Language=VBScript %>


<h1>K squared<p></h1><%
dim k, ksquared
response.write "Now it is " & time() & "<p>"
if k<>"" then
      if isnumeric(k) then
            ksquared=k * k
            Response.Write "K squared is " & ksquared & "<p>"
            Response.Write "'" & k & "' is not numeric. <p>"
      end if
end if


<form action=ksquared.asp>
Enter a value K to square:<input type=text size=5 name=k value='<%=k%>'>
<p><input type=submit value="submit">

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Big MontyWeb Ninja at largeCommented:
I assume you've "enabled asp debugging" in IIS and attached the debugger to the IIS process in VS?

doing a little searching around, I found this blog, but in all honesty, I've never had good luck with using debuggers in visual studio. I've found them iffy at best, and took up more time than it's worth. I've always just used the tried and true method of adding response.write to sections of my code I want to debug. I find this the most efficient way, as I can control exactly what data I want to see
espodAuthor Commented:
I have done all of those steps many, many times. While I haven't referenced that specific blog, I have followed identical steps in several other blogs. I am using IIS.

Response.write has worked for me for many years, but dynamic debugging lets you poke around and see stuff you might not have anticipated. Not to mention being able to step through the code to see where you might have screwed up. Also if you are trying to find a bug that is the result of complex data interactions, you have to keep restoring the conditions each time you want to do a debugging run. Not to mention the fact that sticking response.writes in the middle of HTML is OK but not great.

Big MontyWeb Ninja at largeCommented:
I agree with every point you make, but I find Response.Write, while a bit more difficult to work with, ALWAYS helps me debug what I need to. I cannot say the same for VS debuggers :)

anyways, good luck and happy turkey day!
HTML5 and CSS3 Fundamentals

Build a website from the ground up by first learning the fundamentals of HTML5 and CSS3, the two popular programming languages used to present content online. HTML deals with fonts, colors, graphics, and hyperlinks, while CSS describes how HTML elements are to be displayed.

Scott Fell, EE MVEDeveloper & EE ModeratorCommented:
I agree, I don't use VS and I don't imagine that there is anything like what you are looking to do for classic asp.  

My method is simply to run on the server where I can see the complete error and 95% of the time I can tell what the fix is right away.  If I have something very complex, I start making traps or response writes before everything you would consider to be a break point.   Check what data is being sent just before and after an if/them, do/loop, function etc.  

It also helps to use option explicit to catch typos.  

The other thing I have learned is if it overly complex, start over.  Even if that means you just spent 20 hours on something.  It was hard at first to just let go, but being able to realize you created something overly complex is a giant step.

I also find my best debugging is  a simple editor that has color coding like notepad++ for windows or textwrangler for mac (both free) or sublime text.  

Many errors have to do with spelling, single/double quotes that can be quickly seen by color coding.  

The next biggest error is data you didn't expect and that is where manual trapping or response.writing comes in.

I have also resorted to writing to a log file instead of response.writing to the screen.

You are not the first person to ask for classic asp debugging in VS and I have not seen the type of answer you are looking for which is why I opened it up to some additional topics.
espodAuthor Commented:
I like the idea of writing to a text log.

All your remarks are right on. It's just that in some situations a dynamic debugger is what suits the job, and I've missed having that as a tool for a long time. So long I'd forgotten about it, until I discovered Firebug, and then I remembered the joys of dynamic debugging.
Scott Fell, EE MVEDeveloper & EE ModeratorCommented:
It can be easier to debug front end code with firebug or any of the browsers built in console.  That just does not exist for classic asp.  This is might be one of those "it can't be done" questions.

I did a quick search for classic asp unit testing.  With that I found a classic asp compiler you can use in .net.  I wouldn't know enough about this to help but perhaps worth looking into

This is is an interesting read too.  Just keep clicking the Next Post link at the top of the page 

A few others I found 

I know it seems the long way, but a few simple things as pointed out above is really all you need.  The more you can hand code and not rely on the IDE to fill in the blanks is also a big help.  Although I don't see many Dreamweaver questions on this topic, many  of the issues where from relying on the generated code.  Not that DW produced some bad code, because it did, but because there seemed to be an aversion to taking the training wheels off and coding by hand.   Once that is done, you know your code better and can be much faster in debugging your own code.
espodAuthor Commented:
I wasn't aware there was an ASP to compiler. Interesting discussion.

In the meanwhile I coughed up some bucks and purchased Team Remote ASP debugger, which is a tool written exactly for what I am trying to do. Works pretty well.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Scott Fell, EE MVEDeveloper & EE ModeratorCommented:
If nothing else, you have to love the payment page.

This is not a game for me.
 I am not a charity
This freebee culture is ridiculous! We need to earn too, so we can pay you for your services!
If something doesn't work with them, don't freak out like a crazy abandoned baby, let me connect remotely and I'll solve it.
espodAuthor Commented:
The tool I purchased does the job. Apparently no one out there is using VS to debug classic ASP, or if they are, they're not monitoring Experts Exchange.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
DB Dev Tools

From novice to tech pro — start learning today.