«

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

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

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

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!

wrote:
> 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.../q288/9/65.asp

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

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.


<> wrote in message
news: oups.com...
>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
>

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

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

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

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

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.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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



"Bob Barrows [MVP]" <> wrote in message
news:...
> Kyle Peterson wrote:
>> 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.
>
> --
> Microsoft MVP - ASP/ASP.NET
> Please reply to the newsgroup. This email account is my spam trap so I
> don't check it very often. If you must reply off-line, then remove the
> "NO SPAM"
>

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


"Evertjan." wrote:

> Bob Barrows [MVP] wrote on 30 dec 2005 in
> microsoft.public.inetserver.asp.general:
>
> > Kyle Peterson wrote:
> >> 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.
> >
>
> 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.
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)
>

Evertjan. wrote:
> Bob Barrows [MVP] wrote on 30 dec 2005 in
> microsoft.public.inetserver.asp.general:
>
>> Kyle Peterson wrote:
>>> 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.
>>
>
> 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.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"