espod
asked on
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.
Thanks,
Eric
==========================
<%@ Language=VBScript %>
<HTML>
<HEAD>
</HEAD>
<BODY>
<h1>K squared<p></h1><%
k=request("k")
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>"
else
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">
</form>
</BODY>
</HTML>
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.
Thanks,
Eric
==========================
<%@ Language=VBScript %>
<HTML>
<HEAD>
</HEAD>
<BODY>
<h1>K squared<p></h1><%
k=request("k")
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>"
else
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">
</form>
</BODY>
</HTML>
ASKER
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.
Thanks
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.
Thanks
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!
anyways, good luck and happy turkey day!
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.
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.
ASKER
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.
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.
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 https://aspclassiccompiler.codeplex.com/.
This is is an interesting read too. Just keep clicking the Next Post link at the top of the page
http://www.beingnew.net/2008/10/user-stories-for-classic-asp-unit.html
A few others I found
http://framework.lojcomm.com.br/app/docs/class.unittest/index/General.html
http://msdn.microsoft.com/en-us/library/ms182536(v=vs.90).aspx
http://aspunit.sourceforge.net/
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.
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 https://aspclassiccompiler.codeplex.com/.
This is is an interesting read too. Just keep clicking the Next Post link at the top of the page
http://www.beingnew.net/2008/10/user-stories-for-classic-asp-unit.html
A few others I found
http://framework.lojcomm.com.br/app/docs/class.unittest/index/General.html
http://msdn.microsoft.com/en-us/library/ms182536(v=vs.90).aspx
http://aspunit.sourceforge.net/
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If nothing else, you have to love the payment page. http://remotedebugger.com/secureSSL.asp?startpage=order
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.
ASKER
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.
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