ASP.Net - the "Big Picture"?

[Metre Meter]

Hi,

I have a few questions about ASP.Net, as I've been using it for a
while but my knowledge of the "big picture" is patchy in some areas.
Any help would be appreciated...

- 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? (I'm sorry of this
question is somewhat vague...)
- In a closely-related matter, do any languages have issues accessing
the full ASP.Net environment and facilities? For example, I found
accessing .Net Collections in JScript problematic (though I eventually
worked out how to do it).

- What support to I have for the "native" Windows features under
ASP.Net? Is everything done through the CLR? Can I access ADO COM
objects in a moderately straightforward manner with ASP.Net, or does
everything have to be done via the .Net facilities?

- Which is the best way to stucture my programs made up of multiple
files- via #includes or via <script> tags? Should I really be
developing ASP.Net "by hand" or using Visual Studio anyway?

- MM

 

[Scott M.]

Hi,

I have a few questions about ASP.Net, as I've been using it for a
while but my knowledge of the "big picture" is patchy in some areas.
Any help would be appreciated...

- 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? (I'm sorry of this
question is somewhat vague...)

ASP.NET just defines a web server archtecture that allows for processing on
a web server to occur. Access to all that ASP .NET has to offer is done via
"objects" that have properties and methods. When you write an ASP .NET
program, you use a .NET language, such as VB .NET or C# and, injected into
those language statements, you'll refer to these "ASP.NET" objects, which
are present and native to the web server via the ASP .NET installation into
the web server.

- In a closely-related matter, do any languages have issues accessing
the full ASP.Net environment and facilities?
No.

For example, I found
accessing .Net Collections in JScript problematic (though I eventually
worked out how to do it).

But, understand that JScript is not a native .NET language, it's a native
language understood by Internet Explorer.

- What support to I have for the "native" Windows features under
ASP.Net?

You'll have to define what you mean by "native Windows features". There are
many aspects of working with Windows directly that you don't want or need in
ASP.NET.

Is everything done through the CLR?
Yes.

Can I access ADO COM
objects in a moderately straightforward manner with ASP.Net, or does
everything have to be done via the .Net facilities?

To use non-.NET components, you'll have to create a .NET wrapper class for
them (which is pretty easy), so that you can access those interfaces via the
CLR.

- Which is the best way to stucture my programs made up of multiple
files- via #includes or via <script> tags?

Includes are dead, don't use them. Script tags are fine for JavaScript
libraries.

Should I really be
developing ASP.Net "by hand" or using Visual Studio anyway?

Use Visual Studio. You can get the Free Visual Studio Web Developer at:
http://microsoft.com/express.

-Scott

 

[Patrice]

Hello,

- 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? (I'm sorry of this
question is somewhat vague...)

JScript is not .NET based but is a scripting language that runs inside the
browser. Perhaps a confusion with J# ?
Base features are used through language specific keywords (for example "int"
in C# maps to the System.Int32 .NET type) that all compiles in the same
underlying low level assembly like language. The .NET language you are using
is just the glue. Beyond flow control instructions etc.. you'll call a
common library that can be used from whatever .NET based language you wish.

- In a closely-related matter, do any languages have issues accessing
the full ASP.Net environment and facilities?

No, there is a set or rules that makes those library usable from any .NET
language (Common Language Specification or CLS compliance).

For example, I found
accessing .Net Collections in JScript problematic (though I eventually
worked out how to do it).

JScript have nothing to do with .NET. You may want to post about this
particular issue in another thread. Your .NET code runs server side and you
could generate the jscript code to make a server side array available from
your client side JScript code.

- What support to I have for the "native" Windows features under
ASP.Net? Is everything done through the CLR?

The idea is to provide access to most if not all OS underlying features. You
can still call into the Win32 API or COM classes but it should be quite
rare.

Can I access ADO COM
objects in a moderately straightforward manner with ASP.Net, or does
everything have to be done via the .Net facilities?

You can. You can both consume COM classes from .NET code and expose .NET
code as COM Classes. For a new applicaztion it's likely better though to use
ADO.NET rather than to keep using the "old" ADO API...

- Which is the best way to stucture my programs made up of multiple
files- via #includes or via <script> tags?

Neither. This is now compiled as a whole project so #include and server side
script tags are no more usefull. General code is consumable from anywhere
you want.

Should I really be
developing ASP.Net "by hand" or using Visual Studio anyway?

VS will ease your life. You have free Express edition available from
msdn.microsoft.com/express

 

[Scott M.]

Hello,


Neither. This is now compiled as a whole project so #include and server
side script tags are no more usefull. General code is consumable from
anywhere you want.

The use of <script> tags is hardly "no more usefull". While there are new
..NET features to embed scripts into your assembly, this is not always
desireable. <script> tags will be around and viable for quite some time.

-Scott

 

[Patrice]

.NET features to embed scripts into your assembly, this is not always
desireable. <script> tags will be around and viable for quite some time.

I should likely have detailed. As the OP seems to mention this as an
alternative to #include, I believe he's talking specifically about using a
server script tag attribute with an src attribute pointing to server side
code (as could be done also in "Classic" ASP as a replacement for #include).

My remark doesn't include (no pun intended) other usage of the script tag
and especially its client side flavor...

 

[Gregory A. Beamer]

- 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? (I'm sorry of this
question is somewhat vague...)

If you are truly talking JScript, which is a client technology, and
ASP.NET, .NET, etc., they are not related whatsoever. JScript is a
client side technology that works in a browser and ASP.NET is a server
side platform. You can output JScript (JavaScript, ECMAScript) for the
client side, but it is not part of ASP.NET.

If you mean languages like J#, F#, C#, VB, et al, the language is the
means of programming for ASP.NET, but ASP.NET is simply the web
framework, or container, etc.

- In a closely-related matter, do any languages have issues accessing
the full ASP.Net environment and facilities? For example, I found
accessing .Net Collections in JScript problematic (though I eventually
worked out how to do it).

Any client side language requires you understand the client side
rendering to play with the "components". Once the page has left the
server, it is now a mixture of HTML, CSS and JavaScript. There is .NET
potential in Silverlight, but a standard ASP.NET page renders as XHTML,
CSS and script. That is all.

This relates back to how the web works. I have a couple of entry level
posts on my blog that might be useful to you:

This one is on how data works in .NET, but also covers a bit of the web
Request Response mechanism:
http://bit.ly/8MCMDK

This one explains Request/Response, esp. as related to cookies:
http://bit.ly/87Kdzq

These are more "big picture" types of posts.

- What support to I have for the "native" Windows features under
ASP.Net? Is everything done through the CLR? Can I access ADO COM
objects in a moderately straightforward manner with ASP.Net, or does
everything have to be done via the .Net facilities?

You are mixing CLR (the run time) with Interop (access COM bits) with
compilation, etc.

All .NET runs under the CLR. It can run COM and native bits through
interop. For COM, you use tlbimp.exe to create a .NET callable wrapper.
This can be done by adding a reference, so you don't really have to
understand type library imports and exports (although they are big
picture bits). The book CLR with C# or CLR with VB (Richter) are great
big picture books for understanding how .NET works.

Add a reference to the ADO library and you end up with the ADO objects
in a .NET wrapper. The question, however, is why you would want to do
this, as the new model is much more efficient and relatively easy to
learn enough you won't want to go back.

- Which is the best way to stucture my programs made up of multiple
files- via #includes or via <script> tags?

#include files are not the best way in ASP.NET. Now, the answer, beyond
that, is tricky.

For multiple code files, encapsulate the logic in libraries or create
controls or master pages. This is one way to reuse the code over and
over again.

For client side script, i would Google JavaScript libraries and
encapsulate the logic that way. Don't reinvent the wheel, however, and
look for client side libraries that are open source first.

Should I really be
developing ASP.Net "by hand" or using Visual Studio anyway?

Visual Studio is a tool that can save you a lot of time. It is your
decision on whether it is for you, but I would recommend it.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Metre Meter]

No.

Good to know that, thanks.

But, understand that JScript is not a native .NET language, it's a native
language understood by Internet Explorer.

Sure, I appreciate that. It was JScript I had in mind when I asked the
question. I'd be quite surprised if C# had trouble accessing the .Net
features

You'll have to define what you mean by "native Windows features".  There are
many aspects of working with Windows directly that you don't want or needin
ASP.NET.

COM objects, MFC access, etc.?

To use non-.NET components, you'll have to create a .NET wrapper class for
them (which is pretty easy), so that you can access those interfaces via the
CLR.

That's interesting, I'll look into that.

Includes are dead, don't use them.  Script tags are fine for JavaScript
libraries.

The problem I've had with script tags is where the included script
(bar.js) is itself dependent on functions or variables defined in
another Javascript file (foo.js). While you can manually include both
foo.js and bar.js in the ASP.Net page- if you remember- there seems to
be no way of doing this automatically, because .js files themselves
can't include another script file.

OTOH, since ASP.Net is compiled, ths problem's not as big as it could
be in Classic ASP- where (e.g.) a missing foo.js might not be always
be spotted if the dependent part of the script doesn't execute
immediately.

Use Visual Studio.  You can get the Free Visual Studio Web Developer at:http://microsoft.com/express.

I'll check that out, though I'm guessing that for serious work I'll
have to get my hands on a moderately recent version of the full
commercial release. (No, I'm not a student at present, unfortunately).

Thanks for the info!

- MM

 

[Metre Meter]

JScript is not .NET based but is a scripting language that runs inside the
browser. Perhaps a confusion with J# ?

No; JScript- or at least something that claims to be JScript- is
supported by ASP.Net. (See my answer to Gregory A. Beamer- who seems
to be saying the same thing- in this thread). However, I do realise
that it- or rather LiveScript/JavaScript- wasn't originally designed
around .Net.

The .NET language you are using is just the glue.

That's pretty much how I was viewing it, yes.

No, there is a set or rules that makes those library usable from any .NET
language (Common Language Specification or CLS compliance).

That's the type of concrete answer I like!

Thank you,

- MM

 

[Metre Meter]

If you are truly talking JScript, which is a client technology, and
ASP.NET, .NET, etc., they are not related whatsoever. JScript is a
client side technology that works in a browser and ASP.NET is a server
side platform. You can output JScript (JavaScript, ECMAScript) for the
client side, but it is not part of ASP.NET.

I'm aware of the difference between client and server-side, and the
fact that I can use the latter to generate the former, but that's not
what I meant.

Perhaps I misunderstood where you're coming from. ASP.Net supports
what claims to be server-side JScript like so:-

<script language='jscript' runat='server'>
Response.Write("Hi there!");
</script>

which (as far as the browser is concerned) is replaced with "Hi
there!" and nothing else.

All .NET runs under the CLR. It can run COM and native bits through
interop. For COM, you use tlbimp.exe to create a .NET callable wrapper.
This can be done by adding a reference, so you don't really have to
understand type library imports and exports (although they are big
picture bits). The book CLR with C# or CLR with VB (Richter) are great
big picture books for understanding how .NET works.

Add a reference to the ADO library and you end up with the ADO objects
in a .NET wrapper. The question, however, is why you would want to do
this, as the new model is much more efficient and relatively easy to
learn enough you won't want to go back.

I'm not much of an expert when it comes to .Net or traditional
Windows, but this sounds interesting.

As to why I'd want to do it? I might not, necessarily, but I like to
know where I stand with regards to facilities, etc. FWIW, I can think
of at least one case where I was converting a Classic ASP script to
ASP.Net and wasn't sure how to re-implement it in ASP.Net. I ended up
rewriting it to use the .Net facilities, and you're right- it was
better that way anyway.

Thank you also for the links and comments about Visual Studio, I'll
take a look at them.

-MM

 

[Scott M.]

"Metre Meter" <[email protected]> wrote in message

You'll have to define what you mean by "native Windows features". There
are
many aspects of working with Windows directly that you don't want or need
in
ASP.NET.

COM objects, MFC access, etc.?

-ASP .NET has the same ability to access Windows features as the rest of the
..NET Framework does. COM object, as I've described, are accessible via .NET
wrapper classes (InterOp). Many Windows functions are available via .NET
objects, and traditional API calls are also still available.

Includes are dead, don't use them. Script tags are fine for JavaScript
libraries.

The problem I've had with script tags is where the included script
(bar.js) is itself dependent on functions or variables defined in
another Javascript file (foo.js).

-This isn't a .NET issue at all and has always been something client-side
code has had to deal with. Since browsers "read" what's sent to them in
order, it's important that dependent .js libararies be sent prior to the
libraries that depend on them.


While you can manually include both
foo.js and bar.js in the ASP.Net page- if you remember- there seems to
be no way of doing this automatically, because .js files themselves
can't include another script file.

-Actually, ASP .NET does have a way to cause the .js libraries to be sent in
a way that ensures that dependent libraries are delivered prior to the
libraries that use them. In addition, you can now embed .js libraries into
your compiled .dll for easier deployment and versioning.

OTOH, since ASP.Net is compiled, ths problem's not as big as it could
be in Classic ASP- where (e.g.) a missing foo.js might not be always
be spotted if the dependent part of the script doesn't execute
immediately.

-I'm not sure what you are getting at here. ASP .NET being compiled has
nothing to do with traiditional .js library usage. Even in ASP.NET, if you
are missing a .js, you won't be informed about it until something in the .js
is called for. I don't think you've fully gotten that anything having to do
with ASP.NET happens at the web server and anything having to do with
executing JScript happens at the client. While (as mentioned), there are
abilities to embed your .js libraries into a .NET .dll and while you can use
ASP .NET to generate client-side JScript, ASP .NET does not execute and is
not responsible for the execution of JScript (or any other client-side
technology). The two technologies are not related - at all.

Use Visual Studio. You can get the Free Visual Studio Web Developer
at:http://microsoft.com/express.

I'll check that out, though I'm guessing that for serious work I'll
have to get my hands on a moderately recent version of the full
commercial release. (No, I'm not a student at present, unfortunately).

-The express versions are fully up to date, they just don't have all the
bells and whistles that the professional versions do. You can build full
..NET applications with the express editions.

-Scott

 

[Scott M.]

JScript is not .NET based but is a scripting language that runs inside the
browser. Perhaps a confusion with J# ?

No; JScript- or at least something that claims to be JScript- is
supported by ASP.Net.

-No, that's incorrect. As I've mentioned, JScript is a client-side
scripting language that has no relationship with .NET whatsoever. It is
executed by the client, not the .NET CLR.

-Scott

 

[Scott M.]

On Jan 8, 4:49 pm, "Gregory A. Beamer"

Perhaps I misunderstood where you're coming from. ASP.Net supports
what claims to be server-side JScript like so:-

<script language='jscript' runat='server'>
Response.Write("Hi there!");
</script>

-No, this is not ASP .NET. This is what we now call "Classic ASP". As
we've stated, JScript is not a .NET langauge in any way. You are
misunderstanding your usage of the tags here as ASP.NET. The code you show
here does not execute within the ASP .NET engine or the CLR.

-Scott

 

[Metre Meter]

On Jan 8, 4:49 pm, "Gregory A. Beamer"


Perhaps I misunderstood where you're coming from. ASP.Net supports
what claims to be server-side JScript like so:-

<script language='jscript' runat='server'>
    Response.Write("Hi there!");
</script>

-No, this is not ASP .NET.  This is what we now call "Classic ASP".  As
we've stated, JScript is not a .NET langauge in any way.  You are
misunderstanding your usage of the tags here as ASP.NET.  The code you show
here does not execute within the ASP .NET engine or the CLR.

-Scott

Can you please clarify what is happening here. The following code is
placed in the ASPX file "test.aspx" on the server:-

<!-- START FILE test.aspx -->
<%@page debug='true' language='jscript' %>
<script language='jscript' runat='server'>
var foo : System.Drawing.Drawing2D.ColorBlend = new
System.Drawing.Drawing2D.ColorBlend(); // .Net object created?
</script>
<%
Response.Write("Object foo is '" + foo + "'");
%>
<!-- END FILE test.aspx -->

This is executed *on the server*, resulting in the browser only ever
seeing this:-

<!-- START FILE test.aspx -->
Object foo is 'System.Drawing.Drawing2D.ColorBlend'
<!-- END FILE test.aspx -->

The class used above, System.Drawing.Drawing2D.ColorBlend is listed by
Microsoft as a .Net Framework class at:-
http://msdn.microsoft.com/en-us/library/system.drawing.drawing2d.colorblend(VS.80).aspx
with example syntax given in (amongst others) JScript.

Also, there is something called "JScript .NET" (see
http://en.wikipedia.org/wiki/JScript_.NET ). With respect, you can
probably understand why I am confused(!)

- MM

 

[Metre Meter]

I don't think you've fully gotten that anything having to do
with ASP.NET happens at the web server and anything having to do with
executing JScript happens at the client.

(Please see my reply to one of your other posts within this thread
with an example of JScript within a .aspx page apparently creating
a .Net object *on the server*- not within the browser- and mention of
"JScript.NET". If that isn't strictly ASP.Net by some definition, can
you please clarify. Thank you)

- MM

 

[Scott M.]

On Jan 8, 4:49 pm, "Gregory A. Beamer"


Perhaps I misunderstood where you're coming from. ASP.Net supports
what claims to be server-side JScript like so:-

<script language='jscript' runat='server'>
Response.Write("Hi there!");
</script>

-No, this is not ASP .NET. This is what we now call "Classic ASP". As
we've stated, JScript is not a .NET langauge in any way. You are
misunderstanding your usage of the tags here as ASP.NET. The code you show
here does not execute within the ASP .NET engine or the CLR.

-Scott

Can you please clarify what is happening here. The following code is
placed in the ASPX file "test.aspx" on the server:-

<!-- START FILE test.aspx -->
<%@page debug='true' language='jscript' %>
<script language='jscript' runat='server'>
var foo : System.Drawing.Drawing2D.ColorBlend = new
System.Drawing.Drawing2D.ColorBlend(); // .Net object created?
</script>
<%
Response.Write("Object foo is '" + foo + "'");
%>
<!-- END FILE test.aspx -->

This is executed *on the server*, resulting in the browser only ever
seeing this:-

<!-- START FILE test.aspx -->
Object foo is 'System.Drawing.Drawing2D.ColorBlend'
<!-- END FILE test.aspx -->

The class used above, System.Drawing.Drawing2D.ColorBlend is listed by
Microsoft as a .Net Framework class at:-
http://msdn.microsoft.com/en-us/library/system.drawing.drawing2d.colorblend(VS.80).aspx
with example syntax given in (amongst others) JScript.

Also, there is something called "JScript .NET" (see
http://en.wikipedia.org/wiki/JScript_.NET ). With respect, you can
probably understand why I am confused(!)

JScript and JScript.NET are two separate and distinct things. You are
gettting the two confused. What's happening is that you are writing Classic
ASP code, which is being executed as such, not by the CLR.

JScript.NET is not native to VS and unless you have some specific reason to
use it, you shouldn't.

-Scott

 

[Patrice]

This is likely JScript.NET
(http://msdn.microsoft.com/en-us/library/ms974588.aspx) that I mistakenly
named J# which is still something else. You could use the ScriptEngineXXX
function to find out what version it is...

Actually I tried here and got JScript v 8.0.50727 server side and JScript v
5.8.18795 client side so as you see this is not the same scripting engine.

Is this just because you thought it would be easier in a specific case or do
you really have all your server code in JScript.NET ?

 

[Metre Meter]

This is likely JScript.NET

Yes, that's highly probable(!)

(http://msdn.microsoft.com/en-us/library/ms974588.aspx) that I mistakenly
named J# which is still something else.

Yes; as far as I'm aware, J# is (essentially) a .Net language with the
same basic syntax as Java, but using the .Net framework objects and
compiling to CIL bytecode instead.

Is this just because you thought it would be easier in a specific case ordo
you really have all your server code in JScript.NET ?

I've written one app in JScript.NET; my already minimal C# knowledge
was quite rusty at that time, I'd been using JScript (and client-side
JavaScript) at the time anyway, and it was quicker and simpler to use.
I was pretty aware that it wasn't that serious (or ".NET-ish") a
language though.

I wrote a more recent app in C# and would be more likely to use that
in future anyway.

- MM

 

[Metre Meter]

JScript and JScript.NET are two separate and distinct things.  You are
gettting the two confused.

No. I was already aware that ASP.Net's version of JScript
(compiled, .Net-based, improved syntax) was significantly different to
the interpreted version.

I just wasn't aware that it was specifically called "JScript.Net".

Any confusion appears to come from this use of terminology. When I
referred to "jscript" in the context of ASP.Net (*), I had assumed it
would be obvious that I meant ASP.Net's version of JScript (i.e.
JScript.Net).

However, it appears that by not specifically using its official name
of "JScript.NET", it was assumed I was talking about old-school ASP
JScript. Or client-side JScript. Or something....(?!)

Hence my confusion at statements like "ASP.NET does not execute and is
not responsible for the execution of JScript"...

Since even MS seem quite happy to call it just "JScript" when the
context makes obvious that they mean JScript.NET (e.g. the JScript
declaration on this .Net documentation page:-
http://msdn.microsoft.com/en-us/library/system.drawing.drawing2d.matrix.aspx
), it's... strange that this was not picked up on.

Oh well.

What's happening is that you are writing Classic
ASP code

I'm not clear what you're referring to here. The "test.aspx" example
above appears to be running as an ASP.Net page and invoking a .Net
framework object within the JScript (or rather, JScript.NET) <script>
block.

If that's incorrect, can you please describe which parts- if any- of
that example are Classic ASP.

JScript.NET is not native to VS and unless you have some specific reason to
use it, you shouldn't.

I've used it in the past because it's convenient (and because my C#
was rusty at the time), but even then it was apparent that it wasn't a
"native" .Net language, nor the best choice for anything beyond small
projects. (Though it's still a major improvement on Classic ASP's
interpreted JScript).

I've used C# for more recent stuff.

- MM

 

[Metre Meter]

No. I was already aware that ASP.Net's version of JScript
(compiled, .Net-based, improved syntax) was significantly different to
the interpreted version.

Clarification; should read "... significantly different to the
interpreted version provided by Classic ASP".

- MM

 

[Patrice]

Ok crystal clear now.

As you see using JScript client side is mainstream (actually JScript is MS
implementation, we should even say javascript here) as this is the defacto
scripting language for browsers but seeing someone using JScript.NET server
side is quite unusual as you can see ;-)

I failed to find a detailed comparison but FYI you may want to check :
http://en.wikipedia.org/wiki/JScript_.NET#Differences_with_C.23