Vista - Re: Alternative to PowerShell...

On May 15, 4:05*pm, mr_unreliable <kindlyReplyToNewsgr...@xxxxxx>
wrote: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

> Actually, it's pretty much scripting in the same sense as WSH scripts -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@xxxxxxThere 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. : |