ASP.Net - the "Big Picture"?

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
0
Metre
1/7/2010 9:55:05 PM
dotnet.framework.aspnet 1425 articles. 0 followers. Follow

25 Replies
1308 Views

Similar Articles

[PageSpeed] 16

"Metre Meter" <metremeter@yahoo.co.uk> wrote in message 
news:9a7d595a-374f-4af0-bcf2-d62785c93202@21g2000yqj.googlegroups.com...
> 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 


0
Scott
1/7/2010 10:15:50 PM
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

--
Patrice

0
Patrice
1/8/2010 10:46:25 AM
"Patrice" <http://scribe-en.blogspot.com/> wrote in message 
news:eYtdT$EkKHA.3476@TK2MSFTNGP06.phx.gbl...
> Hello,
>
>> - 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.
>
> --
> Patrice
>

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 


0
Scott
1/8/2010 1:40:26 PM
> 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.

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


0
Patrice
1/8/2010 2:44:48 PM
Metre Meter <metremeter@yahoo.co.uk> wrote in news:9a7d595a-374f-4af0-
bcf2-d62785c93202@21g2000yqj.googlegroups.com:

> - 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!             |
*******************************************
0
Gregory
1/8/2010 4:49:47 PM
On Jan 7, 10:15=A0pm, "Scott M." <s-...@nospam.nospam> wrote:
> "Metre Meter" <metreme...@yahoo.co.uk> wrote in message
> > - In a closely-related matter, do any languages have issues accessing
> > the full ASP.Net environment and facilities?
>
> No.

Good to know that, thanks.

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

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

> > - 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". =A0Ther=
e are
> many aspects of working with Windows directly that you don't want or need=
 in
> ASP.NET.

COM objects, MFC access, etc.?

> >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 fo=
r
> them (which is pretty easy), so that you can access those interfaces via =
the
> CLR.

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

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

> >Should I really be
> > developing ASP.Net "by hand" or using Visual Studio anyway?
>
> Use Visual Studio. =A0You 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
0
Metre
1/8/2010 9:27:20 PM
On Jan 8, 10:46=A0am, "Patrice" <http://scribe-en.blogspot.com/> wrote:
> JScript is not .NET based but is a scripting language that runs inside th=
e
> 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

0
Metre
1/8/2010 9:36:23 PM
On Jan 8, 4:49=A0pm, "Gregory A. Beamer"
<NoSpamMgbwo...@comcast.netNoSpamM> wrote:
> 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=3D'jscript' runat=3D'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
0
Metre
1/8/2010 9:52:56 PM
"Metre Meter" <metremeter@yahoo.co.uk> wrote in message 
news:fb26529f-8054-4331-bf12-539f78d9f753@j14g2000yqm.googlegroups.com...
On Jan 7, 10:15 pm, "Scott M." <s-...@nospam.nospam> wrote:
> "Metre Meter" <metreme...@yahoo.co.uk> 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.

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

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.

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

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 


0
Scott
1/8/2010 10:03:34 PM
"Metre Meter" <metremeter@yahoo.co.uk> wrote in message 
news:de838d46-7d9d-4c05-84ea-56584b795dc1@m25g2000yqc.googlegroups.com...
On Jan 8, 10:46 am, "Patrice" <http://scribe-en.blogspot.com/> wrote:
> 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 


0
Scott
1/8/2010 10:05:41 PM
"Metre Meter" <metremeter@yahoo.co.uk> wrote in message 
news:67cded3d-fffb-45a5-900a-556759f9543e@r5g2000yqb.googlegroups.com...
On Jan 8, 4:49 pm, "Gregory A. Beamer"
<NoSpamMgbwo...@comcast.netNoSpamM> wrote:

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 


0
Scott
1/8/2010 10:09:00 PM
> 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.

Ok so it seems to be really JScript that doesn't use the .NET runtime..NET 
though provide functions to support the use of JScript client side 
(including for example generating client side javascript proxies to access 
web services).

I noticed the js portion response in the other thread but :
- if something is missing, AFAIK ASP.NET won't be any more helpfull than ASP 
classic in respect with that (perhaps warns if the file is missing but if 
you forgot to specify the file...)
- not sure if this is what you mean but you could try to give a close look 
at the script manager (AFAIK it includes script file dependencies and you 
could likely add your own dependencies if you have numerous js files)

--
Patrice

0
Patrice
1/8/2010 10:14:52 PM
On Jan 8, 10:09=A0pm, "Scott M." <s-...@nospam.nospam> wrote:
> "Metre Meter" <metreme...@yahoo.co.uk> wrote in message
>
> news:67cded3d-fffb-45a5-900a-556759f9543e@r5g2000yqb.googlegroups.com...
> On Jan 8, 4:49 pm, "Gregory A. Beamer"
>
> <NoSpamMgbwo...@comcast.netNoSpamM> wrote:
>
> Perhaps I misunderstood where you're coming from. ASP.Net supports
> what claims to be server-side JScript like so:-
>
> <script language=3D'jscript' runat=3D'server'>
> =A0 =A0 Response.Write("Hi there!");
> </script>
>
> -No, this is not ASP .NET. =A0This is what we now call "Classic ASP". =A0=
As
> we've stated, JScript is not a .NET langauge in any way. =A0You are
> misunderstanding your usage of the tags here as ASP.NET. =A0The 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=3D'true' language=3D'jscript' %>
<script language=3D'jscript' runat=3D'server'>
	var foo : System.Drawing.Drawing2D.ColorBlend =3D 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=
%28VS.80%29.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
0
Metre
1/8/2010 11:15:48 PM
On Jan 8, 10:03=A0pm, "Scott M." <s-...@nospam.nospam> wrote:
> 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
0
Metre
1/8/2010 11:25:58 PM
"Metre Meter" <metremeter@yahoo.co.uk> wrote in message 
news:633a7c5e-a266-4dcd-9f58-9b21eea65f8a@j4g2000yqe.googlegroups.com...
On Jan 8, 10:09 pm, "Scott M." <s-...@nospam.nospam> wrote:
> "Metre Meter" <metreme...@yahoo.co.uk> wrote in message
>
> news:67cded3d-fffb-45a5-900a-556759f9543e@r5g2000yqb.googlegroups.com...
> On Jan 8, 4:49 pm, "Gregory A. Beamer"
>
> <NoSpamMgbwo...@comcast.netNoSpamM> wrote:
>
> 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%28VS.80%29.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


0
Scott
1/9/2010 12:04:07 AM
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 ?

--
Patrice

0
Patrice
1/9/2010 10:37:31 AM
On Jan 8, 10:14=A0pm, "Patrice" <http://scribe-en.blogspot.com/> wrote:
> - if something is missing, AFAIK ASP.NET won't be any more helpfull than =
ASP
> classic in respect with that (perhaps warns if the file is missing but if
> you forgot to specify the file...)

What I meant is that if (e.g.) your code is going to throw up an
error- because you forget to include the other file that defined the
thing being referred to- this will happen immediately and obviously at
compile-time with ASP.Net rather than only being spotted when that
particular line is executed (when using interpreted scripts like
Classic ASP does). For example

if (something_uncommon_happens) {
   refer to object;  // But... oops, we forgot to include other file
where object defined.
}

- MM
0
Metre
1/9/2010 7:49:13 PM
Ok, you are likely right as it seems you are talking about JScript.NET that 
you seems to use as your server side language (usually it's rather C# or 
VB). It doesn't apply to client side JScript.

--
Patrice

"Metre Meter" <metremeter@yahoo.co.uk> a �crit dans le message de 
news:aac61025-336a-4225-b9e7-af7964e4a83d@z41g2000yqz.googlegroups.com...
On Jan 8, 10:14 pm, "Patrice" <http://scribe-en.blogspot.com/> wrote:
> - if something is missing, AFAIK ASP.NET won't be any more helpfull than 
> ASP
> classic in respect with that (perhaps warns if the file is missing but if
> you forgot to specify the file...)

What I meant is that if (e.g.) your code is going to throw up an
error- because you forget to include the other file that defined the
thing being referred to- this will happen immediately and obviously at
compile-time with ASP.Net rather than only being spotted when that
particular line is executed (when using interpreted scripts like
Classic ASP does). For example

if (something_uncommon_happens) {
   refer to object;  // But... oops, we forgot to include other file
where object defined.
}

- MM 

0
Patrice
1/9/2010 8:01:54 PM
On Jan 9, 10:37=A0am, "Patrice" <http://scribe-en.blogspot.com/> wrote:
> 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 or=
 do
> 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
0
Metre
1/9/2010 8:17:05 PM
On Jan 9, 12:04=A0am, "Scott M." <s-...@nospam.nospam> wrote:
> JScript and JScript.NET are two separate and distinct things. =A0You 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.asp=
x
), 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
0
Metre
1/9/2010 9:43:45 PM
On Jan 9, 9:43=A0pm, Metre Meter <metreme...@yahoo.co.uk> wrote:
> 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
0
Metre
1/9/2010 9:46:24 PM
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

--
Patrice 

0
Patrice
1/9/2010 10:36:50 PM
"Metre Meter" <metremeter@yahoo.co.uk> wrote in message 
news:38d569ae-bbcf-4985-8e5a-c7ab695b4846@m16g2000yqc.googlegroups.com...
On Jan 9, 9:43 pm, Metre Meter <metreme...@yahoo.co.uk> wrote:
> 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

Yes, JScript and JScript.NET are very different and the term that you use is 
very important when distinguishing between the two.  Quite frankly, 
JScript.NET is not widely used at all as it makes little sense as to why 
you'd want to use it.  When you initially ask about JScript.NET's ability to 
access/leverage all that the .NET Framework has to offer, you really should 
have been asking whether using JScript.NET as your interface to the .NET 
Framework will limit how robust your code can be...and the answer to that is 
yes!

VB .NET and C# are the native .NET languages (well also C++ .NET, but that 
is only used in special circumstances) and these are both very mature 
languages with very rich feature sets.  They can both be strongly typed at 
the same time as providing mechanisms for dynamic typing (pretty cool 
stuff!), which provides a whole level of code stability that JScript.NET 
won't have.  It's not about what aspects of the .NET Framework are 
available, they are all available. But, the .NET Framework is not the 
language.  Think of it this way...no matter what language you speak 
(English, French, Spanish, etc.), you use a stapler the same way...you place 
the paper into it and press down with enough force as to make sure the 
staple goes all the way through.  My point being that to use the stapler 
object does not rely on the language you are speaking.  To use the .NET 
Framework (and the CLR), the langauge you choose doesn't matter as far as 
accessing the feature set of the Framework.  However, ask different people 
that speak different languages to describe the inner-workings of the 
internal combustion engine and you will find that, in different languages, 
there are not always word for word translations.  Grammar, conjugation, and 
pronounciation will all affect "how" you say what you are saying.  Some 
languages are more difficult to learn and understand because one word can 
have different meanings and therefore some languages are better than others 
for particular forms of speech.

Because JScript.NET is modled after JScript, which was modled after 
JavaScript, which was modled after C, you'll find learning C# fairly simple 
in the beginning, which is what most people who have a background in C style 
languages do.

Lastly, when you move to using Visual Studio for your development, you'll 
find that you may not want to embed your code into the .aspx page via a 
<script> tag at all (inline coding) as this has compile and security 
implications that you might not find desireable.  Instead, you may wish to 
choose a more popular "code-behind" pattern, where your code is written into 
a completely different file from your client-side code.

In my opinion, JScript.NET offers nothing advantagous to .NET development 
and will actually impede your coding.

-Scott



0
Scott
1/10/2010 5:37:58 PM
On Jan 10, 5:37=A0pm, "Scott M." <s-...@nospam.nospam> wrote:
> Yes, JScript and JScript.NET are very different and the term that you use=
 is
> very important when distinguishing between the two.

True, but as the link I gave showed, even MS simply call it "JScript"
when the context makes it obvious that it's the .Net-flavoured version
that's being referred to.

With respect- bearing in mind particularly that it was in the context
of a question about ASP.Net, and one being asked by someone with
patchy experience at that- I'm surprised that it caused so much
confusion.

> Quite frankly,
> JScript.NET is not widely used at all as it makes little sense as to why
> you'd want to use it.

Because it was quick and easy at the time and my C# skills were rusty.
I've used C# for a more recent project.

> In my opinion, JScript.NET offers nothing advantagous to .NET development

Whether one approves of it or not, I think it's going a bit far to say
it offers *no* advantages. Its less formal, more "script" style and
looser typing makes writing quick and short, less serious code quicker
than in (e.g.) C#.

(Assuming you're not using VS, of course).

Of course, I would agree entirely that those same aspects probably
make it a poor choice for larger projects (or indeed, anything large
enough to be considered a "project"!)

> and will actually impede your coding. [..] you really should
> have been asking whether using JScript.NET as your interface to the .NET
> Framework will limit how robust your code can be...and the answer to that=
 is
> yes!

Yes, I agree that JScript (in any form) isn't such a great choice for
larger projects.

> VB .NET and C#

Ugh, hate the VB.Net syntax, would rather use C# anyway.

> But, the .NET Framework is not the language.

That's okay, I understand that!

> you'll find learning C# fairly simple
> in the beginning

When I used it for the first time- albeit as a one-off years ago- it
reminded me of Java with some improvements (and a different object
model, of course).

- MM
0
Metre
1/10/2010 10:25:19 PM
"Metre Meter" <metremeter@yahoo.co.uk> wrote in message 
news:3513cc69-bcec-4637-8011-5e1fb66e9326@a21g2000yqc.googlegroups.com...
On Jan 10, 5:37 pm, "Scott M." <s-...@nospam.nospam> wrote:
> Yes, JScript and JScript.NET are very different and the term that you use 
> is
> very important when distinguishing between the two.

True, but as the link I gave showed, even MS simply call it "JScript"
when the context makes it obvious that it's the .Net-flavoured version
that's being referred to.

With respect- bearing in mind particularly that it was in the context
of a question about ASP.Net, and one being asked by someone with
patchy experience at that- I'm surprised that it caused so much
confusion.

- That's because, it's not widely used at all and, despite Microsoft 
referring to JScript.NET as just JScript, that is not what the programming 
community in general tends to think when you say JScript (as you've seen). 
Also, when you start using Visual Studio, you'll find that placing your 
compiled code into the .aspx is not necessarially the norm and (as I 
mentioned) your questions about the use of <script> tags made those of us 
experienced in .NET development assume you meant client-side JScript, 
because server-side code is very often not embedded inline into the .aspx 
page at all, thus removing the need for any use of the <script> tag for 
server-side programming.

I think that as you learn more about doing ASP.NET development, it will 
become clear that your question(s)/comments were actually making it 
difficult to understand you were talking about a server-side use for 
JScript.

> Quite frankly,
> JScript.NET is not widely used at all as it makes little sense as to why
> you'd want to use it.

Because it was quick and easy at the time and my C# skills were rusty.
I've used C# for a more recent project.

> In my opinion, JScript.NET offers nothing advantagous to .NET development

Whether one approves of it or not, I think it's going a bit far to say
it offers *no* advantages. Its less formal, more "script" style and
looser typing makes writing quick and short, less serious code quicker
than in (e.g.) C#.

- It's not about my "approval". It's about my experience (and that of many 
others).  What I've learned in my experience, is that to really get the most 
of .NET, you don't want script style code that is loosly typed and I think 
that JScript.NET's failure to find a mainstream audience bears that out.

(Assuming you're not using VS, of course).

Of course, I would agree entirely that those same aspects probably
make it a poor choice for larger projects (or indeed, anything large
enough to be considered a "project"!)

- I would argue that it's a poor choice for any project.  The fact is that 
if you are going to work with .NET, you are in for a learning curve, there's 
just no way around that.  To say that you'll accept sloppy, late bound code 
that doesn't scale well and is prone to runtime errors because the project 
is small is not a convincing argument.  If you truly like the loosly-typed, 
script style of server side programming, you should stick with Classic ASP.

> and will actually impede your coding. [..] you really should
> have been asking whether using JScript.NET as your interface to the .NET
> Framework will limit how robust your code can be...and the answer to that 
> is
> yes!

Yes, I agree that JScript (in any form) isn't such a great choice for
larger projects.

> VB .NET and C#

Ugh, hate the VB.Net syntax, would rather use C# anyway.

> But, the .NET Framework is not the language.

That's okay, I understand that!

> you'll find learning C# fairly simple
> in the beginning

When I used it for the first time- albeit as a one-off years ago- it
reminded me of Java with some improvements (and a different object
model, of course).

But since Java and JScript (and C# for that matter) are all modled 
(syntaticly) after C-style programming, choosing JScript over C# doesn't 
seem to make sense.

-Scott


0
Scott
1/10/2010 11:16:48 PM
Reply:

Similar Artilces:

ASP.Net
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 A...

Queries Versus Views
I have written many Access reports I would now like to make available via MS SS RS. Many of my reports rely on queries that relies on 2-3-4 other queries. Nested queries, sub-queries, whatever you want to call them. Often this is because of differences between the ways I need the data (one row, many columns) and the way it is stored (many rows, one column). What is the most efficient way to deal with nested queries, sub- queries, or whatever in MS SS RS? Create views instead of queries? I don't seem to be able to create one data set based on another... Thanks, Patr...

The BIG Picture (VB vs the OS)
When programming (in VB or any other language), the BIG picture of how things fits together with the OS tends to get lost. The capabilities of what the OS can do (e.g. Scan, Fax, Remote, TAPI, MAPI, etc. etc) has significantly increased -- and you can write VB to use most of it -- but understanding what are all the OS capabilities, and those parts fit together or interrelate is /has become a major concern. Anyone know of a block diagram or book which puts/lists all the OS capabilites and either or list or explanation of what is done under each? Hello, I always tend...

How I recall e-mail due to big picture attachment
How can I recall e-mail attachment due to a big picture - overlimit bytes? I tried to delete or stop transmit, but it still continue being transmitting. I can't send more e-mails with attachments til this e-mail transmit is completed. http://www.outlook-tips.net/howto/stuck_message.htm -- Diane Poremsky [MVP - Outlook] Author, Teach Yourself Outlook 2003 in 24 Hours Coauthor, OneNote 2003 for Windows (Visual QuickStart Guide) Author, Google and Other Search Engines (Visual QuickStart Guide) Outlook Tips: http://www.outlook-tips.net/ Outlook & Exchange Solutions Center: http://ww...

how much can you shrink a big picture without loosing the picture?
What I am trying to do is create a 'deep shrink / zoom out' on a picture in PPT 2003. So, I have this very, very big picture (1 x 1 m for instance) and want to make it to shrink / zoom out. The slide / screen size is about 25 x 19 cm, so, a shrink to 25% at should be possible. Picture placed on the slide '100%' so, 1 x 1 meter and then put into slide show with emphasis 'shrink' to 25 % and than, blank appears on all sides..??..no picture is 'generated' any more? So, is it possible some how to make this 'deep shrink' animation? or, what ...

Big picture questions
I am not accustomed to creating xml files programmatically. The big picture is this: This will be in VB/VS 2005/ winforms. I have a DTD, a sample XML, and an outside data source I will use to populate the XML. In general I think I know how to create elements and attributes and I'm sure I can hack something together but I'm wondering if I'm missing (or forgetting) a better way (other than a long line of hard-coded CreateElement commands). Suggestions please. ----- A related problem: the XML header, for lack of a better term. If we assume creation of an XmlDocument obje...