ASP.Net - the "Big Picture"?

Discussion in 'ASP .Net' started by Metre Meter, Jan 7, 2010.

  1. Metre Meter

    Metre Meter Guest

    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
     
    Metre Meter, Jan 7, 2010
    #1
    1. Advertising

  2. Metre Meter

    Scott M. Guest

    "Metre Meter" <> wrote in message
    news:...
    > 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
     
    Scott M., Jan 7, 2010
    #2
    1. Advertising

  3. Metre Meter

    Patrice Guest

    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
     
    Patrice, Jan 8, 2010
    #3
  4. Metre Meter

    Scott M. Guest

    "Patrice" <http://scribe-en.blogspot.com/> wrote in message
    news:eYtdT$...
    > 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
     
    Scott M., Jan 8, 2010
    #4
  5. Metre Meter

    Patrice Guest

    > 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
     
    Patrice, Jan 8, 2010
    #5
  6. Metre Meter <> wrote in news:9a7d595a-374f-4af0-
    :

    > - 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! |
    *******************************************
     
    Gregory A. Beamer, Jan 8, 2010
    #6
  7. Metre Meter

    Metre Meter Guest

    On Jan 7, 10:15 pm, "Scott M." <> wrote:
    > "Metre Meter" <> 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".  There 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 for
    > 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.  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.

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

    Thanks for the info!

    - MM
     
    Metre Meter, Jan 8, 2010
    #7
  8. Metre Meter

    Metre Meter Guest

    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. (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, Jan 8, 2010
    #8
  9. Metre Meter

    Metre Meter Guest

    On Jan 8, 4:49 pm, "Gregory A. Beamer"
    <> 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='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
     
    Metre Meter, Jan 8, 2010
    #9
  10. Metre Meter

    Scott M. Guest

    "Metre Meter" <> wrote in message
    news:...
    On Jan 7, 10:15 pm, "Scott M." <> wrote:
    > "Metre Meter" <> 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
     
    Scott M., Jan 8, 2010
    #10
  11. Metre Meter

    Scott M. Guest

    "Metre Meter" <> wrote in message
    news:...
    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
     
    Scott M., Jan 8, 2010
    #11
  12. Metre Meter

    Scott M. Guest

    "Metre Meter" <> wrote in message
    news:...
    On Jan 8, 4:49 pm, "Gregory A. Beamer"
    <> 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
     
    Scott M., Jan 8, 2010
    #12
  13. Metre Meter

    Metre Meter Guest

    On Jan 8, 10:09 pm, "Scott M." <> wrote:
    > "Metre Meter" <> wrote in message
    >
    > news:...
    > On Jan 8, 4:49 pm, "Gregory A. Beamer"
    >
    > <> 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(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, Jan 8, 2010
    #13
  14. Metre Meter

    Metre Meter Guest

    On Jan 8, 10:03 pm, "Scott M." <> 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
     
    Metre Meter, Jan 8, 2010
    #14
  15. Metre Meter

    Scott M. Guest

    "Metre Meter" <> wrote in message
    news:...
    On Jan 8, 10:09 pm, "Scott M." <> wrote:
    > "Metre Meter" <> wrote in message
    >
    > news:...
    > On Jan 8, 4:49 pm, "Gregory A. Beamer"
    >
    > <> 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(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
     
    Scott M., Jan 9, 2010
    #15
  16. Metre Meter

    Patrice Guest

    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
     
    Patrice, Jan 9, 2010
    #16
  17. Metre Meter

    Metre Meter Guest

    On Jan 9, 10:37 am, "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
     
    Metre Meter, Jan 9, 2010
    #17
  18. Metre Meter

    Metre Meter Guest

    On Jan 9, 12:04 am, "Scott M." <> wrote:
    > 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, Jan 9, 2010
    #18
  19. Metre Meter

    Metre Meter Guest

    On Jan 9, 9:43 pm, Metre Meter <> 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
     
    Metre Meter, Jan 9, 2010
    #19
  20. Metre Meter

    Patrice Guest

    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
     
    Patrice, Jan 9, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jm
    Replies:
    4
    Views:
    577
    GIMME
    Jan 6, 2004
  2. Kayser

    Big Picture

    Kayser, Aug 7, 2006, in forum: Java
    Replies:
    4
    Views:
    376
  3. Jonathan Wood

    Big-Picture Question (Web Services, RegNow)

    Jonathan Wood, Nov 17, 2006, in forum: ASP .Net
    Replies:
    23
    Views:
    741
    Jonathan Wood
    Nov 25, 2006
  4. B. Chernick
    Replies:
    0
    Views:
    253
    B. Chernick
    Jan 14, 2008
  5. Metre Meter

    Classic ASP and ASP.Net - The "Big" Picture?

    Metre Meter, Jan 6, 2010, in forum: ASP General
    Replies:
    11
    Views:
    1,763
    Bob Barrows
    Jan 8, 2010
Loading...

Share This Page