Help with debugging ASP

[keyser_Soze]

I have MS Visual Studio 2003 on Windows XP Pro. I have IIS running on
this machine and I am trying to debug some existing code which has both
ASP and ASP.NET components.

When I try and launch the debugger from VS, I am told it can't because
the project is of output type class library. The error indicates I
should set the start action to start external program or start URL.

I tried both of these and cannot seem to get the debugger to attach to
the process. However, I can load the webpage and surf to an error
which causes another session of VS to come up. Unfortunatly, the error
is not one that I can debug because I can not get break points to work
and the debugger will only come up when it hits the error.

My start page is default.asp and I have tried setting a break point in
it to no avail. How can I debug this script?

Thanks,

-KS

 

[Bob Barrows [MVP]]

I have MS Visual Studio 2003 on Windows XP Pro.

There was no way for you to know it, but this is a classic asp newsgroup.
While you may be lucky enough to find a dotnet-savvy person here who can
answer your question, you can eliminate the luck factor by posting your
question to a newsgroup where the dotnet-savvy people hang out. I suggest
microsoft.public.dotnet.framework.aspnet or
microsoft.public.vsnet.debugging.

Unfortunately I don't know the answer to your question, so I suggest posting
to a relevant newsgroup.

Bob Barrows

 

[keyser_Soze]

I had assumed since the first thing I wanted to debug was default.asp,
that this was classic ASP. Does the fact that I have both .asp and
..aspx files make the entire issue dotnet?

Thanks!

 

[Bob Barrows [MVP]]

I had assumed since the first thing I wanted to debug was default.asp,
that this was classic ASP. Does the fact that I have both .asp and
.aspx files make the entire issue dotnet?

It's the fact that it's Visual Studio.Net that makes it a Visual Studio.Net
issue.

I'm not even sure you _can_ debug classic asp code with vs.net, although I
may be mistaken. I would think you would need Visual Interdev, and even with
that program, the ability to debug server-side asp code has never been
reliable.

For an alternative, see:
http://support.microsoft.com/support/kb/articles/q288/9/65.asp

 

[Kyle Peterson]

you don't debug classic asp using a debugger.. pretty much all you can do is
use common sense and pay attention to where the error is and what line it is
at. If you are not seeing detailed error info server or web browser settings
are disabling or not showing it.

asp.net is a different story

both mixed together ? not possible in the same page for the most part unless
you got some whacked out things going on that you should not be doing.

 

[Bob Barrows [MVP]]

you don't debug classic asp using a debugger..

Actually, if you're lucky (and make the proper sacrifices) you can debug
server-side code with Visual Interdev. I had it working for awhile... but
then it stopped working and I could never make it work again. It's very
susceptible to FrontPage Server Extensions conflicts.

 

[Evertjan.]

Bob Barrows [MVP] wrote on 30 dec 2005 in
microsoft.public.inetserver.asp.general:

Actually, if you're lucky (and make the proper sacrifices) you can
debug server-side code with Visual Interdev. I had it working for
awhile... but then it stopped working and I could never make it work
again. It's very susceptible to FrontPage Server Extensions conflicts.

Visual Interdev and Frontpage are often used by people that don't want to
learn indepth ASP, and therefore wish for automatic debugging.

Experience learns that automatic debugging is impossible,
debugging needs manual breakpoints and a good knowledge of a language.

A debugger could detect syntax failures, but the larger part of bugs are
logical errors that only show at runtime and depend on the external input.

Simple, clean and straight forward programming code, which the above
progrmmes don't give, is a prerequisite for a good working and maintainable
code.

 

[Kyle Peterson]

same here with the problems.. I was a bit of an Interdev 1 and 6 expert back
in the day.
Ulitmately what they tried to do with Visual Interdev 6 was a failure and
half the shit in it did not work correctly.
It was object oriented before it was ready for primetime.

Over the years I just stuck to hand coding (and some in-house code wizards)
though I have to admit the latest versions of Dreamweaver are actually
pretty sweet for ASP work if you actually take the time to become familiar
with it which I never do.

 

[Dale]

Yes, you can debug ASP server-side script in VS2003. I do it regularly.

The hard part is not how to debug; it is figuring out how from the
documentation on MSDN. I'll give you a simplified version from memory so if
you can't decipher it, let me know and I'll go through the procedures and
take notes so I can be more specific.

1. Right clicke your project (the project, not the solution) in project
explorer and select properties.

2. On your VS2003 project properties window, debug settings, enable
debugging for ASP files.

3. In IIS manager, either at the default website or the specific site if
you only want to debug ASP in some sites and not in others, click the
Configure button just under the button where you enable the site application.

4. On the configuration applet, there is a checkbox to enable debugging of
ASP pages.

5. Add the appropriate users to the Debugger Users local group. This is
the tricky part, or was for me.

The instructions I followed said to add the IWAM acount to the group, which
didn't work. So then, I added the EVERYONE account, all of the available
network and system accounts, the IUSR account, and my own account. then I
could debug ASP.

Next, I started deleting accounts to see what I could do without. I deleted
the EVERYONE first, deleted all of the NETWORK and system type accounts
except the SYSTEM account since it was already in the group when I started,
and deleted the IUSR account. That left my own account and NT
AUTHORITY\SYSTEM. I debug ASP projects that use anonymous access and that
use Windows Authentication.

At that point, the list seemed reasonably short and I didn't try deleting
any more.

6. Set a breakpoint on server script in your asp files and debug to your
heart's content.

Since the security portion seems to be the hardes part, if my instructions
don't work for you, I suggest you do what I did: add everything under the
sun to the Debugger Users group and start removing until you have a short
working list left in the group.

Good luck.
--
Dale Preston
MCAD C#
MCSE, MCDBA

 

[Bob Barrows [MVP]]

Bob Barrows [MVP] wrote on 30 dec 2005 in
microsoft.public.inetserver.asp.general:


Visual Interdev and Frontpage

Not FrontPage: FrontPage server extensions.

are often used by people that don't
want to learn indepth ASP, and therefore wish for automatic debugging.

Maybe so, but the desire for debugging and the abiltiy to write "indepth
ASP" are not contradictory.

Experience learns that automatic debugging is impossible,

Not so. When it works, the Interdev debugger provides this. It's keeping it
working that's the issue...

debugging needs manual breakpoints

And I'm telling you that when it works, Interdev provides a full-fledged
debugger: breakpoints, watches, call stacks, Immediate window, everything
one would expect from a debugger.

and a good knowledge of a language.
A debugger could detect syntax failures, but the larger part of bugs
are logical errors that only show at runtime and depend on the
external input.

Simple, clean and straight forward programming code, which the above
progrmmes don't give,

Maybe they don't "give" it, but they don't prevent it either when used by a
knowledgeable programmer.

is a prerequisite for a good working and
maintainable code.

True.

 

[Bob Barrows [MVP]]

Yes, you can debug ASP server-side script in VS2003.

Classic ASP? Or ASP.Net? I regularly debug ASP.Net server-side code as well.
I've never tried with classic ASP code. Does it still require FrontPage
Server Extensions to be installed on the server?

 

[Evertjan.]

Bob Barrows [MVP] wrote on 30 dec 2005 in
microsoft.public.inetserver.asp.general:

And I'm telling you that when it works, Interdev provides a
full-fledged debugger: breakpoints, watches, call stacks, Immediate
window, everything one would expect from a debugger.

Ha Ha, Bob,

I could have expectd this.

My posting came from my gut feeling that most questions here about
ASP debuggers come from people that ask this BECAUSE of their
inability to debug by hand even simple code.

Good hand debugging, like temporarily inserting a home made
conditonal breakpoint:

if counter>17 then
response.write VbCrLf & "Breakpoint xx:<br>" & VbCrLf
response.write "a= " & a & "<br>" & VbCrLf
response.write "n= " & n & "<br>" & VbCrLf
response.end
end if

or hard coded data entry, like:

myData = request.form("myData")
myData = "17" ''''' temporary hard data, should be remarked away later

.... will be far more beneficial than the most expensive debugger
programme for THOSE people and their future programming.

I concede that a good debugger is a timesaver in the hands of experienced
ASP programmers having complex script code.

However debuggers are only essential in debugging [to be] compiled code,
because there the structure of the source code is lost in the executable.

 

[Dale]

I disagree. If you're not using a debugger to get you to where the problem
exists, you're not doing your employer justice with your time.

I think that most questions about debugging ASP code come from people whose
ASP applications are no longer simple and therefore it is much more efficient
to single-step through code, watching values as they do, and getting right to
the problem, rather than spending hours writing temporary code that they have
to later remember to get all of out of their application.

I know developers who write web applications in Notepad because they think
the IDEs are for code-sissies but they're wrong, too.

You stated that debuggers can catch syntax errors but that to find the
errors the code needs external input. You are incorrect. Compilers can find
syntax errors, not debuggers. Debuggers actually help you find the errors
while including the external input. Single stepping through your ASP code
and monitoring variable values while running with the real world input is
exactly how debuggers help the developer find the problem.

Knowledge of their development environment and available debuggers are
essential tools that belong in every developer's toolkit. If you can't use
the tools available, you're not providing full value to your employer or
customers.

--
Dale Preston
MCAD C#
MCSE, MCDBA

Bob Barrows [MVP] wrote on 30 dec 2005 in
microsoft.public.inetserver.asp.general:

And I'm telling you that when it works, Interdev provides a
full-fledged debugger: breakpoints, watches, call stacks, Immediate
window, everything one would expect from a debugger.

Ha Ha, Bob,

I could have expectd this.

My posting came from my gut feeling that most questions here about
ASP debuggers come from people that ask this BECAUSE of their
inability to debug by hand even simple code.

Good hand debugging, like temporarily inserting a home made
conditonal breakpoint:

if counter>17 then
response.write VbCrLf & "Breakpoint xx:<br>" & VbCrLf
response.write "a= " & a & "<br>" & VbCrLf
response.write "n= " & n & "<br>" & VbCrLf
response.end
end if

or hard coded data entry, like:

myData = request.form("myData")
myData = "17" ''''' temporary hard data, should be remarked away later

.... will be far more beneficial than the most expensive debugger
programme for THOSE people and their future programming.

I concede that a good debugger is a timesaver in the hands of experienced
ASP programmers having complex script code.

However debuggers are only essential in debugging [to be] compiled code,
because there the structure of the source code is lost in the executable.

 

[Dale]

I debug classic ASP and ASP.Net in the Visual Studio .Net 2003 debugger,
single-stepping through server side script of ASP pages, evaluating variable
values, and all the other things you can do in any other debugger.

I can't say whether or not the ASP debugging specifically requires FrontPage
server extensions since you can't install VIsual Studio .Net without having
FrontPage server extensions installed. It is impossible to try it without
them.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

 

[Dave Anderson]

I can't say whether or not the ASP debugging specifically requires
FrontPage server extensions since you can't install VIsual Studio
.Net without having FrontPage server extensions installed. It is
impossible to try it without them.

I think the point centers on whether those extensions are installed on the
SERVER, not on the developer's workstation.

IIRC, they are required on the server for WEBDAV to function. Perhaps this
is central to the issue.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

 

[Kyle Peterson]

Lots of big fancy words and explanations there but it is ultimately your
opinion.
I for one totally disagree but I am not going to sit here on the holidays
and write a report about it, thats for sure.

I disagree. If you're not using a debugger to get you to where the problem
exists, you're not doing your employer justice with your time.

I think that most questions about debugging ASP code come from people
whose
ASP applications are no longer simple and therefore it is much more
efficient
to single-step through code, watching values as they do, and getting right
to
the problem, rather than spending hours writing temporary code that they
have
to later remember to get all of out of their application.

I know developers who write web applications in Notepad because they think
the IDEs are for code-sissies but they're wrong, too.

You stated that debuggers can catch syntax errors but that to find the
errors the code needs external input. You are incorrect. Compilers can
find
syntax errors, not debuggers. Debuggers actually help you find the errors
while including the external input. Single stepping through your ASP code
and monitoring variable values while running with the real world input is
exactly how debuggers help the developer find the problem.

Knowledge of their development environment and available debuggers are
essential tools that belong in every developer's toolkit. If you can't
use
the tools available, you're not providing full value to your employer or
customers.

--
Dale Preston
MCAD C#
MCSE, MCDBA

Bob Barrows [MVP] wrote on 30 dec 2005 in
microsoft.public.inetserver.asp.general:

debugging needs manual breakpoints

And I'm telling you that when it works, Interdev provides a
full-fledged debugger: breakpoints, watches, call stacks, Immediate
window, everything one would expect from a debugger.

Ha Ha, Bob,

I could have expectd this.

My posting came from my gut feeling that most questions here about
ASP debuggers come from people that ask this BECAUSE of their
inability to debug by hand even simple code.

Good hand debugging, like temporarily inserting a home made
conditonal breakpoint:

if counter>17 then
response.write VbCrLf & "Breakpoint xx:<br>" & VbCrLf
response.write "a= " & a & "<br>" & VbCrLf
response.write "n= " & n & "<br>" & VbCrLf
response.end
end if

or hard coded data entry, like:

myData = request.form("myData")
myData = "17" ''''' temporary hard data, should be remarked away later

.... will be far more beneficial than the most expensive debugger
programme for THOSE people and their future programming.

I concede that a good debugger is a timesaver in the hands of experienced
ASP programmers having complex script code.

However debuggers are only essential in debugging [to be] compiled code,
because there the structure of the source code is lost in the executable.

 

[McKirahan]

[snip]

I know developers who write web applications in Notepad because they think
the IDEs are for code-sissies but they're wrong, too.

[snip]

Or possibly it's because Notepad is free and an IDE is not...

 

[Bob Barrows [MVP]]

I debug classic ASP and ASP.Net in the Visual Studio .Net 2003
debugger, single-stepping through server side script of ASP pages,
evaluating variable values, and all the other things you can do in
any other debugger.

I can't say whether or not the ASP debugging specifically requires
FrontPage server extensions since you can't install VIsual Studio
.Net without having FrontPage server extensions installed. It is
impossible to try it without them.

Well, that's not true. Our development server does not have them installed
and I have no problem debugging ASP.Net code. I have my doubts about classic
ASP code, but I will try it next week.

Bob Barrows

 

[Dale]

Which raises the proverbial question of which came first? The chicken or the
egg?

Perhaps you incorrectly stated that it isn't possible to debug ASP because
you don't like debuggers so never learned the possibilities or perhaps you
don't like debuggers because you have never used them to help you debug ASP?

Either way, it's an opinion you can't, by your own words, support from your
own experience. So yours is, at best, an opinion. Mine, for all you know,
might be fact.
--
Dale Preston
MCAD C#
MCSE, MCDBA

Lots of big fancy words and explanations there but it is ultimately your
opinion.
I for one totally disagree but I am not going to sit here on the holidays
and write a report about it, thats for sure.

I disagree. If you're not using a debugger to get you to where the problem
exists, you're not doing your employer justice with your time.

I think that most questions about debugging ASP code come from people
whose
ASP applications are no longer simple and therefore it is much more
efficient
to single-step through code, watching values as they do, and getting right
to
the problem, rather than spending hours writing temporary code that they
have
to later remember to get all of out of their application.

I know developers who write web applications in Notepad because they think
the IDEs are for code-sissies but they're wrong, too.

You stated that debuggers can catch syntax errors but that to find the
errors the code needs external input. You are incorrect. Compilers can
find
syntax errors, not debuggers. Debuggers actually help you find the errors
while including the external input. Single stepping through your ASP code
and monitoring variable values while running with the real world input is
exactly how debuggers help the developer find the problem.

Knowledge of their development environment and available debuggers are
essential tools that belong in every developer's toolkit. If you can't
use
the tools available, you're not providing full value to your employer or
customers.

--
Dale Preston
MCAD C#
MCSE, MCDBA

Bob Barrows [MVP] wrote on 30 dec 2005 in
microsoft.public.inetserver.asp.general:

debugging needs manual breakpoints

And I'm telling you that when it works, Interdev provides a
full-fledged debugger: breakpoints, watches, call stacks, Immediate
window, everything one would expect from a debugger.


Ha Ha, Bob,

I could have expectd this.

My posting came from my gut feeling that most questions here about
ASP debuggers come from people that ask this BECAUSE of their
inability to debug by hand even simple code.

Good hand debugging, like temporarily inserting a home made
conditonal breakpoint:

if counter>17 then
response.write VbCrLf & "Breakpoint xx:<br>" & VbCrLf
response.write "a= " & a & "<br>" & VbCrLf
response.write "n= " & n & "<br>" & VbCrLf
response.end
end if

or hard coded data entry, like:

myData = request.form("myData")
myData = "17" ''''' temporary hard data, should be remarked away later

.... will be far more beneficial than the most expensive debugger
programme for THOSE people and their future programming.

I concede that a good debugger is a timesaver in the hands of experienced
ASP programmers having complex script code.

However debuggers are only essential in debugging [to be] compiled code,
because there the structure of the source code is lost in the executable.

 

[Dale]

There are plenty of free IDEs for web development. Mozilla, if you don't
like Microsoft. WebMatrix, if you do. There are a few free open source IDEs
for Windows development in C# as well.

But, from my experience (and, lucky for me, my wife falls for this line when
it comes to my computer spending) the money spent on an IDE more than pays
for itself in increased productivity. I am a consultant and, for instance,
buy my own development tools, including MSDN subscriptions. $2600 this year.
But the financial benefit in increased contract rates has paid for that many
times over.

If I went to an interview with a potential client/employer and told them
that I could develop faster in Notepad than their fastest Visual Studio
developer, even if that was true, they'd laugh me out the door.

Sure, Notepad is free (but then so are the Express versions of Visual Studio
2005) but I don't know of anyone who is getting paid for developing in
Notepad. Except, perhaps, Charles Petzold. And I don't know of anyone who
could tell an IT manager in an interview that "real men don't use debuggers"
and get the job.

--
Dale Preston
MCAD C#
MCSE, MCDBA

[snip]

I know developers who write web applications in Notepad because they think
the IDEs are for code-sissies but they're wrong, too.

[snip]

Or possibly it's because Notepad is free and an IDE is not...