How does one debug ASP Classic with VWD Express?

[Jim Rodgers]

My question is simple:
How does one debug ASP Classic with Microsoft Visual Web
Developer Express 2005 ("VWD")?

Looming in the back of anyone's mind when you see a posting
like this on any newsgroup is "didn't this guy read the docs?"

Frankly, I "sort of did" a number of times. I feel the days of
"things that are intuitively obvious" to use long ago gave way to
"things that are clear after a 'Hello World'" example. And those
things now are gone (since .Net) and have perhaps given way
to the on-line-tutorial (at best). Still, I'm at a loss for any easy
to use instructions for debugging Classic ASP with VWD Express.

I'm not even sure, this time, what I'm looking for. With VB6 and
VBA, I fully expect "Step-Into, Step-Over, and Step-Outof" control
of execution — plus at least a Call Stack window of some sort.
But with VBScript, are these things possible? I assume they are
because isn't it the fully-compiled language system that cannot be
"parsed," if you will, in execution mode? Then again, we have the
whole IIS/ASP architecture. I've always debugged these programs
with just Notepad and a browser — and often-times, Front Page.
And I never was consistently successful getting Front Page to do
anything clever like grab ahold of an instance of a debugger or a
broswer and have them all work together.

I written soooo much in VB6. I'm spoiled by the simplicity of the
programming scenario (fat client / one machine) and the luxury of
the VB6 Development Environment. My experience from all that
work is now reduced to just so many bad habits.

Before I get into translating all that VB6/VBA/VBScript into VB.Net
or C#, I need to pay some bills! And this is getting harder and
harder to do now that my business seems to have moved over to
100% web-based applications. My productivity is in the toilet!

So, my friends of the ASP Classic and VWD Express, H-E-L-P !!!

Jim Rodgers

 

[Mark J. McGinty]

My question is simple:
How does one debug ASP Classic with Microsoft Visual Web
Developer Express 2005 ("VWD")?

Looming in the back of anyone's mind when you see a posting
like this on any newsgroup is "didn't this guy read the docs?"

Frankly, I "sort of did" a number of times. I feel the days of
"things that are intuitively obvious" to use long ago gave way to
"things that are clear after a 'Hello World'" example. And those
things now are gone (since .Net) and have perhaps given way
to the on-line-tutorial (at best). Still, I'm at a loss for any easy
to use instructions for debugging Classic ASP with VWD Express.

I'm not even sure, this time, what I'm looking for. With VB6 and
VBA, I fully expect "Step-Into, Step-Over, and Step-Outof" control
of execution - plus at least a Call Stack window of some sort.
But with VBScript, are these things possible? I assume they are
because isn't it the fully-compiled language system that cannot be
"parsed," if you will, in execution mode? Then again, we have the
whole IIS/ASP architecture. I've always debugged these programs
with just Notepad and a browser - and often-times, Front Page.
And I never was consistently successful getting Front Page to do
anything clever like grab ahold of an instance of a debugger or a
broswer and have them all work together.

I written soooo much in VB6. I'm spoiled by the simplicity of the
programming scenario (fat client / one machine) and the luxury of
the VB6 Development Environment. My experience from all that
work is now reduced to just so many bad habits.

Before I get into translating all that VB6/VBA/VBScript into VB.Net
or C#, I need to pay some bills! And this is getting harder and
harder to do now that my business seems to have moved over to
100% web-based applications. My productivity is in the toilet!

So, my friends of the ASP Classic and VWD Express, H-E-L-P !!!

I have no idea what VWD's debug capabilities are, however, I do know of a
simple way to test the script debugging capabilities of your system as it
sits:

Open a command prompt, and execute a valid .vbs or .js script file, passing
the //x option. You may wish to copy an existing script file, or create a
simple one just for this -- whatever's easiest for you. The only
requirements are that it must be syntactically valid, and it must have at
least one executable line of code (i.e, for .VBS files, it can't just
contain Dim statements.)

For argument's sake, let's suppose you have opened a command prompt, changed
directory to C:\Test, and a valid VBScript file named C:\Test\debugcheck.vbs
exists. At the prompt type:

debugcheck.vbs //x

This will attempt to execute the script in the default debugger,
automatically breaking on the first executable line. It may give you a
choice of more than one debugging app, some or all of which may or may not
be correctly installed.

The goal here is to establish whether or not a working script debugger is
installed. Debugging ASP script is more involved than debugging client-side
script, IIS settings, permissions, blah blah blah -- but chasing any of
those is pointless unless you know you have the software to debug *any*
script installed/working. Executing client-side script //x is by far the
easiest reality check for this.

Simple flow chart:
------------------

I want to Debug ASP
\|/
Is a script debugger installed and working?
\|/ \|/
No Yes
\|/ \|/
Install one, Attach to ASP
or make one script host process
work and set break points
\|/
Does it work? -> Yes -> Woohoo,
done
\|/
No
\|/
[too convoluted
to diagram here]


Good luck!

-Mark

 

[Jim Rodgers]

VWD isn't really designed for classic ASP.
Try ASP Studio, it's designed for debugging classic ASP.
http://en.ewebxp.com/

On that site, I look for info and find this:

"With no server , you can edit and debug an ASP project with the help of ASP
server integrated capable of debugging , after you create an ASP project
simply."

....Is this a foreshadow of the Help File?

Actually, what I am looking for is a VWD-resident (add-on?)
that can wizard my lazy butt into an easy-to-use debug
configuration for ASP Classic — and perhaps another one that
can show me how actually to debug with it.

I learned long ago at first to avoid 3rd party tools and controls.
Usually it's just more license fees and an incompatible product
life cycle. I don't have that kind of time since I use whatever I
use on about a dozen PC's in a given month. 3rd party stuff,
for example a reasonable SNMP Manager object, I have to
keep in just one or two places because of license and, of course,
configuration issues. Those components get shared only after
they are compiled (VB6).

====================

As I understand it, there is, somewhere, a set of instructions
that will show me how to set-up and use VWD for debugging
Classic ASP with VBScript.

Obviously, VWD is somewhat hostile towards development with
Classic ASP. There is no ASP file type in the Add New File
Dialog, and id you try to use the "Comment" button on the
toolbar, you get the <!-- --> treatment around your VBScript
statements rather than apostrophe's !!! I'm not impressed.
I'd fire the guy who thought THIS was a good idea.

But I want to use it, and I believe these limitations either
already have secret solutions, or MS will be reasonable and
fix it, for crying out loud!

================

So, can anyone tell me how to open my files in VWD can
proceed to debug them?

Sincerely looking for help with this,

Jim Rodgers

 

[Mark J. McGinty]

On that site, I look for info and find this:

"With no server , you can edit and debug an ASP project with the help of
ASP
server integrated capable of debugging , after you create an ASP project
simply."

...Is this a foreshadow of the Help File?

Actually, what I am looking for is a VWD-resident (add-on?)
that can wizard my lazy butt into an easy-to-use debug
configuration for ASP Classic - and perhaps another one that
can show me how actually to debug with it.

I learned long ago at first to avoid 3rd party tools and controls.
Usually it's just more license fees and an incompatible product
life cycle. I don't have that kind of time since I use whatever I
use on about a dozen PC's in a given month. 3rd party stuff,
for example a reasonable SNMP Manager object, I have to
keep in just one or two places because of license and, of course,
configuration issues. Those components get shared only after
they are compiled (VB6).

====================

As I understand it, there is, somewhere, a set of instructions
that will show me how to set-up and use VWD for debugging
Classic ASP with VBScript.

Obviously, VWD is somewhat hostile towards development with
Classic ASP. There is no ASP file type in the Add New File
Dialog, and id you try to use the "Comment" button on the
toolbar, you get the <!-- --> treatment around your VBScript
statements rather than apostrophe's !!! I'm not impressed.
I'd fire the guy who thought THIS was a good idea.

But I want to use it, and I believe these limitations either
already have secret solutions, or MS will be reasonable and
fix it, for crying out loud!

================

So, can anyone tell me how to open my files in VWD can
proceed to debug them?

Sincerely looking for help with this,

Did you read my first post? If you perform the reality check I described,
and VWD is capable of debugging script (because that's exactly what classic
ASP is: script) it should show up as an option, in a list of installed
debugging applications that you can choose from.

If VWD does show in the list, you'll only need a little config, and to
figure out how to make VWD attach to ASP's script host process. (Usually a
Process menu item, that opens a dialog.) From there, set some break points
and you're in.

If VWD *doesn't* show up in the list, or no opportunity to debug the script
is presented at all, then trying to debug classic ASP with VWD is likely
tantamount to beating a dead horse. If waiting for Microsoft to do "the
right thing" seems like a viable strategy to you, I'd have to suppose you've
never actually had to deploy it... either that or you are extremely patient,
and have other technologies to substitute, to fill needs while you wait
(quite possibly, forever.).

If VWD is incapable of debugging classic ASP, does that mean you will simply
forgo use of a real, source-level debugging environment entirely, and revert
to Response.Write and the browser? Suit yourself, but you've gotta know
they don't even compare.

As for buying 3rd party tools, it's unnecessary; if you've got Office,
you've got a highly functional script debugger, though it doesn't install by
default (iirc, it's listed under tools as HTML Editor, in the setup -- for
Office 2000 the app is called MSE.EXE, apparently cloned from Interdev 6.0.)
If you've got VS6, install Interdev; if you've got VS 2003 or VS 2005,
script debugging is integral to the IDEs.

Personally I consider the ability to debug ASP code to be a requirement, it
has saved me hours upon countless hours. Further, some problems are
virtually impossible to fully understand by dumping values to the browser;
using a real debugger is the only way to debug that shows you everything at
once, without leaving you to make assumptions about which branches executed
and which variables contained what.

As for learning how to use it, if you've used one Microsoft debugger
released in the last decade, you've pretty-much used them all. You can
examine values of simple scalar types, drill into properties of objects
(represented in a treeview), set conditional break points, and execute code
in the immediate window. You say you're familiar with VB6 debugging?
You'll be right at home, not much new to learn, only a few extra details
needed to make it happen. The only thing you may miss is the ability to
edit and continue, which is not there, because, due to the implementation of
the script engine, it just isn't possible.


-Mark

 

[Jim Rodgers]

Did you read my first post? If you perform the reality check I described,
and VWD is capable of debugging script (because that's exactly what classic
ASP is: script) it should show up as an option, in a list of installed
debugging applications that you can choose from.

If VWD does show in the list, you'll only need a little config, and to
figure out how to make VWD attach to ASP's script host process. (Usually a
Process menu item, that opens a dialog.) From there, set some break points
and you're in.

If VWD is incapable of debugging classic ASP, does that mean you will simply
forgo use of a real, source-level debugging environment entirely, and revert
to Response.Write and the browser? Suit yourself, but you've gotta know
they don't even compare.

I understand. I never had as much script to debug as I do now.
I always got along fine using Response.Write, etc., ...and I have
recently developed a lot of technique based on that. As a matter
of fact, I really learned a lot about ASP and IIS this way. Some
of my crazy adhoc debug tools led to techniques I use in product
code.

However, enough is enough.

...If you've got VS6, install Interdev; if you've got VS 2003 or VS 2005,
script debugging is integral to the IDEs.

Personally I consider the ability to debug ASP code to be a requirement, it
has saved me hours upon countless hours. Further, some problems are
virtually impossible to fully understand by dumping values to the browser;
using a real debugger is the only way to debug that shows you everything at
once, without leaving you to make assumptions about which branches executed
and which variables contained what.

As I am planning to wrap-up much of my script into DLLs, I
will be hurting if I cannot stop and examine objects.

...You say you're familiar with VB6 debugging?
You'll be right at home, not much new to learn, only a few extra details
needed to make it happen.
-Mark

Thanks, Mark.

Cheers,

Jim Rodgers

 

[Jim Rodgers]

Did you read my first post? If you perform the reality check I described,
and VWD is capable of debugging script (because that's exactly what classic
ASP is: script) it should show up as an option, in a list of installed
debugging applications that you can choose from.

Mark, I'm not really sure what you mean. I wish I knew exactly
where to look. Will I see the words "installed" or "debugging
applications"? Am I looking in VWD or MSE for this?

If VWD does show in the list, you'll only need a little config, and to
figure out how to make VWD attach to ASP's script host process. (Usually a
Process menu item, that opens a dialog.) From there, set some break points
and you're in.

====================

Mark,

Well, I didn't really understand what you were trying to explain.
And I could tell you never used VWD to write/debug Classic ASP.
You were just telling me how to get it work if it were to work.
I appreciate your knowledge and your intellectual flexibility to try
to help me.

================

So I just started hacking away at it to see what happens.

- First, I tried to run a VB script.
- Windows says I "should" (must) change the scripting host to CScript.
- I don't want to. Hoping the "//x" will save me.
- Somehow, I wind-up in MS MSE...
- - a scripting environment? a debugger?
- I look under options and see "Processes."
- So I start VWD, go back to MSE, and VWD is in the list.
- I "attach" MSE to VWD from MSE.
- Next, I go back to VWD and open a familiar asp file.
- I click on the little green arrow.
- - is it run??? it never did anything before...
- Some things happen and then THIS:

Server Error in '/wwwroot' Application.
---------------------------------------------------
This type of page is not served.
Description: The type of page you have requested is
not served because it has been explicitly forbidden.
The extension '.asp' may be incorrect. Please review
the URL below and make sure that it is spelled correctly.

Requested URL: /wwwroot/Application.asp
---------------------------------------------------------------------
Version Information:
Microsoft .NET Framework Version:2.0.50727.832; ASP.NET
Version:2.0.50727.832

==================

So, maybe VWD does not "rock for ASP Classic" as
a certain MVP recently told me it did.

Does Microsoft understand that this sort of crap is a
BARRIER to entry for customers? Now I'm supposed to
feel inclined to use one MS product because another
one is boobytrapped? At best, I may dust-off my old
VS6 stuff when I go back to make DLLs of my VBScript.
(I never bothered with VInterDev because at the time I
was a purely VB6 guy.)

After all these years, and all this fighting FOR Microsoft,
I am ready, finally, to look at another vendor who respects
MY needs at least a little rather than _only_ HIS. One of my
needs is to support all the work I have already done while
making transitions to new technologies as I choose.

The product already is not supported. So why,exactly, did
they go through the trouble to break it further?

==============

I understand that "Enterprise Java Beans" is the future of
serious server-side development. There are numerous
platforms that support these applications. They run great
on Windows as well as Solaris (of course!) and HPUX, AIX,
etc.

You can configure an app to launch as many VM's as you need
to scale up to the task. In a world where multi-chip and multi-
core has been the norm for years now, this makes sense. And
these java apps are like VB in that they are interpreted but can
be compiled. You can configure the point at which your codes
switch from interpreted to compiled. And it's not just a Sun
thing: these systems run on various platforms from IBM, BEA,
etc. Great SOA platforms with great interactivity with major
database products. Imagine your Oracle package spawning
EVB's on your eight-way quad-core Windows box! And you can
use IIS to balance the server farm.

Do software companies make a profit doing things this way?
Just ask JDA. They've been making out like bandits since they
bought Manugistics, who excelled at this architecture.

Does anyone understand my point?

You can start by writing simple scripts and wind up writing real
software! I thought that Microsoft was the one who created
opportunities this way. It is the Bill Gates way. But Bill is out of
it now; and so, I fear, is Microsoft.

I feel it is a matter of principle, that if MS -REFUSES- to let me
have ONE IDE for their overlapping product technologies in my
overlapping projects and overlapping market spaces, then this
is a company that has lost its heart -- and my loyalty.

=================

OK. OK. OK. So I'm freaking out a little bit here. After all, the
old Visual InterDev tool still works, right? And VWD is certainly
just an upgrade on that platform, right?

Right.

And VWD surely is better than FrontPage... I guess.

I guess.

And it's free. (Once again, it's the "Drug Dealer" model of
software development.)

Whaddaya want for free?

========================

If I pissed you off with this rant, then, please, forgive me.

This is costing me REAL money; and could cost me a lot more
than THAT. Anyway, I have a couple more large projects to do
on ASP Classic and VBScript,...

.... so I would like to hang out here a little longer if you guys will
have me. I'll try to pay my way by helping to answer others'
questions from time to time if I can.

And I appreciate all te help you guys give me here.

Cheers and Regards,

Jim Rodgers

 

[Mike Brind]

Mark, I'm not really sure what you mean. I wish I knew exactly
where to look. Will I see the words "installed" or "debugging
applications"? Am I looking in VWD or MSE for this?



====================

Mark,

Well, I didn't really understand what you were trying to explain.
And I could tell you never used VWD to write/debug Classic ASP.
You were just telling me how to get it work if it were to work.
I appreciate your knowledge and your intellectual flexibility to try
to help me.

================

So I just started hacking away at it to see what happens.

- First, I tried to run a VB script.
- Windows says I "should" (must) change the scripting host to CScript.
- I don't want to. Hoping the "//x" will save me.
- Somehow, I wind-up in MS MSE...
- - a scripting environment? a debugger?
- I look under options and see "Processes."
- So I start VWD, go back to MSE, and VWD is in the list.
- I "attach" MSE to VWD from MSE.
- Next, I go back to VWD and open a familiar asp file.
- I click on the little green arrow.
- - is it run??? it never did anything before...
- Some things happen and then THIS:

Server Error in '/wwwroot' Application.
---------------------------------------------------
This type of page is not served.
Description: The type of page you have requested is
not served because it has been explicitly forbidden.
The extension '.asp' may be incorrect. Please review
the URL below and make sure that it is spelled correctly.

Requested URL: /wwwroot/Application.asp
---------------------------------------------------------------------
Version Information:
Microsoft .NET Framework Version:2.0.50727.832; ASP.NET
Version:2.0.50727.832

==================

So, maybe VWD does not "rock for ASP Classic" as
a certain MVP recently told me it did.

Does Microsoft understand that this sort of crap is a
BARRIER to entry for customers? Now I'm supposed to
feel inclined to use one MS product because another
one is boobytrapped? At best, I may dust-off my old
VS6 stuff when I go back to make DLLs of my VBScript.
(I never bothered with VInterDev because at the time I
was a purely VB6 guy.)

After all these years, and all this fighting FOR Microsoft,
I am ready, finally, to look at another vendor who respects
MY needs at least a little rather than _only_ HIS. One of my
needs is to support all the work I have already done while
making transitions to new technologies as I choose.

The product already is not supported. So why,exactly, did
they go through the trouble to break it further?

==============

I understand that "Enterprise Java Beans" is the future of
serious server-side development. There are numerous
platforms that support these applications. They run great
on Windows as well as Solaris (of course!) and HPUX, AIX,
etc.

You can configure an app to launch as many VM's as you need
to scale up to the task. In a world where multi-chip and multi-
core has been the norm for years now, this makes sense. And
these java apps are like VB in that they are interpreted but can
be compiled. You can configure the point at which your codes
switch from interpreted to compiled. And it's not just a Sun
thing: these systems run on various platforms from IBM, BEA,
etc. Great SOA platforms with great interactivity with major
database products. Imagine your Oracle package spawning
EVB's on your eight-way quad-core Windows box! And you can
use IIS to balance the server farm.

Do software companies make a profit doing things this way?
Just ask JDA. They've been making out like bandits since they
bought Manugistics, who excelled at this architecture.

Does anyone understand my point?

You can start by writing simple scripts and wind up writing real
software! I thought that Microsoft was the one who created
opportunities this way. It is the Bill Gates way. But Bill is out of
it now; and so, I fear, is Microsoft.

I feel it is a matter of principle, that if MS -REFUSES- to let me
have ONE IDE for their overlapping product technologies in my
overlapping projects and overlapping market spaces, then this
is a company that has lost its heart -- and my loyalty.

=================

OK. OK. OK. So I'm freaking out a little bit here. After all, the
old Visual InterDev tool still works, right? And VWD is certainly
just an upgrade on that platform, right?

Right.

And VWD surely is better than FrontPage... I guess.

I guess.

And it's free. (Once again, it's the "Drug Dealer" model of
software development.)

Whaddaya want for free?

========================

If I pissed you off with this rant, then, please, forgive me.

This is costing me REAL money; and could cost me a lot more
than THAT. Anyway, I have a couple more large projects to do
on ASP Classic and VBScript,...

... so I would like to hang out here a little longer if you guys will
have me. I'll try to pay my way by helping to answer others'
questions from time to time if I can.

Forget it. You cannot use VWD for classic ASP debugging because it does not
support attaching to process. It's not an upgrade on Visual Interdev
anymore than VB.NET is an upgrade of VB6 or ASP.NET is an upgrade of Classic
ASP. They are entirely different technologies. They are replacements for
older technologies that Microsoft have decided not to provide any backwards
compatibility for.

You can, however, invest in the full version of Visual Studio 2005 and use
that to debug classic ASP, and read about why they have cut classic ASP
support from this product:
http://blogs.msdn.com/greggm/archive/2006/03/15/552108.aspx. Oh, and VWD is
the cut-down version of VS2005 - not an upgrade on anything at all.

I guess the difficulty that MS have is that they introduced the .NET
framework 6-7 years ago. VS2005 is the third version of the .NET IDE and
they have the fourth - VS2008 - in Beta2. The framework itself is now on
version 3.5. Classic ASP only ever made version 3.0, and that was launched
in Feb 2000. Most serious developers have moved onto the .NET framework now
and have the paid-for IDE. Hardly anyone new is learning classic ASP, and
the number of nature of posts in this group bears that out. They've more
than halved over the last year or so, and most concern legacy apps. On the
other hand, the multitude of newsgroups and forums available for ASP.NET are
literally struggling under the strain of increasing activity. If you were
running the business, you would probably make the same decisions MS have. I
know I would.

I think it's called "progress".

 

[Jim Rodgers]

Forget it. You cannot use VWD for classic ASP debugging because it does not
support attaching to process. It's not an upgrade on Visual Interdev
anymore than VB.NET is an upgrade of VB6 or ASP.NET is an upgrade of Classic
ASP. They are entirely different technologies. They are replacements for
older technologies that Microsoft have decided not to provide any backwards
compatibility for.

You can, however, invest in the full version of Visual Studio 2005 and use
that to debug classic ASP, and read about why they have cut classic ASP
support from this product:
http://blogs.msdn.com/greggm/archive/2006/03/15/552108.aspx. Oh, and VWD is
the cut-down version of VS2005 - not an upgrade on anything at all.

I guess the difficulty that MS have is that they introduced the .NET
framework 6-7 years ago. VS2005 is the third version of the .NET IDE and
they have the fourth - VS2008 - in Beta2. The framework itself is now on
version 3.5. Classic ASP only ever made version 3.0, and that was launched
in Feb 2000. Most serious developers have moved onto the .NET framework now
and have the paid-for IDE. Hardly anyone new is learning classic ASP, and
the number of nature of posts in this group bears that out. They've more
than halved over the last year or so, and most concern legacy apps. On the
other hand, the multitude of newsgroups and forums available for ASP.NET are
literally struggling under the strain of increasing activity. If you were
running the business, you would probably make the same decisions MS have. I
know I would.

I think it's called "progress".

Mike,

Thank you for your reply.

I have an early (the first) version of Visual Studio .NET in an MSDN
Universal Pack (forgot the exact year). Would I be pissed at myself if I
invested in installing that one? And would the VS6 InterDev be better that
the VS.NET (in that MSDN Pack) for my work with ASP Classic/VBScript?

BTW, my remaining ASP Classic projects are essentially ports from VB6.
These particular clients have too many problems with fat clients as time goes
on. Also, users there are more saavy now, and they insist on using their own
e-mail clients and other personal apps that sometimes create issues with the
fat client configurations.

I choose to port these apps rather than re-write them in VB.NET for various
reasons, but high on the list is my extensive use of Variants in the
interface to a key OCX I wrote that manages data and the GUI for that product
platform. Such extensive use of Variants precludes a simple re-write to
..NET.

Cheers,

Jim Rodgers

==========================

A Rant, An Aside, A Point of View:

I started using ASP back in 1996 when IIS was a product MS bought from
Vermeer. I guess ASP got cleaned-up and packaged as such in 1997. At the
same time MS was wrestling with the VB3-VB4 upgrade (that, too, really was a
replacement rather than an upgrade). Surely it was at least by then MS
started the trajectory for the VB5/6 to VB.NET strategy. Still, even back
then I was suspicious of the use of a scripting tool for ASP. I've always
been amazed that it worked so well.

I agree that .NET is vastly superior to its predecessor technologies. I
once evangelized the superiority of VB over PowerWhateverItWas and Delphi and
even C++ ...for most In-House tasks like IT and Engineering applications.
However, despite the superiority of the replacement technologies, I am an
evangelist NO MORE.

Especially as my responsibilities now are more related to business
management and strategy, I am beginning to see software development in a new
way. When MS decides to dump support -REALLY- for ASP Classic by not
allowing it to run on new server platforms, then we will see how smart they
are.

There is a Perfect Storm brewing out there, and it is not the making of some
anti-Microsoft or anti-Bill Gates conspiracy. Rather, it is the result of
SUCCESSFUL Microsoft strategies (more exactly, Philosophies) that they could
not keep selling INTERNALLY as staff turns over. Let me ramble on.

Some great strategies are not well-supported by Market Science — just as
some poor ones (e.g., out-sourcing) seem at first to be well-supported by
Business Science. Sometimes it takes talented LEADERSHIP with that deeper
understanding and vision to to push some strategies to fruition — sometimes
over the dead bodies, as it were, of generally well-informed advisors. I
have "recommended or approved" (as they say) many millions of dollars worth
of Microsoft products. I did it because it made sense to me. When my
detractors wanted to out-source the manufacturing plant to China, I and my
associates showed the owners how they could do even better keeping it in
Atlanta. Microsoft, Visual Basic, Access, Excel, and SQL Server were key
elements in that plan. So was leveraging the under-utilized skills and
intelligence of the hourly workers. This was the missing link most American
corporations never find — indeed, they never even look for it.

Now, Microsoft also is not looking for this critical layer in the
"time-space continuum" of the Life Cycle of their customers. All those MS
sales I am responsible for really had their roots in my work with "Microsoft
Basic," a 4k ROM-based interpreter on my Kim-1 home computer. "Everyone"
thought that was just a hobby or a toy, but I did post graduate studies using
that thing! Later, "they" also said the same sorts of comments about Visual
Basic.

While all the C++ programmers were having meetings about meetings, and
listening to guest speakers, and their managers were writing poison e-mails
(on the VAX!) about my groups amatuer techniques, we were eating their lunch.
While all the Quality Engineers were setting up mandatory training sessions
for everyone on God-knows-what-this-time, my team was writing a distributed
real-time data collection and process control system (Manufacturing Execution
System) in VB3 and Access 95. Yield went from 70% to 99.9%, and we emerged
from bankruptcy. While the IT Dept was conducting data model reviews for
variables naming and orthogonalization — and forcing all development on
Oracle and Solaris — millions were lost in inappropriate capital
expenditures, failed IT projects, failed Quality initiatives, and "reusable"
C++ softwares that other C++ programmers refused to work on unless they could
do a complete re-write or got a big raise.

The point is this: SUBJECT MATTER EXPERTISE IS OFTEN MORE IMPORTANT than
being some kind of big deal smarty-pants know-it-all expert on programming
science. If you completely detach subject matter experts (test engineering,
manufacturing engineering, physical simulation, statistical analysis,
financial analysis, quality engineering, ...even SQL development)... if you
detach experts from any access to software development tools, there will be a
price to pay. This price is higher for US and Europe than it will be for
China and India, but still it is a significant expense. In fact, it is
STRATEGICALLY IMPORTANT to address this aspect of the fabric of a
medium-to-large company.

I fear VB.NET and C# and whatever are 29% too much trouble for the real
producers of the company to leverage. In my experience, most pure
"programmers" have no other bottom-line skills or knowledge besides their one
or two programming languages and maybe a superficial awareness of systems
architecture. Engineers, scientists, and mathematicians got a wonderful gift
when VB3 came around. Suddenly, they could write code for THEIR needs
without jumping through all kinds of corporate hoops to get at programming
resources. Moreover, VB ran on THEIR computer, not the corporate mini or
mainframe. This is an exact parallel to how, perhaps five years earlier,
professionals found they could write their own documents without submitting a
requisition to the Word Processing Department. Productivity went through the
roof — and in more than some small part, it was due to the leadership and
vision of Bill Gates.

Consequently, the late 1980's and especially the 1990's became a period of
fantastically-improved results (especially productivity) in global
corporations. The stock market went berserk. And in the late 1990's, the
Internet multiplied this effect — until that bubble burst.

My concern for programmers today is that many of them will not add value.
Just as the Word Processing clerk had to go back to being an admin assistant.
And if you are good enough to be regarded as a professional programmer, then
you better live in India. Watch what happens. And watch how moves [like
making VB completely different] break the siphon — they create a rift in the
time-space continuum of corporate business culture. Ladies and gentlemen, we
are only now at this point. I'm still seeing A WHOLE LOT of "asp"s on
website links today — they are not all "aspx" just yet. And where did some
of the previous software development managers go? They were promoted so they
could crush VB and perhaps even Microsoft (yes, I took my meds!) — because
"understanding what is the best language" is the only core skill they have.
This results in a strategic misalignment which will maintain the current
"resource leak" we know of as out-sourcing.

In the future, after all this shakes out, I believe we will see very
carefully made distinctions between computer technologies developed in-house
for situationally-unique uses (in hundreds of ways) and those purchased (many
as software services) for complex but well-understood common problems like
ERP and personal productivity. Isn't this obvious already? But we also will
see (as we do not now see) ways to address the CONTINUITY and
interoperability of these two realms.

In this perspective, classic VB plays its role in-house. So what happens to
the knowledge workers who have heretofore kicked-butt because they knew
Excel, Access, VB, VBA, and/or VBScript? They are abandoned by Microsoft
since Bill Gates left. I do not yet know who is their new benefactor. I
feel lost in the woods without a compass. Is Delphi still viable? Did
Delphi ever get support on UNIX? Didn't Borland change their name to Delphi?
How is that going?

And what is the role of VB.NET? It can only be in the big software realm —
shrink-wrapped and Software-As-A-Service products. But can it really compete
here up against Enterprise Java Beans and C++? I don't really know that
either, but I am not putting ANY money on .NET. Finally, if these products
are "what you buy" and not what you make (unless you are a big software
"manufacturer"), then who will be hiring most .NET programmers? I don't
think Microsoft cares WHO buys their stuff; but, then, that's the whole
problem.

Ah, yes, I feel better now.

 

[Mike Brind]

Forget it. You cannot use VWD for classic ASP debugging because it does
not
support attaching to process. It's not an upgrade on Visual Interdev
anymore than VB.NET is an upgrade of VB6 or ASP.NET is an upgrade of
Classic
ASP. They are entirely different technologies. They are replacements
for
older technologies that Microsoft have decided not to provide any
backwards
compatibility for.

You can, however, invest in the full version of Visual Studio 2005 and
use
that to debug classic ASP, and read about why they have cut classic ASP
support from this product:
http://blogs.msdn.com/greggm/archive/2006/03/15/552108.aspx. Oh, and VWD
is
the cut-down version of VS2005 - not an upgrade on anything at all.

I guess the difficulty that MS have is that they introduced the .NET
framework 6-7 years ago. VS2005 is the third version of the .NET IDE and
they have the fourth - VS2008 - in Beta2. The framework itself is now on
version 3.5. Classic ASP only ever made version 3.0, and that was
launched
in Feb 2000. Most serious developers have moved onto the .NET framework
now
and have the paid-for IDE. Hardly anyone new is learning classic ASP,
and
the number of nature of posts in this group bears that out. They've more
than halved over the last year or so, and most concern legacy apps. On
the
other hand, the multitude of newsgroups and forums available for ASP.NET
are
literally struggling under the strain of increasing activity. If you
were
running the business, you would probably make the same decisions MS have.
I
know I would.

I think it's called "progress".

Mike,

Thank you for your reply.

I have an early (the first) version of Visual Studio .NET in an MSDN
Universal Pack (forgot the exact year). Would I be pissed at myself if I
invested in installing that one? And would the VS6 InterDev be better
that
the VS.NET (in that MSDN Pack) for my work with ASP Classic/VBScript?

BTW, my remaining ASP Classic projects are essentially ports from VB6.
These particular clients have too many problems with fat clients as time
goes
on. Also, users there are more saavy now, and they insist on using their
own
e-mail clients and other personal apps that sometimes create issues with
the
fat client configurations.

I choose to port these apps rather than re-write them in VB.NET for
various
reasons, but high on the list is my extensive use of Variants in the
interface to a key OCX I wrote that manages data and the GUI for that
product
platform. Such extensive use of Variants precludes a simple re-write to
.NET.

Cheers,

Jim Rodgers

==========================

A Rant, An Aside, A Point of View:

I started using ASP back in 1996 when IIS was a product MS bought from
Vermeer. I guess ASP got cleaned-up and packaged as such in 1997. At the
same time MS was wrestling with the VB3-VB4 upgrade (that, too, really was
a
replacement rather than an upgrade). Surely it was at least by then MS
started the trajectory for the VB5/6 to VB.NET strategy. Still, even back
then I was suspicious of the use of a scripting tool for ASP. I've always
been amazed that it worked so well.

I agree that .NET is vastly superior to its predecessor technologies. I
once evangelized the superiority of VB over PowerWhateverItWas and Delphi
and
even C++ ...for most In-House tasks like IT and Engineering applications.
However, despite the superiority of the replacement technologies, I am an
evangelist NO MORE.

Especially as my responsibilities now are more related to business
management and strategy, I am beginning to see software development in a
new
way. When MS decides to dump support -REALLY- for ASP Classic by not
allowing it to run on new server platforms, then we will see how smart
they
are.

There is a Perfect Storm brewing out there, and it is not the making of
some
anti-Microsoft or anti-Bill Gates conspiracy. Rather, it is the result of
SUCCESSFUL Microsoft strategies (more exactly, Philosophies) that they
could
not keep selling INTERNALLY as staff turns over. Let me ramble on.

Some great strategies are not well-supported by Market Science - just as
some poor ones (e.g., out-sourcing) seem at first to be well-supported by
Business Science. Sometimes it takes talented LEADERSHIP with that deeper
understanding and vision to to push some strategies to fruition -
sometimes
over the dead bodies, as it were, of generally well-informed advisors. I
have "recommended or approved" (as they say) many millions of dollars
worth
of Microsoft products. I did it because it made sense to me. When my
detractors wanted to out-source the manufacturing plant to China, I and my
associates showed the owners how they could do even better keeping it in
Atlanta. Microsoft, Visual Basic, Access, Excel, and SQL Server were key
elements in that plan. So was leveraging the under-utilized skills and
intelligence of the hourly workers. This was the missing link most
American
corporations never find - indeed, they never even look for it.

Now, Microsoft also is not looking for this critical layer in the
"time-space continuum" of the Life Cycle of their customers. All those MS
sales I am responsible for really had their roots in my work with
"Microsoft
Basic," a 4k ROM-based interpreter on my Kim-1 home computer. "Everyone"
thought that was just a hobby or a toy, but I did post graduate studies
using
that thing! Later, "they" also said the same sorts of comments about
Visual
Basic.

While all the C++ programmers were having meetings about meetings, and
listening to guest speakers, and their managers were writing poison
e-mails
(on the VAX!) about my groups amatuer techniques, we were eating their
lunch.
While all the Quality Engineers were setting up mandatory training
sessions
for everyone on God-knows-what-this-time, my team was writing a
distributed
real-time data collection and process control system (Manufacturing
Execution
System) in VB3 and Access 95. Yield went from 70% to 99.9%, and we
emerged
from bankruptcy. While the IT Dept was conducting data model reviews for
variables naming and orthogonalization - and forcing all development on
Oracle and Solaris - millions were lost in inappropriate capital
expenditures, failed IT projects, failed Quality initiatives, and
"reusable"
C++ softwares that other C++ programmers refused to work on unless they
could
do a complete re-write or got a big raise.

The point is this: SUBJECT MATTER EXPERTISE IS OFTEN MORE IMPORTANT than
being some kind of big deal smarty-pants know-it-all expert on programming
science. If you completely detach subject matter experts (test
engineering,
manufacturing engineering, physical simulation, statistical analysis,
financial analysis, quality engineering, ...even SQL development)... if
you
detach experts from any access to software development tools, there will
be a
price to pay. This price is higher for US and Europe than it will be for
China and India, but still it is a significant expense. In fact, it is
STRATEGICALLY IMPORTANT to address this aspect of the fabric of a
medium-to-large company.

I fear VB.NET and C# and whatever are 29% too much trouble for the real
producers of the company to leverage. In my experience, most pure
"programmers" have no other bottom-line skills or knowledge besides their
one
or two programming languages and maybe a superficial awareness of systems
architecture. Engineers, scientists, and mathematicians got a wonderful
gift
when VB3 came around. Suddenly, they could write code for THEIR needs
without jumping through all kinds of corporate hoops to get at programming
resources. Moreover, VB ran on THEIR computer, not the corporate mini or
mainframe. This is an exact parallel to how, perhaps five years earlier,
professionals found they could write their own documents without
submitting a
requisition to the Word Processing Department. Productivity went through
the
roof - and in more than some small part, it was due to the leadership and
vision of Bill Gates.

Consequently, the late 1980's and especially the 1990's became a period of
fantastically-improved results (especially productivity) in global
corporations. The stock market went berserk. And in the late 1990's, the
Internet multiplied this effect - until that bubble burst.

My concern for programmers today is that many of them will not add value.
Just as the Word Processing clerk had to go back to being an admin
assistant.
And if you are good enough to be regarded as a professional programmer,
then
you better live in India. Watch what happens. And watch how moves [like
making VB completely different] break the siphon - they create a rift in
the
time-space continuum of corporate business culture. Ladies and gentlemen,
we
are only now at this point. I'm still seeing A WHOLE LOT of "asp"s on
website links today - they are not all "aspx" just yet. And where did
some
of the previous software development managers go? They were promoted so
they
could crush VB and perhaps even Microsoft (yes, I took my meds!) - because
"understanding what is the best language" is the only core skill they
have.
This results in a strategic misalignment which will maintain the current
"resource leak" we know of as out-sourcing.

In the future, after all this shakes out, I believe we will see very
carefully made distinctions between computer technologies developed
in-house
for situationally-unique uses (in hundreds of ways) and those purchased
(many
as software services) for complex but well-understood common problems like
ERP and personal productivity. Isn't this obvious already? But we also
will
see (as we do not now see) ways to address the CONTINUITY and
interoperability of these two realms.

In this perspective, classic VB plays its role in-house. So what happens
to
the knowledge workers who have heretofore kicked-butt because they knew
Excel, Access, VB, VBA, and/or VBScript? They are abandoned by Microsoft
since Bill Gates left. I do not yet know who is their new benefactor. I
feel lost in the woods without a compass. Is Delphi still viable? Did
Delphi ever get support on UNIX? Didn't Borland change their name to
Delphi?
How is that going?

And what is the role of VB.NET? It can only be in the big software
realm -
shrink-wrapped and Software-As-A-Service products. But can it really
compete
here up against Enterprise Java Beans and C++? I don't really know that
either, but I am not putting ANY money on .NET. Finally, if these
products
are "what you buy" and not what you make (unless you are a big software
"manufacturer"), then who will be hiring most .NET programmers? I don't
think Microsoft cares WHO buys their stuff; but, then, that's the whole
problem.

Ah, yes, I feel better now.

In answer to your original question, I installed VS2003 to have a go at .Net
1.1 about 3-4 years ago. I never tried debugging classic ASP pages with it,
and I had never used Visual Interdev. My debugging methods were restricted
to Response.Write, so I cannot give you a view on the relative strengths of
each product. Perhaps someone else here can.

I hated 1.1, so I never really used VS2003 at all, despite having paid
over£1000.00 for the version I bought. If anyone would like the Pro
version, including original box, Windows Server 2003, SQL Server 2000,
Exchange Server 2003 etc, etc... I can be persuaded to do a deal ;-)

As far as the rest of your post is concerned, I haven't read it all, but I
can't imagine that MS would withdraw asp.dll from IIS. There would be no
point. It is, after all, just an ISAPI. And there are still millions of
sites that need it to run. What hosting company in its right mind would
upgrade to a new server platform where they couldn't run existing customer
sites? And bear in mind that the revenue stream that .Net is designed to
improve most at MS is Server and OS licences. That's why they give away
extraordinarily powerful IDEs like VWD etc. MS won't stop providing
runtimes - they'll just not develop the platforms further. Equally, if you
want to continue to do your thing in VB/VBScript/VBA, I am sure that you
will be able to for a long time to come.

Oh, and my brother uses Delphi, although I think he has migrated over to
Delphi.Net now.... ;-)

 

[Mark J. McGinty]

Jim,

Sorry for the delay. Parts of this may be -- actually make that, this is
surely incomplete, it's an extensive topic, and I have many hours of
frustration invested into making it work. But the ROI has been huge.

The funny thing to me is, how fine the line between success and failure.
How many times have you jumped that gap between the two, by changing some
settings, hacking a registry key, or doing something else that was trivial,
if you knew what to do?

Tragically, the line between possible and impossible is equally fine, and
perhaps even more opaque. So, each of us has to decide when to cut his
losses. Making that decision too early -- as many have done in this realm,
imho -- actually increases losses in the long run.

If you want to continue this discussion privately, let me know in a post to
the NG, and email me at my spam dump address ([email protected] --
yes it's a real domain) and I'll keep an eye out for it... but first read
the rest of my response, inline, below...

Mark, I'm not really sure what you mean. I wish I knew exactly
where to look. Will I see the words "installed" or "debugging
applications"? Am I looking in VWD or MSE for this?

That's what you're in the process of discovering... pointless to try to
answer here. (Answers with reasons further down.)

====================

Mark,

Well, I didn't really understand what you were trying to explain.
And I could tell you never used VWD to write/debug Classic ASP.

I've never laid eyes on VWD for any purpose.

You were just telling me how to get it work if it were to work.
I appreciate your knowledge and your intellectual flexibility to try
to help me.

================

So I just started hacking away at it to see what happens.

That's often the only way to get any real answers.

- First, I tried to run a VB script.
- Windows says I "should" (must) change the scripting host to CScript.

The alternative is to execute the script explicitly with CScript:

CSCRIPT scriptname.vbs //x
CSCRIPT scriptname.js //x

- I don't want to. Hoping the "//x" will save me.
- Somehow, I wind-up in MS MSE...

The //x script took you there, //x invokes the script debugger [app].
Apparently, the only script debugger you have installed is MSE -- but that's
not a bad thing at all, it is a very capable script debugger. If you had
more than one (like, say, you installed Visual Studio 2005) it would offer
you a choice.

- - a scripting environment? a debugger?

Windows Script Host is the scripting environment, that part is a given. MSE
is both a source file editor, and a debugging environment.

At the point MSE opened, it should've displayed the script source you're now
debugging. You should see tool bar buttons that toggle display of the call
stack window, locals window, immediate window, and watch window. You should
also see buttons with the familiar step into, step over and step out of
symbols. The highlighted line of code is the next one that will execute;
the step into and step over buttons will step through each line...

- I look under options and see "Processes."
- So I start VWD, go back to MSE, and VWD is in the list.

At this point I think we can probably write-off VWD as a script debugger; if
it was one, you would've been given a choice between it and MSE.

- I "attach" MSE to VWD from MSE.

Pointless, because ASP script is executed by IIS. Depending on the
isolation setting in IIS, it may appear in the processes window as
DLLHOST.EXE if your ASP app are set for high isolation. I forget what
the process is for the other isolation settings, but the key thing is the
word "script" in the languages or type column of the processes list.

Before you look for it in the processes window, you'll want to load a page
of your ASP app to establish a session -- it's gotta be running before it
can be debugged. And there are settings in IIS to enable debugging. In the
properties dialog for a virtual server or virtual directory, in the
Directory tab, if the Create button has been clicked, the Configuration
button will be enabled; clicking the Configuration button opens another
property sheet, which has a Debugging tab, in which there are 2
checkboxes -- I always check them both. Also, my experience has been that
debugging must be enabled on the web root, as well as on all parents of the
app/dir you wish to debug.

All of this assumes you have IIS running on your machine, and the ASP code
running on your local IIS (typically something like
http://localhost/myappdir/mypage.asp where myappdir is the name of a virtual
directory.) There are provisions for remotely debugging ASP code running on
another workstation or server, but my luck with that has been hit and miss.
I know I can depend on it working locally.


This is about the end of anything of tutorial value... I had some more
comments, that are already typed below, value of which are questionable at
best... read on at risk of wasting your time.

- Next, I go back to VWD and open a familiar asp file.
- I click on the little green arrow.
- - is it run??? it never did anything before...
- Some things happen and then THIS:

Server Error in '/wwwroot' Application.
---------------------------------------------------
This type of page is not served.
Description: The type of page you have requested is
not served because it has been explicitly forbidden.
The extension '.asp' may be incorrect. Please review
the URL below and make sure that it is spelled correctly.

Requested URL: /wwwroot/Application.asp
---------------------------------------------------------------------
Version Information:
Microsoft .NET Framework Version:2.0.50727.832; ASP.NET
Version:2.0.50727.832

==================

So, maybe VWD does not "rock for ASP Classic" as
a certain MVP recently told me it did.

Doesn't sound like it, but hard to say, sight unseen.

Does Microsoft understand that this sort of crap is a
BARRIER to entry for customers? Now I'm supposed to
feel inclined to use one MS product because another
one is boobytrapped?

I'm sure they're aware that x% of users will encounter this or that hardship
When you consider that MS is large enough to buy out the suppliers and the
customers of competitors they want to sink -- and that they have done
exactly that on many occasions... given that, how much could they possibly
be expected to care?

The thing about their software that absolutely floors me, is the way their
new versions tend to omit features that previous releases supported, and
that I got used to using.

Case in point, access to collections and arrays in the script debugger.
Say, for instance, your script creates an MSXML2.DOMDocument object, which
as you may know, given that it contains one or more nodes, has a childNodes
property that is essentially a collection of nodes. Further, each node in
child nodes, that contains one or more nodes, also has a childNodes
property. In Interdev and MSE, when you click the + to expand childNodes,
you see underneath, a list of +'s, one for each child node. In VS 2003 and
VS 2005, click the +, all you get is a count. If you want to examine a
child node, you must dereference each one you want to see in the watch
window or immediate window.

So my question is, why do they expect us to accept an use something that's
so much less functional, when we "upgrade" to their latest release? In this
particular case, the only argument against the way it used to work that I
can imagine, was that large arrays could take awhile to render in a
treeview. So why not limit the loop that demand-loads the branch? Why not
stop at 50 or 100, and tack-on a dummy node that says [more...] that's
replaced with the next 50 or 100 when clicked?

At best, I may dust-off my old
VS6 stuff when I go back to make DLLs of my VBScript.
(I never bothered with VInterDev because at the time I
was a purely VB6 guy.)

I still have VS6 installed, and I still use it to write some COM and Win32
stuff in C++. I also like VS6 tech ref better than the newer incarnations,
it doesn't take a week to load, it doesn't try to force .net down my throat
with literally every search (even with all the .net topics cleared in the
filter) and most of all, it never gives me help for the IDE, or worse yet,
help for the help system, when I want API tech ref!

Plus I like VS6 as a generic text editor, it loads quickly enough to use it
for most things... but it doesn't let you debug script... Enter MSE or
Interdev -- which isn't really much more capable than MSE; the debugging
facilties are equal between them.

After all these years, and all this fighting FOR Microsoft,
I am ready, finally, to look at another vendor who respects
MY needs at least a little rather than _only_ HIS. One of my
needs is to support all the work I have already done while
making transitions to new technologies as I choose.

The product already is not supported. So why,exactly, did
they go through the trouble to break it further?

If their old technology becomes less practical/viable for any reason, the
new technology automatically becomes more practical/viable.