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

Answer 1

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 2

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

Answer 3

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 4

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.

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.