How can i view Debug.Write?

[Mike Brind]

We seem to have strayed a bit.

Create a file on your web-server:

DebugTest.asp
===========
<% Debug.WriteLine("Hello, world!") %>

Can someone please sum up the IIS options, the ASP options, the programs,
the program options required to view this debug output?


i happen to have the Microsoft Script Debugger installed on my local
machine; and if i have it running while the web-server executes
DebugTest.asp, i do not see any output (at least not in the Call Stack,
Running Documents or Command Windows.)

No - the dubugger has to be on the same machine where the page is
executed. This is why you have to select "Enable ASP server-side
script debugging". ASP scripts are not visible to the client like
client-side javascript is.

i also happen to have Microsoft Visual Studio 2005 installed, and if i have
it running while the web-server executes DebugTest.asp, i do not see any
output. The web-site is in "medium" security (application pooling) mode, and
i do not see any debug output if i have attached the debugger to
dllhost.exe - perhaps i don't have the proper window up in VS2005
(View..Output does not show anything at any rate)

i am (right now) using the Windows XP built-in IIS, and i have configured
the options under
Website
->Properties
-> Home Directory
-> Configuration
-> App Debugging
X Enable ASP server-side script debugging
X Enable ASP client-side script debugging

NOTE: You cannot use the "Internet Information Services" management tool
that comes with Windows XP to set these options, you must use the IIS admin
tool on a Windows Server machine and connect back to your local computer.
The symtpons of it not working are: nothing happens when you push the
"Configuration" button.

I have Windows XP Pro, IIS 5.1. I used the IIS management tool to
configure these options on my machine successfully. I created this
script:

<%
Stop
Debug.Write "Hello World"
Stop
%>

When I ran the page, 'Stop' invoked the debugger (VS2003 in my case) on
the same machine, then I installed the Script Debugger. When I ran the
page again, I got a list of apps to use to debug. When I stepped over
to the final "Stop", the output appeared in the command window of the
script debugger. It will appear in the Output window of VS 2003/5.

It would appear that you need to use the Stop statement to create a
breakpoint to interest the dubugging apps. Or, use the apps to create
the breakpoints. But you must have the app on the same machine as the
web server.

 

[Mike Brind]

No - the dubugger has to be on the same machine where the page is
executed. This is why you have to select "Enable ASP server-side
script debugging". ASP scripts are not visible to the client like
client-side javascript is.


I have Windows XP Pro, IIS 5.1. I used the IIS management tool to
configure these options on my machine successfully. I created this
script:

<%
Stop
Debug.Write "Hello World"
Stop
%>

When I ran the page, 'Stop' invoked the debugger (VS2003 in my case) on
the same machine, then I installed the Script Debugger. When I ran the
page again, I got a list of apps to use to debug. When I stepped over
to the final "Stop", the output appeared in the command window of the
script debugger. It will appear in the Output window of VS 2003/5.

It would appear that you need to use the Stop statement to create a
breakpoint to interest the dubugging apps. Or, use the apps to create
the breakpoints. But you must have the app on the same machine as the
web server.

But given all that, I think I shall continue to use <% Response.Write()
%> to debug my asp files

 

[Michael Kujawa]

Does Debug console give you more information then err.description?
<%
if err.number > 0 then
response.write "Err Number: " & err.number "<br>"
response.write err.description
%>

If it does not then while go through all that hassle?

 

[Ian Boyd]

Does Debug console give you more information then err.description?

<%
if err.number > 0 then
response.write "Err Number: " & err.number "<br>"
response.write err.description
%>

If it does not then while go through all that hassle?

Yes, it's hard to understand why people moved away from print statements and
embraced breakpoints and tracing.

 

[Michael Kujawa]

I use Debug and trace all the time outside of web
for "Desktop Application" development with VFP

I just do not see the sense with asp as an error will
normally end the server process and throw an error
description.

I can test on my end with IIS of course, but when the
files are uploaded to a server and you do not have access
to a the debug console on the remote IIS server, or the asp
server is actually a Unix or Linux Box running chilisoft ASP
what good would running a debug session do you then?

Not trying to start something here I was just curious if the
Debug console gave you more useful information and what
if any practically it has when you cannot access the remote IIS
server.

 

[Mike Brind]

It gave me LESS information. It doesn't give me an error number - just
the description. Makes googling for solutions a little more
interesting...

 

[Ian Boyd]

just curious if the

Debug console gave you more useful information and what
if any practically it has when you cannot access the remote IIS
server.

Problem is, there is no error. There's a logical problem. So ideally i would
trace the ASP, but the version of Visual Studio i convinced the company to
purchase does not support ASP, even more so on a separate Windows 2000
server machine.

i could use Response.Writes, except that doing that puts extra strings in
the response text sent back to the browser, which sometimes breaks things,
and other times just isn't even visible.

Desired solutions, in order of preference:
1. Debugger with tracing, expression evaluation and watches
2. Logging of trace info
3. Print

 

[Bob Barrows [MVP]]

Problem is, there is no error. There's a logical problem. So ideally
i would trace the ASP, but the version of Visual Studio i convinced
the company to purchase does not support ASP, even more so on a
separate Windows 2000 server machine.

i could use Response.Writes, except that doing that puts extra
strings in the response text sent back to the browser, which
sometimes breaks things, and other times just isn't even visible.

Anything sent to the browser via Response will always be visible in the
source (right-click-->View Source)
To avoid "breaking things", write the values into hidden fields, or into
divs whose css display property is set to none:

response.write "<div id=""debug"" style=""display:none"">"
response.write "debugging information"
response.write "</div>"

View the source to see the results.

Desired solutions, in order of preference:
1. Debugger with tracing, expression evaluation and watches
2. Logging of trace info
3. Print

4. vbscript debugger class -
http://support.microsoft.com/kb/299986/EN-US/

 

[Michael Kujawa]

Hi Ian,

I use a SQL table to trace and store expression evals
during development of complex functions for a site. I have
subroutines setup to generate appends to the table. I know
waiting for the page to download from the server can sometimes
take a long time.

It makes it easy to see the actual calculation / eval results that
are performed serverside by looking at the table via Enterprise
Manager. I do not have to wait until the page is processed and
delivered to see what is happening as the subroutines append
and update the table during the process.

I don't always do this but when I need to it works well. After I
am finished testing I remove the sub-routines.

Mike K

 

[Ian Boyd]

To avoid "breaking things", write the values into hidden fields, or into

divs whose css display property is set to none:

response.write "<div id=""debug"" style=""display:none"">"
response.write "debugging information"
response.write "</div>"

Assuming that at the time the DIV happens to come down we are inside the
HTML body, the xhtml body, or that we are in HTML at all.
Or that the reponse output isn't buffered, and a the response hasn't been
cleared.
Or that the browser hasn't subsequently been sent a redirect and so there is
no longer any source to see.

4. vbscript debugger class -
http://support.microsoft.com/kb/299986/EN-US/

i don't understand what this is doing. Is it just really obfuscated
Response.Write's?

 

[Ian Boyd]

I use a SQL table to trace and store expression evals

during development of complex functions for a site. I have
subroutines setup to generate appends to the table. I know
waiting for the page to download from the server can sometimes
take a long time.

i tried creating a COM Object that only calls OutputDebugString, but for
some reason the console session on the Windows Server machine cannot see the
output debug strings generated from the IWAM session.

 

[Bob Barrows [MVP]]

Assuming that at the time the DIV happens to come down we are inside
the HTML body, the xhtml body, or that we are in HTML at all.
Or that the reponse output isn't buffered, and a the response hasn't
been cleared.
Or that the browser hasn't subsequently been sent a redirect and so
there is no longer any source to see.

Good points. Although these can be mitigated by using Response.Flush
where appropriate, or logging to a server-side text file (a technique I
use quite often) where not appropriate.

i don't understand what this is doing. Is it just really obfuscated
Response.Write's?

Pretty much. I posted it under the assumption that you were still unable
to get the debugger working.

 

[Michael Kujawa]

I suppose, even though it maybe possible
to use the debug console in a limited way, my guess
is you are finding out that asp really is best debugged
by response.writes or db appends during the process.

It seems at least according to this thread that using the
debug console is a hassle and not really reliable. Maybe
that is why not to many even thought it was possible.

I am sure if it was practical to use it, this group or google
archives would be filled with posts saying to use it.

 

[Anthony Jones]

I suppose, even though it maybe possible
to use the debug console in a limited way, my guess
is you are finding out that asp really is best debugged
by response.writes or db appends during the process.

It seems at least according to this thread that using the
debug console is a hassle and not really reliable. Maybe
that is why not to many even thought it was possible.

I am sure if it was practical to use it, this group or google
archives would be filled with posts saying to use it.

That's right. I would be one of them. In my view if you're a serious
developer then you need serious tools. Response.Write can be useful and for
some hosted and production situations you're only choice. However for
general development and debugging nothing matches VS running on a local
machine against a local development version of the site.

 

[Michael Kujawa]

That's right. I would be one of them. In my view if you're a serious
developer then you need serious tools. Response.Write can be useful and for
some hosted and production situations you're only choice. However for
general development and debugging nothing matches VS running on a local
machine against a local development version of the site.

True,

VS I suppose maybe be best. But I have never used it.
I myself have never used anything but notepad for includes
and DW / NOF for layout, local IIS / SQL for testing.

Although, I am considering biting the bullet and purchasing a
copy of VS. I have some very complex projects coming up
and VS may be right for those projects. Hopefully there
is not a long learning or unlearning curve?

 

[Bob Barrows [MVP]]

True,

VS I suppose maybe be best. But I have never used it.
I myself have never used anything but notepad for includes
and DW / NOF for layout, local IIS / SQL for testing.

Although, I am considering biting the bullet and purchasing a
copy of VS. I have some very complex projects coming up
and VS may be right for those projects. Hopefully there
is not a long learning or unlearning curve?

No. you'll find yourself wondering how you ever did without it.

 

[Mike Brind]

No. you'll find yourself wondering how you ever did without it.

Bob, or Anthony (or anyone who primarily uses VS) - could you explain
the main features of VS that you find indispensible in classic ASP
development?

Thanks

 

[Anthony Jones]

Bob, or Anthony (or anyone who primarily uses VS) - could you explain
the main features of VS that you find indispensible in classic ASP
development?

First and fore most the ability to step the code line by line to see exactly
what is going on.

Being able to examine the state of variables as they change and the ability
to modify them. The problem with a Response.Write approach is that it's
still a trial and error approach. By having the code stepped in a debugger
you can see when for example a piece of SQL is built incorrectly and why.
You can then correct that SQL and continue stepping. In this way a single
run through the code can reveal multiple errors in detail in one pass.

Also being able to set break points on not just a line but also the state of
a variable. If I have a large loop that errors only when a variable has a
certain value I can set up a break for that condition then step to see why
things are going pear shaped.

Another window I find invaluable is the call stack window. Very often a
problem in code is due to logic problem above the function where the error
occurred. The ability to see how the code arrived at certain point and
being able examine the contents of all the local variables in each of the
calling procedures is also very useful.

 

[Bob Barrows [MVP]]

Bob, or Anthony (or anyone who primarily uses VS) - could you explain
the main features of VS that you find indispensible in classic ASP
development?

Anthony extolled on the virtues of the debugger (which frankly, I rarely use
for server-side code because it rarely works on my development server, which
my workplace requires me to use - when I do need to use it, I have to copy
my project to my personal machine, debug it and make corrections to the code
on the development server - very unwieldy, so I mainly use the
response.write approach).

I've used both Notepad and VS for development. Having used VS, I will never
go back to Notepad by choice. The reasons?
1. Integration with the MSDN library and Platform SDK for context-sensitive
help
2. Intellisense - yes there are times it gets in the way, but I'm constantly
using ctrl-space to autocomplete words
3. Color-coding of statements: comments are green, <% have yellow
background, string literals are maroon ...
5. Right-click -> View in browser
6. Solution Explorer - having a solution containing all the projects
(websites) that I will need to work on in one place. For example, I will
typically have a solution containing the development, QA and production
versions of a site, making deployment very simple.
7. Integrated source control

There's more but i need to move on.

 

[Mike Brind]

Anthony extolled on the virtues of the debugger (which frankly, I rarely use
for server-side code because it rarely works on my development server, which
my workplace requires me to use - when I do need to use it, I have to copy
my project to my personal machine, debug it and make corrections to the code
on the development server - very unwieldy, so I mainly use the
response.write approach).

I've used both Notepad and VS for development. Having used VS, I will never
go back to Notepad by choice. The reasons?
1. Integration with the MSDN library and Platform SDK for context-sensitive
help
2. Intellisense - yes there are times it gets in the way, but I'm constantly
using ctrl-space to autocomplete words
3. Color-coding of statements: comments are green, <% have yellow
background, string literals are maroon ...
5. Right-click -> View in browser
6. Solution Explorer - having a solution containing all the projects
(websites) that I will need to work on in one place. For example, I will
typically have a solution containing the development, QA and production
versions of a site, making deployment very simple.
7. Integrated source control

There's more but i need to move on.

I was trying to work out if there is any reason I should be looking to
switch from Dreamweaver 8. At the moment there is nothing compelling
in the list you have provided. They are all good features, but DW
offers most of them:

Intellisense - to a lesser degree
Colour coding
Solution Explorer (Site Manager)
Source Control (which as a single developer I don't use)

but it also has some other very good features:

Support for PHP files (which I use sometimes)
A great CSS feature where the styles you define are displayed (with
styling) in a drop down list for application to elements
The html contents of include files are displayed in Design View.
.....