What are people using JScript.Net for?

Question

I'm interested to know who uses JScript.Net and for what sort of applications. Whenever I'm reading MSDN .Net documentation, I always notice the JScript samples but in all the years I've been a C# dev I've never actually known anyone to use it.

What sort of applications are people using this for, and how does it measure, in terms of flexibility, power and general usage, to C#?

[Edit: Just to clarify - I'm not asking what JScript.Net is, I'm asking what people are actually using it for - i.e. interested to know actual usage scenarios and how people have found it to work with]

Answer 1

Rob - I have used JScript.NET in anger in one place in my code, which is essentially to expose the functionality of its eval method. Here is a cut-down version:

static public class Evaluator
{
    private const string _jscriptSource =
        @"package Evaluator
        {
           class Evaluator
           {
              public function Eval(expr : String) : String 
              { 
                 return eval(expr); 
              }
           }
        }";

    static private object _evaluator;
    static private Type _evaluatorType;

    static Evaluator()
    {
        InstantiateInternalEvaluator();
    }

    static private void InstantiateInternalEvaluator()
    {
        JScriptCodeProvider compiler = new JScriptCodeProvider();

        CompilerParameters parameters;
        parameters = new CompilerParameters();
        parameters.GenerateInMemory = true;

        CompilerResults results;
        results = compiler.CompileAssemblyFromSource(parameters, _jscriptSource);

        Assembly assembly = results.CompiledAssembly;
        _evaluatorType = assembly.GetType("Evaluator.Evaluator");

        _evaluator = Activator.CreateInstance(_evaluatorType);
    }

    static public object EvaluateToObject(string statement)
    {
        try
        {
            return _evaluatorType.InvokeMember(
                "Eval",
                BindingFlags.InvokeMethod,
                null,
                _evaluator,
                new object[] {statement}
                );
        }
        catch (Exception)
        {
            InstantiateInternalEvaluator();
            return null;
        }
    }

You can obviously create overloads for other return types. I can't claim the original idea for this was mine! Uses for this would be, for example, to evaluate a string expression like 3 + 4 to 7 without expression parsing.

Answer 2

The JScript.NET Wikipedia page is pretty explanatory: http://en.wikipedia.org/wiki/JScript_.NET

In short, it seems to be JavaScript with the .NET library.

Answer 3

JScript .NET is a modern scripting language with a wide variety of applications. It is a true object-oriented language, and yet it still keeps its "scripting" feel. JScript .NET maintains full backwards compatibility with previous versions of JScript, while incorporating great new features and providing access to the common language runtime and .NET Framework (from JScript.NET).

Besides, you might find this stackoverflow post helpful as well: Can JScript.NET be used to script a .NET application?

As for who is using, I am honestly not aware of (I am pretty sure there are out there).

Read Introducing JScript.NET.

My personal thought was that it could be awsome for web developers who're used to write in plain JScript and want to get the benefits of .NET without need to learn a new language, or for those who want to have all their code written in one language.

Answer 4

I'd just assumed it was used by Microsoft to inflate the number of languages .NET supported at launch for marketing purposes.

Answer 5

I use it quite a lot, almost exclusively, for ASP.NET and related web-stuff.

You can use it for pretty much all the stuff you can use the other .NET languages for. It makes MSIL, just like the others ;) Compiled with the "fast" option which turns of some of the native javascript traits, like prototype extensions and eval, it performs just like any other code on the CLR.

It's certainly not a full-fledged member of the family, in the sense that it seems somewhat left behind in .NET 1.1 in terms of features, the tool support is non-existant, and the documentation is downright appaling. That's part of why I like it so much, actually, makes me feel like I'm programming.

If you have a lot of (j)scripts lying around that needs to be converted to .NET, this is the obvious choice as you will usually need very little rewriting for that to work. Otherwise there's no particular reason for choosing JScript.NET over any other .NET language, and many reasons not to.

It all comes down to personal preferences since it all ends up as the same CLR code, regardless of language. I find JScript.NET easy-going, natural to write and with a flexible simplicity like no other language I tried, so I use that until I encounter a problem that the language just can't handle. Hasn't happened yet.

Answer 6

I recommend to everybody not to use it or only in homeopathic doses. Unfortunately I have to work with it a lot for legacy reasons, and as was stated before it was developed for .NET 1.1 and was not upgraded since, has no support for generics, no support for delegates, cannot declare events etc. It was never very widespread and is currently not developed anymore (although sometimes Microsoft still fixes a bug I submit). But that's the minor issue: There are major problems in the compiler, valid code may crash it easily and then all you have is an exception thrown somewhere in the depth of jsc.exe with no hint which file is causing the crash let alone which line of code. Here's an example of what happens (I was casting a strongly typed array into an ICollection):

***INTERNAL COMPILER ERROR***
Microsoft.Vsa.VsaException: InternalCompilerError (0x80133021): System.NotSupportedException: Not supported in a non-reflected type.
   at System.Reflection.Emit.SymbolType.GetMember(String name, MemberTypes type, BindingFlags bindingAttr)
   at System.Type.GetMember(String name, BindingFlags bindingAttr)
   at Microsoft.JScript.Convert.GetToXXXXMethod(IReflect ir, Type desiredType, Boolean explicitOK)
   at Microsoft.JScript.Convert.EmittedCallToConversionMethod(AST ast, ILGenerator il, Type source_type, Type target_type)
   at Microsoft.JScript.Convert.Emit(AST ast, ILGenerator il, Type source_type, Type target_type, Boolean truncationPermitted)
   at Microsoft.JScript.Binding.TranslateToILCall(ILGenerator il, Type rtype, ASTList argList, Boolean construct, Boolean brackets)
   at Microsoft.JScript.Lookup.TranslateToILCall(ILGenerator il, Type rtype, ASTList argList, Boolean construct, Boolean brackets)
   at Microsoft.JScript.Call.TranslateToIL(ILGenerator il, Type rtype)
   at Microsoft.JScript.Binding.TranslateToILSet(ILGenerator il, AST rhvalue)
   at Microsoft.JScript.Lookup.TranslateToILSet(ILGenerator il, Boolean doBoth, AST rhvalue)
   at Microsoft.JScript.VariableDeclaration.TranslateToIL(ILGenerator il, Type rtype)
   at Microsoft.JScript.Block.TranslateToIL(ILGenerator il, Type rtype)
   at Microsoft.JScript.FunctionObject.TranslateToIL(CompilerGlobals compilerGlobals)
   at Microsoft.JScript.FunctionDeclaration.TranslateToILInitializer(ILGenerator il)
   at Microsoft.JScript.Block.TranslateToILInstanceInitializers(ILGenerator il)
   at Microsoft.JScript.Class.TranslateToCOMPlusClass()
   at Microsoft.JScript.Class.TranslateToIL(ILGenerator il, Type rtype)
   at Microsoft.JScript.Package.TranslateToIL(ILGenerator il, Type rtype)
   at Microsoft.JScript.Block.TranslateToIL(ILGenerator il, Type rtype)
   at Microsoft.JScript.ScriptBlock.TranslateToIL(ILGenerator il, Type rtype)
   at Microsoft.JScript.ScriptBlock.TranslateToILClass(CompilerGlobals compilerGlobals, Boolean pushScope)
   at Microsoft.JScript.VsaStaticCode.TranslateToIL()
   at Microsoft.JScript.Vsa.VsaEngine.DoCompile()
   at Microsoft.Vsa.BaseVsaEngine.Compile()

Good luck if you have to find the problem with such a message.

JScript.NET has some features that could be interesting for some projects, like prototyping (adding new properties and I think also methods to an existing instance of any object), has kind of Lamda-Functions already since .NET 1.1 (maybe 1.0) etc. But to reach this totally different behavior from what was possible with .NET 1.1 they had to wrap everything in runtime-helpers, JScript.NET has an own String class, that is converted into System.String to and fro whenever needed. Same with arrays, JScript has its own implementation and has to convert them whenever a framework function is called with an array as parameter etc.

I experienced such funny things like that a request to the database was executed twice if I passed it directly as a parameter to a method (DoSomething(myRequest.Execute()), the result of the request was of type System.String[][]) but the whole thing is working fine if I assign the result first to a variable and then pass it to the method, or if you try to sort an array with System.Array.Sort(..) it is simply ignored and so on.

I have the feeling JScript.NET was a case study to proof that it's also possible to implement languages with a very different philosophy, and the Microsoft gave it up as they realized its approach was not well chosen, but they learned the lesson and did an excellent job with PowerShell which has a somewhat similar philosophy.

But to cut a long story short: Don't use JScript.NET if you don't have to, use a modern language like C# or VB.NET instead, and if you need scripting functionality, I recommend using CSScript.

Answer 7

Well, I'm trying to use it. I can't say I've been successful.

I've not done a lot of web coding in any environment, but here is my 2 cents.

I wanted to expose some database tables to a web page, so I threw together a quick Classic ASP (yeah, yeah, I know) page that pulled the data from SQL Server and returned the table as a JSON object. Rather than locate a JSON serializer for VBScript I just wrote both sides in J(ava)script and imported json2.js on the server to provide serialization. It worked great; honestly it took less than an hour to have it spit back a nice JSON representation of the table, 50 minutes of which was a fruitless attempt to get JScript to import json2.min.js directly rather than throwing <% %> wrappers around it and renaming it json2.min.asp.

But everyone says it is sick and wrong to use Classic ASP in this day and age, so I'm trying to replace my quick & dirty ASP + Jscript + ADO implementation with ASP.NET + Jscript.NET + ADO.NET. After some head-pounding-keyboard moments I have ASP.NET v4.0.30319 up on IIS6 and have a "hello, world" page that does some simple loops javascript via the <@ language = "JScript"> directive. So far so good.

I were following Best Practices here I'd be wrapping everything in a class etc, but as I'm just try to get out of the driveway I tried doing a quick port of my existing code, which imports various useful bits of Javascript from other files using ASP include statements.

Including some simple stuff using <--#incude file="somejsconstants.asp" --> worked fine and let me access constants from that file. But my attempt to pull in the JSON serializer with<--#incude file="json2.min.asp" --> didn't work, and firing up a version of json2.js suitably modified to be a standalone aspx page and threw the same error. (The compiler error is Objects of type 'jscript_aspx' do not have such a member.) JScript.NET seems to be unhappy with the use of closures, a near-omnipresent construction in today's javascript libraries.

From postings above it's clear there are plenty of ways to serialize JSON objects in the .NET platform, but my gut feeling is that if JScript.NET barfs on Javascript written by Douglas Crockford, then it is a quirky, incompatible rathole not worth investing my time in. I might as well follow the ASP.NET masses and use C#.

Answer 8

As an enhancement for batch files and for console applications as it allows a neat hybridization (without unnecessary output) thanks to its directives.Save the following example with .bat extension and check its result:

@if (@X)==(@Y) @end /* JScript comment
@echo off
setlocal

for /f "tokens=* delims=" %%v in ('dir /b /s /a:-d  /o:-n "%SystemRoot%\Microsoft.NET\Framework\*jsc.exe"') do (
   set "jsc=%%v"
)

if not exist "%~n0.exe" (
    "%jsc%" /nologo /out:"%~n0.exe" "%~dpsfnx0"
)

 %~n0.exe %*

endlocal & exit /b %errorlevel%


*/

import System;

Console.WriteLine("hello from jscript.net");

Here some examples can be found.

Answer 9

With the Business Process Management tool Metastorm BPM you can use JScript.Net to extend your workflows. For example you can add custom .Net .dlls to the engine and interact with them in your processes using JScript.Net.

My experience was quite positive. I've implemented just some small glue scripts but I'd prefer scripting with JScript.Net to VBScript (the second supported Scripting Language) anytime.

Answer 10

I don't know how it compares performance-wise, but I know that JScript.NET is one of the languages you can use with Unity 3D.

Answer 11

JScript .NET is one of the languages supported for writing application extensions for Sony's family of media editing products. Sound Forge & Vegas.

In particular Sound Forge has a window that you can use to edit and run scripts to manipulate audio files.

It turns out the Microsoft made it pretty easy to add scripting to your application using one (or all) of the .NET supported languages. VB, JScript & C#. Just just have to expose some objects from your application and hand those objects (assemblies actually) to the compiler along with the user's script text.

They have a web forum for script writers for Sound Forge

Answer 12

I'm late to the party here, but I want to add my take:

I see JScript.NET being useful for server-side code. It's pretty natural to use something server-side that is essentially the same as what you use client-side. Also, it makes working with JSON that much easier so can be a boon if you're creating a web service that communicates via JSON.

I wrote a web service where I work in C# but am thinking of migrating to JScript.NET because of those reasons.