473,322 Members | 1,425 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

How can i view Debug.Write?

IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?
Jun 2 '06 #1
46 24067

Ian Boyd wrote:
IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?


<%
Response.Write "Hello World"
%>

--
Mike Brind

Jun 2 '06 #2

"Mike Brind" <pa*******@hotmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...

Ian Boyd wrote:
IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?


<%
Response.Write "Hello World"
%>

I will always cherish the initial misconceptions I had about you.
Jun 2 '06 #3

Ian Boyd wrote:
"Mike Brind" <pa*******@hotmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...

Ian Boyd wrote:
IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?


<%
Response.Write "Hello World"
%>

I will always cherish the initial misconceptions I had about you.


That's gone wayyyyyyyyy over my head.

--
Mike Brind

Jun 2 '06 #4
Ian Boyd wrote:
IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?

I know of no debugger for classic ASP-based script that supplies a Debug
object similar to the one used in VB, which is what I presume you are
talking about. As Mike says, you pretty much have to resort to
Response.write, of create your own custom debugging class:
http://support.microsoft.com/kb/299986/EN-US/
--
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.
Jun 2 '06 #5

Mike Brind wrote:
Ian Boyd wrote:
"Mike Brind" <pa*******@hotmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...

Ian Boyd wrote:
> IIS5, on a Windows 2000 Server machine.
>
> Debeg.WriteLine "Hello, world!"
>
>
> How can i view it?

<%
Response.Write "Hello World"
%>

I will always cherish the initial misconceptions I had about you.


That's gone wayyyyyyyyy over my head.


Oh, hold on a minute. I Googled your odd phrase, and it appears to be
some kind of sarcastic put-down. So I asked myself why I had earned
that reaction, and did a bit more googling.

Now I kind of thought that you were coming from a VBA/VB6 direction,
and trying to apply those debugging practices to classic asp, hence my
answer. At first, I didn't spot that your post had changed from
debug.write in the subject to debeg[sic].writeLINE in the body, but
debug.writeline is used in VB.NET (maybe other places as well, for all
I know), which suggests to me that you are using ASP.NET.

If that's the case, you're in the wrong group, and I select number 3 in
the this list (http://www.pushback.com/fun/BestComebacks.html) for you.

--
Mike Brind

Jun 2 '06 #6
> IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?

<%
Response.Write "Hello World"
%>

Let me clarify.

i'm coming into "ASP Programming" from C/C++ WinAPI programming.

It turns out that "ASP code" is actually VBScript, and it looks like the ASP
ISAPI extension for IIS uses the windows scripting engine. One of the
features available in the VBScripting engine is an intrinsic object called
Debug, which has two useful methods
Debug.Write
and
Debug.WriteLine

Unfortunaly, i cannot find where the ASP ISAPI extension for IIS puts the
"console output" on the web server; it doesn't output it as
OutputDebugStrings. Nor can i find any generally available "console" for
IIS.
Referring to your answer to my question: how does <%Response.Write()%> help
me view the output of Debug.Write?

If that's the case, you're in the wrong group, and I select number 3 in
the this list (http://www.pushback.com/fun/BestComebacks.html) for you.


Good show old man, very well played.

Jun 3 '06 #7
> I know of no debugger for classic ASP-based script that supplies a Debug
object similar to the one used in VB


It's not VB, it's VBScript

http://msdn.microsoft.com/library/de...c2d3d5e6fb.asp
ASP uses the scripting engine. The scripting engine has "console output".
Where does the ASP ISASP plugin for IIS, which is hosting the scripting
engine, redirect any "console" output to?

Jun 3 '06 #8
Ian Boyd wrote on 03 jun 2006 in
microsoft.public.inetserver.asp.general:
It turns out that "ASP code" is actually VBScript,
No,
the ASP platform supports two scripting languages: VBscript and Jscript.
and it looks like
the ASP ISAPI extension for IIS uses the windows scripting engine. One
of the features available in the VBScripting engine is an intrinsic
object called Debug, which has two useful methods
Debug.Write
As ASP is on a server, it has no intrinsic console/human interface,
and a serverside output is not available.

The debug object would have no output so is not implemented.
Referring to your answer to my question: how does <%Response.Write()%>
help me view the output of Debug.Write?


<% Response.Write('Hello world') %>
or
<% = 'Hello world' %>
being minimal Jscript

<% Response.Write "Hello world" %>
or
<% = "Hello world" %>
being minimal VBscript
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jun 3 '06 #9
Ian Boyd wrote:
I know of no debugger for classic ASP-based script that supplies a
Debug object similar to the one used in VB
It's not VB, it's VBScript

Umm, read my sentence again. Where did I say that I thought you were using
VB in ASP?

ASP uses the scripting engine. The scripting engine has "console
output".
But ASP doesn't, so this is not implemented.
Where does the ASP ISASP plugin for IIS, which is hosting the
scripting engine, redirect any "console" output to?


I just tried to debug a vbs file (using the debugger available in VS2003)
containing a debug.write statement and nothing appearred in the Immediate
window. Are you sure this works for vbscript files?

--
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"
Jun 3 '06 #10

Ian Boyd wrote:
IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?

<%
Response.Write "Hello World"
%>

Let me clarify.

i'm coming into "ASP Programming" from C/C++ WinAPI programming.

It turns out that "ASP code" is actually VBScript,


There is no such thing as "ASP code" as such, in just the same way as
there is no such thing as Dotnet code, for example. ASP is a
server-side technology for dynamically outputting html to the browser.
As Evertjan says, ASP supports a number of scripting languages.
VBScript is one of them, JScript, Javascript and Perl are others.

and it looks like the ASP ISAPI extension for IIS uses the windows scripting engine. One of the
features available in the VBScripting engine is an intrinsic object called
Debug, which has two useful methods
Debug.Write
and
Debug.WriteLine

Unfortunaly, i cannot find where the ASP ISAPI extension for IIS puts the
"console output" on the web server; it doesn't output it as
OutputDebugStrings. Nor can i find any generally available "console" for
IIS.
That's because there is no console output in ASP. As I said in my
first post (which you completely dismissed), you have to output html to
a browser to debug your code. You do that by utilising the Response
object's Write method.


Referring to your answer to my question: how does <%Response.Write()%> help
me view the output of Debug.Write?


Debug.Write/WriteLine does not exist in ASP. Response.Write is its
equivalent.

Have you looked at ASP.NET instead? It might be a lot closer to what
you are used to. I would suggest that the learning curve for dotnet
wouldn't be so steep for you. It probably won't test your patience so
much.

--
Mike Brind

Jun 3 '06 #11

"Ian Boyd" <ia***********@avatopia.com> wrote in message
news:Od**************@TK2MSFTNGP02.phx.gbl...
IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?

<%
Response.Write "Hello World"
%>

Let me clarify.

i'm coming into "ASP Programming" from C/C++ WinAPI programming.

It turns out that "ASP code" is actually VBScript, and it looks like the

ASP ISAPI extension for IIS uses the windows scripting engine. One of the
features available in the VBScripting engine is an intrinsic object called
Debug, which has two useful methods
Debug.Write
and
Debug.WriteLine

Unfortunaly, i cannot find where the ASP ISAPI extension for IIS puts the
"console output" on the web server; it doesn't output it as
OutputDebugStrings. Nor can i find any generally available "console" for
IIS.

Dunno what "OutputDebugStrings" is, however it works fine for me in the VS
2003 output window.

See:-

http://msdn.microsoft.com/library/de...f9bbf74e41.asp


Referring to your answer to my question: how does <%Response.Write()%> help me view the output of Debug.Write?

It doesn't.
If that's the case, you're in the wrong group, and I select number 3 in
the this list (http://www.pushback.com/fun/BestComebacks.html) for you.


Good show old man, very well played.

Jun 3 '06 #12

"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote in message
news:eW**************@TK2MSFTNGP02.phx.gbl...
Ian Boyd wrote:
I know of no debugger for classic ASP-based script that supplies a
Debug object similar to the one used in VB
It's not VB, it's VBScript

Umm, read my sentence again. Where did I say that I thought you were

using VB in ASP?


ASP uses the scripting engine. The scripting engine has "console
output".
But ASP doesn't, so this is not implemented.
Where does the ASP ISASP plugin for IIS, which is hosting the
scripting engine, redirect any "console" output to?


I just tried to debug a vbs file (using the debugger available in VS2003)
containing a debug.write statement and nothing appearred in the Immediate
window. Are you sure this works for vbscript files?


Use the output window set to debug (which is the only choice you have when
debugging ASP).
--
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"

Jun 3 '06 #13
Anthony Jones wrote:

I just tried to debug a vbs file (using the debugger available in
VS2003) containing a debug.write statement and nothing appearred in
the Immediate window. Are you sure this works for vbscript files?


Use the output window set to debug (which is the only choice you have
when debugging ASP).

I wasn't debugging ASP. I was debugging a file called test.vbs. No ASP
involved.

It had just 3 lines:

stop
debug.write "test"
stop

But you're right. It somehow switched away from the output window without my
noticing it. I just tried again and, when I switched back to the output
window, the "test" was written to it. So it is certainly possible to use
debug.write in a vbs file.

Now to try it in ASP ...

--
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"
Jun 3 '06 #14
Anthony Jones wrote:
Use the output window set to debug (which is the only choice you have
when debugging ASP).


You're right. It does work when debuggin an ASP process. Sorry Ian.
--
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"
Jun 3 '06 #15

Mike Brind wrote:
Ian Boyd wrote:
IIS5, on a Windows 2000 Server machine.

Debeg.WriteLine "Hello, world!"
How can i view it?

<%
Response.Write "Hello World"
%>

Let me clarify.

i'm coming into "ASP Programming" from C/C++ WinAPI programming.

It turns out that "ASP code" is actually VBScript,


There is no such thing as "ASP code" as such, in just the same way as
there is no such thing as Dotnet code, for example. ASP is a
server-side technology for dynamically outputting html to the browser.
As Evertjan says, ASP supports a number of scripting languages.
VBScript is one of them, JScript, Javascript and Perl are others.

and it looks like the ASP
ISAPI extension for IIS uses the windows scripting engine. One of the
features available in the VBScripting engine is an intrinsic object called
Debug, which has two useful methods
Debug.Write
and
Debug.WriteLine

Unfortunaly, i cannot find where the ASP ISAPI extension for IIS puts the
"console output" on the web server; it doesn't output it as
OutputDebugStrings. Nor can i find any generally available "console" for
IIS.


Large portion of humble pie for me please.

Go to the properties of your application in IIS Management Console, and
click on the Configuration button. On the App Debugging tab, select
"Enable ASP server-side script debugging". That brings the Microsoft
Script Debugger into play (it's installed as part of IIS on Win 2000),
and will display error messages etc on the server (which is what you
asked for). You can start the debugger by using the code that Bob
showed, or by selecting it from Start -> Programs ->Accessories.

I'm not sure that Debug.Write works, but the command window allows you
to test the value of variables by typing ?variablename. I can't test
the Script Debugger, because I have VS 2003 installed on my machine,
and that seems to have replaced the script debugger - if I indeed ever
had it on XP Pro.

You have my apologies, of course.

--
Mike Brind

Jun 3 '06 #16

Mike Brind wrote:
Mike Brind wrote:
Ian Boyd wrote:
> IIS5, on a Windows 2000 Server machine.
>
> Debeg.WriteLine "Hello, world!"
>
>
> How can i view it?
>
> <%
> Response.Write "Hello World"
> %>
Let me clarify.

i'm coming into "ASP Programming" from C/C++ WinAPI programming.

It turns out that "ASP code" is actually VBScript,


There is no such thing as "ASP code" as such, in just the same way as
there is no such thing as Dotnet code, for example. ASP is a
server-side technology for dynamically outputting html to the browser.
As Evertjan says, ASP supports a number of scripting languages.
VBScript is one of them, JScript, Javascript and Perl are others.

and it looks like the ASP
ISAPI extension for IIS uses the windows scripting engine. One of the
features available in the VBScripting engine is an intrinsic object called
Debug, which has two useful methods
Debug.Write
and
Debug.WriteLine

Unfortunaly, i cannot find where the ASP ISAPI extension for IIS puts the
"console output" on the web server; it doesn't output it as
OutputDebugStrings. Nor can i find any generally available "console" for
IIS.


Large portion of humble pie for me please.

Go to the properties of your application in IIS Management Console, and
click on the Configuration button. On the App Debugging tab, select
"Enable ASP server-side script debugging". That brings the Microsoft
Script Debugger into play (it's installed as part of IIS on Win 2000),
and will display error messages etc on the server (which is what you
asked for). You can start the debugger by using the code that Bob
showed, or by selecting it from Start -> Programs ->Accessories.

I'm not sure that Debug.Write works,


It does. I downloaded the debugger from microsoft, and debug.write
outputs to the command window.

--
Mike Brind

Jun 4 '06 #17
Mike Brind wrote:
I'm not sure that Debug.Write works,


It does. I downloaded the debugger from microsoft, and debug.write
outputs to the command window.

Yeah, i had never tried it. I alwasy just assumed it wouldn't work.
--
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"
Jun 4 '06 #18
> Debeg.WriteLine "Hello, world!"

How can i view it?


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

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've never written VBScript outside of ASP. i've never used the Microsoft
Script Debugger outside of debugging Javascript from Internet Explorer.
Jun 5 '06 #19
Ian Boyd wrote:
Debeg.WriteLine "Hello, world!"

How can i view it?
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?

In IIS Manager, set Application protection to Low, and go into the
Application properties and enable debugging.
I used a Stop statement in the code to force the debugger to attach to
the process.
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.)
I can't seem to make the debugger run standalone, but since you seem to
have discovered this trick, you need to attach the debugger to the asp
process being run. Using a Stop statement in the code makes this happen.

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.


Have you attached it to the process? Look at the Debug menu, which
should contain an Attach to Process option.

--
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.
Jun 5 '06 #20

Ian Boyd wrote:
Debeg.WriteLine "Hello, world!"

How can i view it?
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

Jun 5 '06 #21

Mike Brind wrote:
Ian Boyd wrote:
Debeg.WriteLine "Hello, world!"

How can i view it?


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.


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

Jun 5 '06 #22
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?

Jun 5 '06 #23
> 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.
Jun 5 '06 #24

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.


"Ian Boyd" <ia***********@avatopia.com> wrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

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

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

--
Mike Brind
Michael Kujawa wrote:
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.


"Ian Boyd" <ia***********@avatopia.com> wrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

<snip>
Yes, it's hard to understand why people moved away from print statements

and
embraced breakpoints and tracing.


Jun 5 '06 #26
> 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
Jun 6 '06 #27
Ian Boyd wrote:
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.


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/
--
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.
Jun 6 '06 #28
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" <ia***********@avatopia.com> wrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
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

Jun 6 '06 #29
> 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?
Jun 7 '06 #30
> 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.
Jun 7 '06 #31
Ian Boyd wrote:
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.


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


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

--
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.
Jun 7 '06 #32
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.

"Ian Boyd" <ia***********@avatopia.com> wrote in message
news:OV**************@TK2MSFTNGP05.phx.gbl...
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.

Jun 8 '06 #33

"Michael Kujawa" <nof at kujawas dot net> wrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
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.



"Ian Boyd" <ia***********@avatopia.com> wrote in message
news:OV**************@TK2MSFTNGP05.phx.gbl...
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.


Jun 8 '06 #34

"Anthony Jones" <An*@yadayadayada.com> wrote in message
news:e3**************@TK2MSFTNGP02.phx.gbl...

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?

Jun 8 '06 #35
Michael Kujawa wrote:
"Anthony Jones" <An*@yadayadayada.com> wrote in message
news:e3**************@TK2MSFTNGP02.phx.gbl...

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?


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

--
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.
Jun 8 '06 #36

Bob Barrows [MVP] wrote:
Michael Kujawa wrote:
"Anthony Jones" <An*@yadayadayada.com> wrote in message
news:e3**************@TK2MSFTNGP02.phx.gbl...

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?


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

--
Mike Brind

Jun 9 '06 #37

"Mike Brind" <pa*******@hotmail.com> wrote in message
news:11**********************@y43g2000cwc.googlegr oups.com...

Bob Barrows [MVP] wrote:
Michael Kujawa wrote:
"Anthony Jones" <An*@yadayadayada.com> wrote in message
news:e3**************@TK2MSFTNGP02.phx.gbl...
>
> 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?
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?


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.

Thanks

--
Mike Brind

Jun 9 '06 #38
Mike Brind wrote:

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?


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.
--
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"
Jun 9 '06 #39

Bob Barrows [MVP] wrote:
Mike Brind wrote:

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?


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

--
Mike Brind

Jun 9 '06 #40

"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote in message
news:O0**************@TK2MSFTNGP05.phx.gbl...
Mike Brind wrote:

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?


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,
Do you mean remote debugging? I've never got that to work so you're doing
better than me :)
I've never got T-SQL debugging to work either probably for the same reason.
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).

We use a shared development machine only for systems integration testing.
When the source is checked in the shadow folder for the checked in code
forms the root of the testing web site. If things don't go well we fetch
all checked in code to our local machines and reproduce and debug the
problem there.
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.
--
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"

Jun 9 '06 #41
"Mike Brind" <pa*******@hotmail.com> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com...


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: <snip> Mike Brind


That sort of sums it up for me as well. I will stick with the most
reliable for me... DW8 and Notepad.

Although I figured I should get cracking at .Net sometime soon.
So I went ahead and purchased VS Studio 2005 Professional
Upgrade. Still quite steep in price but glad owning VFP 9 gave
me a price break.

Mike Kujawa
Jun 9 '06 #42

Michael Kujawa wrote:
"Mike Brind" <pa*******@hotmail.com> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com...


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:

<snip>
Mike Brind


That sort of sums it up for me as well. I will stick with the most
reliable for me... DW8 and Notepad.

Although I figured I should get cracking at .Net sometime soon.
So I went ahead and purchased VS Studio 2005 Professional
Upgrade. Still quite steep in price but glad owning VFP 9 gave
me a price break.


Hmmm. I bought VS2003 Developer at just over £1300 (about $4000 at
today's exchange rate, I think :-P) for having a crack at dotnet. It's
hardly ever been used. Now they've released v2.0, and are giving IDEs
away.... But at least I'm now making much more use of SQL Server.

Notepad? That only sees the light of day whan I need to strip MS
Office formatting from text prior to posting it in a rich text
editor....

--
Mike Brind

Jun 10 '06 #43
>> VS I suppose maybe be best.

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.


That's what i thought when i convinced the company to get VS2005.

The web programming language plugin for VS2005 is called "Visual Web
Developer". Apparently this replaces FrontPage, but as FrontPage was
removed, so was native support for ASP.

As i read from a lot of upset and frustrated web developers who upgraded to
2005, if you want to develop in ASP, you need to acquire a copy of 2003
instead.
Jun 13 '06 #44
> As i read from a lot of upset and frustrated web developers who upgraded
to 2005, if you want to develop in ASP, you need to acquire a copy of 2003
instead.


I develop all of my ASP pages in 2005 (File | Open).

Then again, I have little use for frilly wizards and projects and publishing
tools, which is probably where most of the complaints are.
Jun 13 '06 #45
On Tue, 13 Jun 2006 16:17:32 -0400, "Aaron Bertrand [SQL Server MVP]"
<te*****@dnartreb.noraa> wrote:
in <eN**************@TK2MSFTNGP05.phx.gbl>
As i read from a lot of upset and frustrated web developers who upgraded
to 2005, if you want to develop in ASP, you need to acquire a copy of 2003
instead.


I develop all of my ASP pages in 2005 (File | Open).

Then again, I have little use for frilly wizards and projects and publishing
tools, which is probably where most of the complaints are.


For all the same reasons I use UltraEdit.

---
Stefan Berglund
Jun 13 '06 #46
> I develop all of my ASP pages in 2005 (File | Open).

Then again, I have little use for frilly wizards and projects and
publishing tools, which is probably where most of the complaints are.


i was more interested in
1. set breakpoint
2. push play
3. debug
Jun 15 '06 #47

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.