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

keyser_S***@usa.com wrote:
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

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!

keyser_S***@usa.com wrote:
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

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.


<keyser_S***@usa.com> wrote in message
Show quoteHide quote

Kyle Peterson wrote:
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.

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

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.

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.
Show quoteHide quote

Dale wrote:
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?

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
Show quoteHide quote

Dale wrote:
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.

Dale wrote:
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

I've always felt there was a fallacy in this debugging process, since
the same result is achieved by response.writes of the key variables in
most cases.  Primal Script actually allowed a better debugging
process, but even then, there's a lot less debugging that you can do
(or have to do) in Classic ASP than .NET or C or any other
environment.

Of course, when I started doing any programming you basically had no
debuggeres anywhere, so I guess it's what you get used to...  :)

Jeff

Show quoteHide quote

Evertjan. wrote:
Show quoteHide quoteNot FrontPage: FrontPage server extensions.

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

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

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.

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

True.

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

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

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.

Show quoteHide quote

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.



Show quoteHide quote

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.
Show quoteHide quote

[snip]

[snip]

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

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.

Show quoteHide quote

[snip]

[snip]

Now you know another.

Hello everyone,

I thought I would chime in here since I have been around the ASP scene as
long as anyone out there. Never been a big player in the newsgroups but I
have made appearances over the years.

When I 1st started using ASP all that was available was Visual Interdev 1.
It was difficult to even figure out how to use and some of the Design Time
Controls in it had issues. I basically had to come up with way to code on my
own. Then came along Visual Interdev 6 and my company at the time sent
myself and two other guys to a 2 day 32x training seminar in Long Island. I
ate a lot of really good cookies at that seminar and met some really smart
people but Visual Interdev 6 turned out to be a frigin nightmare. They tried
to make everything all object oriented and it really did not work out. We
stopped Interdev 6 it at the company I worked at. Otherwise we would have
never got anything productive done.

Over the years debugging sort of became a manual process and to be honest I
have never had much of a reason to debug with classic ASP. A few issues come
up now and then and you check out the line error, response write something
out, maybe do a response.end and you figure out the problem pretty quickly.
Like someone said above you get used to that and to tell you the truth it is
not a hassle or a problem whatsoever in my mind.

Then newer versions of visual studio come out and becomes possible to debug.
I have spent a lot of time with it. I find the debuggin to be a pain in the
ass, it slows me down, and I can write faster/better code with some of the
in house code generators and tools I have developed over the years than
using the features of the VS IDE. I don't edit strictly in notepad per say.
I generally use a nice editor like dreamweaver or visual studio strictly for
the color coding. I use wysiwyg editors sometimes to speed up the process of
html generation but I am comfortable in the middle of any complex notepad
code situation if I get stuck there. I basically use whatever tool, code
snippet, book, or article in my possesion to get the job done.

Someone on here said that if someone isn't using the VS.NET IDE and
debugging with their classic asp that they are not doing their company
justice or something like that. What a bunch of horsesh*t that is. Most of
the top guys in the classic ASP world use a little bit of everything to
design their code and have a great library of collected goodies from over
the years that makes them better at what they do than anyone out there.
Anyone that puts all their faith in one IDE is making a mistake. Anyone that
says you should be debugging classic asp code with VS.NET or you are not
doing your company justice making a pretty strong statement.

Now, I am big into ASP.NET as well and yes I pretty much use
Visual.Studio.NET with that and yes I use all the code behind, webforms,
debugging features.. etc etc  And it all works nicely, but something about
debugging classic asp in that envirnoment seems to me to be flat out ODD. It
is more work to set it all up than it is even worth in the 1st place and
classic ASP was never meant to be taken to that level nor is there any
reason to debug all that much if you have half a clue what you are doing.

As far as my business goes. More than selling a few software apps I spend
most of my time as private contractor doing large programming jobs here and
there. I am quite busy, get paid fairly high dollar, and never have had any
company have any issues with how I code or the fact that I do not debug in
VS.NET. My most recent 3 jobs were with Pitney Bowes, Lockheed Martin , and
Symbol Technologies and they were all extremely satified with the work I did
for them. I totally expect repeat work and I have plenty to do in the months
to come. I guess I am not doing these places justice since I don't debug my
ASP code in VS.NET.   Yeah Right !!

Take Care,

Chris Williams
http://www.cjwsoft.com/about.asp







Show quoteHide quote

Christopher Williams wrote:
LOL Some??

Or just use the html elements, right?

I'm not sure I understand why. Interdev is still a pretty good code editor
as long as you delete the _ScriptLibrary folder from every project you
create. Why pay for another code editor if you already have a pretty good
one.

I tried one project using the DTC's and failed miserably (yeah, the DTC's
sucked). Since then, I've used everything but DTC's in Interdev. Source
control, code highlighting, Intellisense, autocompletion, debugging (when it
worked) all improved my productivity. Given that we had a MSDN subscription,
we never had a reason to pay for any other code editor. However, one of the
other developers on our staff started using FrontPage and Dreamweaver ...
there isn't a singe one of his apps I haven't had to rewrite since he left
the company.

While debugging worked, I loved it, and I miss it now that it's stopped
working (not enough to spend several days trying to get it to work again
<wink>). But, as you said, there are other ways to debug

So, I like VI6, but YMMV.

Bob Barrows
PS. Dreamweaver, Ultradev, etc have similar code bloat/poor code issues with
many of their builtin controls, so I don't see them as
a huge improvement over VI6.

Error with XML DOM parsing the Request object
call url while keep form parameters
Error while calling stored procedure from asp page
opening bianry files from hard disk
ServerXMLHTTP and impersonation