Help with debugging ASP

Discussion in 'ASP General' started by keyser_Soze@usa.com, Dec 29, 2005.

  1. Guest

    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
     
    , Dec 29, 2005
    #1
    1. Advertising

  2. 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.
     
    Bob Barrows [MVP], Dec 29, 2005
    #2
    1. Advertising

  3. Guest

    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!
     
    , Dec 29, 2005
    #3
  4. 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/kb/articles/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.
     
    Bob Barrows [MVP], Dec 29, 2005
    #4
  5. 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:...
    >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, Dec 29, 2005
    #5
  6. 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], Dec 29, 2005
    #6
  7. Evertjan. Guest

    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., Dec 29, 2005
    #7
  8. 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.



    "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"
    >
     
    Kyle Peterson, Dec 30, 2005
    #8
  9. Dale Guest

    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)
    >
     
    Dale, Dec 30, 2005
    #9
  10. 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"
     
    Bob Barrows [MVP], Dec 30, 2005
    #10
  11. Dale wrote:
    > 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?



    --
    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], Dec 30, 2005
    #11
  12. Evertjan. Guest

    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.

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Dec 30, 2005
    #12
  13. Dale Guest

    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


    "Evertjan." wrote:

    > 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.
    >
    > --
    > Evertjan.
    > The Netherlands.
    > (Please change the x'es to dots in my emailaddress)
    >
     
    Dale, Dec 30, 2005
    #13
  14. Dale Guest

    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


    "Bob Barrows [MVP]" wrote:

    > Dale wrote:
    > > 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?
    >
    >
    >
    > --
    > 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"
    >
    >
    >
     
    Dale, Dec 30, 2005
    #14
  15. Dale wrote:
    > 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.
     
    Dave Anderson, Dec 30, 2005
    #15
  16. 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.



    "Dale" <> wrote in message
    news:D...
    >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
    >
    >
    > "Evertjan." wrote:
    >
    >> 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.
    >>
    >> --
    >> Evertjan.
    >> The Netherlands.
    >> (Please change the x'es to dots in my emailaddress)
    >>
     
    Kyle Peterson, Dec 30, 2005
    #16
  17. McKirahan Guest

    "Dale" <> wrote in message
    news:D...

    [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...
     
    McKirahan, Dec 30, 2005
    #17
  18. Dale wrote:
    > 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
    --
    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], Dec 31, 2005
    #18
  19. Dale Guest

    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


    "Kyle Peterson" wrote:

    > 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.
    >
    >
    >
    > "Dale" <> wrote in message
    > news:D...
    > >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
    > >
    > >
    > > "Evertjan." wrote:
    > >
    > >> 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.
    > >>
    > >> --
    > >> Evertjan.
    > >> The Netherlands.
    > >> (Please change the x'es to dots in my emailaddress)
    > >>

    >
    >
    >
     
    Dale, Dec 31, 2005
    #19
  20. Dale Guest

    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


    "McKirahan" wrote:

    > "Dale" <> wrote in message
    > news:D...
    >
    > [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...
    >
    >
    >
     
    Dale, Dec 31, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sean
    Replies:
    1
    Views:
    588
  2. Johann Blake
    Replies:
    1
    Views:
    1,208
    Hermit Dave
    Jan 5, 2004
  3. Jim Bancroft
    Replies:
    1
    Views:
    475
    Scott Allen
    Jan 24, 2005
  4. jacob navia

    Debugging C vs debugging C++

    jacob navia, Oct 26, 2006, in forum: C Programming
    Replies:
    11
    Views:
    595
    Ian Collins
    Oct 27, 2006
  5. AAaron123
    Replies:
    3
    Views:
    668
    AAaron123
    Jul 28, 2009
Loading...

Share This Page