On May 15, 4:05*pm, mr_unreliable <kindlyReplyToNewsgr...@xxxxxx>
wrote:

> Blue Streak wrote:

> > * * I have been working on updating a .NET script engine originally
> > written by Rama K. Vavilala called "NScript" originally posted on
> > CodeProject. *I have recently re-compiled this program for the
> > Microsoft .NET Framework 2.0. *With permission from the original
> > author I have re-packaged the program and have called it Windows
> > Script Host .NET (WSH.NET). It is available as an open-source project
> > at Google Code from the following link:

>
> hi Blue Streak,
>
> While I am inclined to applaud any new scripting language, and
> especially one that supports a better user interface than wsh/vbs
> does, (assuming that you have left the windows forms capability
> of vb.net intact), I am baffled about nscript.
>
> I appears to be nothing more than a glorified batch file, that
> allows you to compile vb.net (and jscript, and c-sharp). *The
> notion of a scripting language as something that is quick,
> easy (and dirty) seems to have been left out. *Am I missing
> something???
>
> And if it is only a glorified batch file, then what's wrong with
> just using a (real) batch file (as I have previously done, and
> which appears to work just fine)?
>
> cheers, jw

I saw your post but it took a few days for the message to show.

Is this a glorified batch file? Yes and no.

I'm sure you will admit that straight MS-DOS batch files, although
useful, do have their limitations within a Windows environment. In
steps in Microsoft with Windows Script(ing) Host. WSH picks up where
batch files left off. However, I have found (and the others I have
conversed with) that VBScript (and JScript) leave something to be
desired from a programming standpoint.

I was in a couple of situations where WSH/VBScript saved my arse
at a bad job I had ... but I digress. You can use WSH to access text
files, the system registry, SQL databases, and whatever else you dream
up so long as you have created an ActiveX / COM interface. However,
you couldn't do fancy things programmatically (e.g. define a nested
class within a class). With .NET you can do this plus a lot more.

Power Shell offers the same functionality but I didn't care very
much for the interface. Using C# and VB.NET may not seem very much
like a script where you have to include a Main() function but from
a .NET standpoint this is quick and dirty. If you like you can take
at CSharpScript by Edward Poore at CodeProject. This runs C# code
without the requirement for a Main() function (actually he has one
inserted dynamically just before compilation). There are many
more .NET script engines at CodeProject.

However, if you use JScript.NET you will know that it doesn't
require a Main() function at all. Using NScript (or WSH.NET) will
allow this to run as a script!

Yes, you do take a hit when you first start the script because it
still has to compile it within memory but, then again, ASP.NET does
exactly the same thing. The next time you run it the script is a lot
faster.

The point I'm trying to make is that it's matter of preference.
This script engine allows you to compile .NET code without having to
download and install the SDK. I just happen to think that's neat. If
you don't like it then don't use it.

B.S.

P.S. I am not aware if Rama K. Vavilala removed any of the
functionality of .NET. I didn't get that impression going over his
code. He just had the script engine split into two parts: 1) Windows
interface and 2) Console.

>
The point I'm trying to make is that it's matter of preference.
This script engine allows you to compile .NET code without having to
download and install the SDK. I just happen to think that's neat. If
you don't like it then don't use it.

>

I have a similar reaction to that of mr_unreliable.
It sounds interesting that you can write .Net code
and compile it from text in small pieces (assuming one
has a reason to use .Net in the first place) but I
don't see what that has to do with scripting.

Actually, it's pretty much scripting in the same sense as WSH scripts -
after all, they're dynamically compiled much as this is. I like it, but then
again, I always like shiny, new, free toys, even if they're slightly
non-topical. : D

"mayayana" <mayaXXyana1a@xxxxxx> wrote in message
news:OfR5W0uuIHA.4528@xxxxxx

>>

> The point I'm trying to make is that it's matter of preference.
> This script engine allows you to compile .NET code without having to
> download and install the SDK. I just happen to think that's neat. If
> you don't like it then don't use it.

>>

>
> I have a similar reaction to that of mr_unreliable.
> It sounds interesting that you can write .Net code
> and compile it from text in small pieces (assuming one
> has a reason to use .Net in the first place) but I
> don't see what that has to do with scripting.
>
>

> Actually, it's pretty much scripting in the same sense as WSH scripts -

> after all, they're dynamically compiled much as this is

I haven't tried the tool, but I don't see the similarity
based on the OP's posts. He seems to be describing
a .Net compiler, which would be like comparing Java
to javascript - a JIT-compiled programming system
with a runtime as opposed to a scripting language with
an interpreter.

I'm always skeptical of these hybrid projects. Something
that requires knowing VB.Net, installing a 70+ MB runtime,
and compiling the code leaves behind the whole point of script
being quick, simple and shielded from the consequences of
serious errors.
It's a bit like the idea of accessing Win32 API functions from
VBS - The people who want to do it probably don't know enough
about the API calls to use them safely. If they did then they
wouldn't be trying to squeeze those APIs through a clunky script
filter when the functions could be called directly from compiled
software.

"mayayana" <mayaXXyana1a@xxxxxx> wrote in message
news:#1JxwmavIHA.3500@xxxxxx

>> Actually, it's pretty much scripting in the same sense as WSH scripts -
>> after all, they're dynamically compiled much as this is

>
> I haven't tried the tool, but I don't see the similarity
> based on the OP's posts. He seems to be describing
> a .Net compiler, which would be like comparing Java
> to javascript - a JIT-compiled programming system
> with a runtime as opposed to a scripting language with
> an interpreter.

There are some big differences, but this isn't actually one of them - in WSH
at least, the scripts are JIT-compiled, parsed, and turned into machine code
before they even start to run. Even when you add code using something like
VBScript's Execute, the added code is JITed before it gets executed - and
whatever language you use, for all intents and purposes Active Scripting
languages in practice share a common runtime in the classic COM objects
deployed with it, the WScript object, and the WMI and AD subsystems.

The biggest problem from my perspective with using things like this for
anything production isn't the reliability per se; the core infrastructure
for just-in-time, language-agnostic compilation is part of the vanilla .NET
architecture. However, there _is_ a problem for me in the fact that the
languages don't behave like scripting languages in general; they don't work
as well for ad-hoc use as VBScript/JScript do. : |

> I'm always skeptical of these hybrid projects. Something
> that requires knowing VB.Net, installing a 70+ MB runtime,
> and compiling the code leaves behind the whole point of script
> being quick, simple and shielded from the consequences of
> serious errors.
> It's a bit like the idea of accessing Win32 API functions from
> VBS - The people who want to do it probably don't know enough
> about the API calls to use them safely. If they did then they
> wouldn't be trying to squeeze those APIs through a clunky script
> filter when the functions could be called directly from compiled
> software.
>
>