Classic ASP and ASP.Net - The "Big" Picture?
Metre Meter
also written some separate ASP.Net apps, my understanding is vague on
some larger issues
- What are the issues with mixing languages in Classic ASP? For
example, declaring variables, functions etc. in one language and
accessing/calling them in another?
- Where is the line between "native" language features (e.g. in
JScript), and those features which are part of .Net (or whatever),
common to all .Net languages? Or put another way, how are the .Net
facilities "mapped" onto a particular language?
- What environment does Classic ASP operate within (i.e. analogous to
ASP.Net programs operating under CLR)?
- What support to I have for the "native" Windows features under
ASP.Net? Is everything done through the CLR? Do I have more direct
access to Windows' native features under Classic ASP, or does that
restrict me in a different way? Is there anything in that vein that I
can do in Classic ASP that I can't do in ASP.Net?
- Do any languages (particularly JScript) have issues accessing the
full features of the Classic ASP or ASP.Net environment?
(I had a problem with JScript and collections once, but I was able
to work my way around it)
- Which is the best way to stucture my programs made up of multiple
files?
- Via #includes or via <script> tags? The latter sounds better,
but how do I include a jscript file within a jscript fileif there are
dependencies
- Should I really be developing ASP.Net "by hand" or using Visual
Studio anyway?
- What "type" of object does Server.CreateObject in Classic ASP
create?
I apologise if these questions seem somewhat vague, or if there are a
lot of them. As they're somewhat interconnected, please feel free to
answer them by pointing me towards any online resources. Any help is
appreciated- thank you!
Bob Barrows
> While I've been supporting a Classic ASP app for a while, and have
> also written some separate ASP.Net apps, my understanding is vague on
> some larger issues
>
documentation: http://msdn2.microsoft.com/en-us/library/ms524664
> - What are the issues with mixing languages in Classic ASP? For
> example, declaring variables, functions etc. in one language and
> accessing/calling them in another?
http://classicasp.aspfaq.com/general/does-order-matter-when-using-different-languages-in-asp.html
>
> - Where is the line between "native" language features (e.g. in
> JScript), and those features which are part of .Net (or whatever),
> common to all .Net languages? Or put another way, how are the .Net
> facilities "mapped" onto a particular language?
better asked in a dotnet group (this is a classic asp group)
microsoft.public.dotnet.framework.aspnet
www.asp.net
>
> - What environment does Classic ASP operate within (i.e. analogous to
> ASP.Net programs operating under CLR)?
Not sure I understand the question. ASP is run by an IIS server using
asp.dll
>
> - What support to I have for the "native" Windows features under
> ASP.Net? Is everything done through the CLR?
again, better asked in a dotnet group
> Do I have more direct
> access to Windows' native features under Classic ASP, or does that
> restrict me in a different way? Is there anything in that vein that I
> can do in Classic ASP that I can't do in ASP.Net?
Are you talking about access to the windows api? Don't even think about
it with script languages, which is all that classic ASP supports.
>
> - Do any languages (particularly JScript) have issues accessing the
> full features of the Classic ASP or ASP.Net environment?
I won't answer for .Net, but for classic ASP the answer is no
http://www.aspfaq.com/show.asp?id=2176
> (I had a problem with JScript and collections once, but I was able
> to work my way around it)
>
doesn't seem to be a question
> - Which is the best way to stucture my programs made up of multiple
> files?
> - Via #includes or via <script> tags?
For server-side code, I typically use server-side includes (#includes).
> The latter sounds better,
> but how do I include a jscript file within a jscript fileif there are
> dependencies
??? just do it?
Are you talking about client-side or server-side code?
> - Should I really be developing ASP.Net "by hand" or using Visual
> Studio anyway?
better asked in a dotnet group
>
> - What "type" of object does Server.CreateObject in Classic ASP
> create?
>
Whatever type is provided by the type library being referenced ...
set rs=createobject("adodb.recordset") causes the creation of an ADO
recordset object and returns a reference to it to the rs variable.
The "Server." part is not really necessary anymore. It used to be
recommended in earlier versions of IIS but is merely overhead now. Use
vbscript's CreateObject method instead.
--
HTH,
Bob Barrows
Tim Slattery
>- What are the issues with mixing languages in Classic ASP? For
>example, declaring variables, functions etc. in one language and
>accessing/calling them in another?
As far as I know, different languages live in different spaces. If
your ASP code contains blocks of VBScript and of server-side
JavaScript, the variables from VBScript will not be available to the
Javascript code. I don't think mixing languages like that is a good
idea anyway.
>- Where is the line between "native" language features (e.g. in
>JScript), and those features which are part of .Net (or whatever),
>common to all .Net languages? Or put another way, how are the .Net
>facilities "mapped" onto a particular language?
Can't help with .Net questions.
>- What environment does Classic ASP operate within (i.e. analogous to
>ASP.Net programs operating under CLR)?
Classic ASP is implemented by a filter that runs under IIS.
>- Do any languages (particularly JScript) have issues accessing the
>full features of the Classic ASP or ASP.Net environment?
For classic: I think JavaScript can do anything that VBScript can do.
For .Net: no clue
>- What "type" of object does Server.CreateObject in Classic ASP
>create?
An ActiveX component. It's implemented as a DLL, which must be
registered on the server. I've written such things in both VB and C++.
No doubt it can be done in other languages as well.
--
Tim Slattery
Slatt...@bls.gov
http://members.cox.net/slatteryt
Bob Barrows
> Metre Meter <metre...@yahoo.co.uk> wrote:
>
>> - What are the issues with mixing languages in Classic ASP? For
>> example, declaring variables, functions etc. in one language and
>> accessing/calling them in another?
>
> As far as I know, different languages live in different spaces. If
> your ASP code contains blocks of VBScript and of server-side
> JavaScript, the variables from VBScript will not be available to the
> Javascript code. I don't think mixing languages like that is a good
> idea anyway.
>
You can call vbscript functions from a jscript block and vice versa:
http://msdn.microsoft.com/en-us/library/aa260861(VS.60).aspx
--
HTH,
Bob Barrows
Evertjan.
microsoft.public.inetserver.asp.general:
functions and also variables are available to both:
==================
<% = a %>
<br>
<% = b() %>
<script language ='javascript' runat='server'>
var a = 'Blah';
function b() {
return 'Blip';
};
</script>
==================
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Metre Meter
> Metre Meter wrote:
> > - What are the issues with mixing languages in Classic ASP? For
> > example, declaring variables, functions etc. in one language and
> > accessing/calling them in another?
>
Yes, I'd come across that issue before, but that page lays it out
particularly clearly, thank you. It can definitely be a nuisance if
you don't understand that. :-/
> better asked in a dotnet group (this is a classic asp group)
>
> microsoft.public.dotnet.framework.aspnetwww.asp.net
Will do, thank you.
> > - What environment does Classic ASP operate within (i.e. analogous to
> > ASP.Net programs operating under CLR)?
>
> Not sure I understand the question. ASP is run by an IIS server using
> asp.dll
Sorry, that was badly phrased, probably because I hadn't thought it
out too well. Is there a resource that gives an overview of how the
different parts of IIS (including Classic ASP) work together, which
parts do what, and which processes run which, etc.?
> > Do I have more direct
> > access to Windows' native features under Classic ASP, or does that
> > restrict me in a different way? Is there anything in that vein that I
> > can do in Classic ASP that I can't do in ASP.Net?
>
> Are you talking about access to the windows api? Don't even think about
> it with script languages, which is all that classic ASP supports.
But the methods I can call on the Server.CreateObject created objects
are those of the same ADO COM object created by any other machines
(barring security considerations), right?
> doesn't seem to be a question
It was a side-note for the previous question
> - Which is the best way to stucture my programs made up of multiple
> > files?
> > - Via #includes or via <script> tags?
>
> For server-side code, I typically use server-side includes (#includes).
I get the impression that it's more a matter of personal choice (at
least as far as Classic ASP goes)?
> > but how do I include a jscript file within a jscript fileif there are
> > dependencies
> ??? just do it?
> Are you talking about client-side or server-side code?
Server-side JScript; e.g. if we have file foo.js which contains...
var blah = "whatever";
function some_function(in_param) {
return blah + another_function(in_param);
}
Then we have to include foo.js in our ASP file ("parent.asp") like
so...
<script language='jscript' runat='server' src='foo.js'></script>
But... some_function() in foo.js uses another_function(), which is
defined in bar.js, so we need to include that. But we can't include
<script> tags within foo.js itself, nor #include, because it's a
JScript file. We can of course add
<script language='jscript' runat='server' src='bar.js'></script>
in "parent.asp", but we have to remember to do that ourselves. Or
perhaps we should just #include our code file instead, like you said?
> > - What "type" of object does Server.CreateObject in Classic ASP
> > create?
>
> Whatever type is provided by the type library being referenced ...
>
> set rs=createobject("adodb.recordset") causes the creation of an ADO
> recordset object and returns a reference to it to the rs variable.
So it's generally a COM object of some sort?
Thanks for the feedback,
- MM
Metre Meter
> Metre Meter <metreme...@yahoo.co.uk> wrote:
> >- What "type" of object does Server.CreateObject in Classic ASP
> >create?
>
> An ActiveX component. It's implemented as a DLL, which must be
> registered on the server. I've written such things in both VB and C++.
An ActiveX ADO COM object?
- MM
Metre Meter
> functions and also variables are available to both:
Thanks for all the feedback on this subject.
-MM
Bob Barrows
For example, you can use CreateObject to instantiate a FileSystemObject:
set fso=createobject("scripting.filesystemobject")
You can even create your own ActiveX (COM) object as Tim described.
--
Microsoft MVP - ASP/ASP.NET - 2004-2007
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Bob Barrows
> Sorry, that was badly phrased, probably because I hadn't thought it
> out too well. Is there a resource that gives an overview of how the
> different parts of IIS (including Classic ASP) work together, which
> parts do what, and which processes run which, etc.?
Bird's-eye view:
IIS is a web server. It processes http requests* from clients, using ISAPI
filters to decide what to do with the requests. For .htm and .html requests,
it simply sends the requested page as the response. For .asp pages, it
passes the request to the asp.dll, which provides the objects described in
the documentation I pointed you at. The server-side script in the requested
.asp file runs and generates html which is written to the response and
passed to the client.
There's really not much more you need to know about the inner workings. But
if you're interested, I suggest you read the documentation I pointed you at
earlier.
>
> But the methods I can call on the Server.CreateObject created objects
> are those of the same ADO COM object created by any other machines
> (barring security considerations), right?
Other machines? No, it can only access activex dlls that are installed
(registered) on the machine on which the script is running.
> I get the impression that it's more a matter of personal choice (at
> least as far as Classic ASP goes)?
>
Yes. Personally, I always use ssi's for server-side code, or bits of html
that need to be used in multiple files.
Metre Meter
> Metre Meter wrote:
> > are those of the same ADO COM object created by any other machines
> > (barring security considerations), right?
>
> Other machines?
I've no idea why I typed "machines", because it's certainly not what I
meant(!) I'm pretty sure that it should have read by any other means".
> No, it can only access activex dlls that are installed
> (registered) on the machine on which the script is running.
That's very informative, thanks. So I can create all sorts of COM
objects, so long as they've been registered with the server?
- MM