Hi,

Is it possible to access intrinsic WScript object properties from a .NET
class? I am writing a COM object in .NET (VB.NET or C#), which can be
invoked from a WSH script (VBS, JS, etc). In the COM object logic, I have to
detect such properties as Interactive, ScriptFullName, and others. I can get
some of these properties through the .NET Framework equivalents, but some
properties are only available from WScript object. I thought that I could
get them through the IHost interface of the WScript.exe (I added it as a
reference), but I cannot figure out how to instantiate the IHost object. I
tried to create as:

IHost.IHost iHost = new IHost.IHost_ClassClass();

but got the error:

"COM object with CLSID {60254CA2-953B-11CF-8C96-00AA00B8708C} is either not
valid or not registered."

Any ideas? Thanks,

Alek

P.S. Sorry for cross-posting. I tried the Interop group but did not get any
responses.

No, WScript is available only when script runs with wscript.exe or
cscript.exe. You can not know in COM/.Net object how program was started -
it could be script, .Net or C++ program, ASP or ASP.Net page or anything
else.

You can not create instance of WScript object, it is created automatically
in wscript.exe or cscript.exe.

You could pass this values (or even WScript object itself) from script
itself to your object (create property in .Net object and assign WScript
object to this property in script). But be ready that some script (or other
caller) will not pass these values into your object.

//------------------------------------------
Regards,
Vassiliev V. V.
http://www.managed-vcl.com - using .Net objects in Delphi for Win32 +
ADO.Net
http://www.oledbdirect.com - The fastest way to access MS SQL Server,
MS Jet (Access) and Interbase (through OLEDB)

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ ×
ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:(E-Mail Removed)...
> Hi,
>
> Is it possible to access intrinsic WScript object properties from a .NET
> class? I am writing a COM object in .NET (VB.NET or C#), which can be
> invoked from a WSH script (VBS, JS, etc). In the COM object logic, I have
to
> detect such properties as Interactive, ScriptFullName, and others. I can
get
> some of these properties through the .NET Framework equivalents, but some
> properties are only available from WScript object. I thought that I could
> get them through the IHost interface of the WScript.exe (I added it as a
> reference), but I cannot figure out how to instantiate the IHost object. I
> tried to create as:
>
> IHost.IHost iHost = new IHost.IHost_ClassClass();
>
> but got the error:
>
> "COM object with CLSID {60254CA2-953B-11CF-8C96-00AA00B8708C} is either
not
> valid or not registered."
>
> Any ideas? Thanks,
>
> Alek
>
> P.S. Sorry for cross-posting. I tried the Interop group but did not get
any
> responses.
>
>

Thanks Slava,

Passing WScript object is a good suggestion; I am gonna think about it. I
understand your point, but I am not sure why this limitation (not being able
to instantiate WScript object) was imposed. I wish there were a way to get
it directly similar to retrieving ASP context object info. If the object is
called from the process other than WSH, it would fail (the behavior would be
the same as if you wanted to get Request or Response info from ASP object
invoked from an app other than ASP).

Alek

"Viatcheslav V. Vassiliev" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> No, WScript is available only when script runs with wscript.exe or
> cscript.exe. You can not know in COM/.Net object how program was started -
> it could be script, .Net or C++ program, ASP or ASP.Net page or anything
> else.
>
> You can not create instance of WScript object, it is created automatically
> in wscript.exe or cscript.exe.
>
> You could pass this values (or even WScript object itself) from script
> itself to your object (create property in .Net object and assign WScript
> object to this property in script). But be ready that some script (or
other
> caller) will not pass these values into your object.
>
> //------------------------------------------
> Regards,
> Vassiliev V. V.
> http://www.managed-vcl.com - using .Net objects in Delphi for Win32 +
> ADO.Net
> http://www.oledbdirect.com - The fastest way to access MS SQL Server,
> MS Jet (Access) and Interbase (through OLEDB)
>
> "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ ×
> ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:(E-Mail Removed)...
> > Hi,
> >
> > Is it possible to access intrinsic WScript object properties from a .NET
> > class? I am writing a COM object in .NET (VB.NET or C#), which can be
> > invoked from a WSH script (VBS, JS, etc). In the COM object logic, I
have
> to
> > detect such properties as Interactive, ScriptFullName, and others. I can
> get
> > some of these properties through the .NET Framework equivalents, but
some
> > properties are only available from WScript object. I thought that I
could
> > get them through the IHost interface of the WScript.exe (I added it as a
> > reference), but I cannot figure out how to instantiate the IHost object.
I
> > tried to create as:
> >
> > IHost.IHost iHost = new IHost.IHost_ClassClass();
> >
> > but got the error:
> >
> > "COM object with CLSID {60254CA2-953B-11CF-8C96-00AA00B8708C} is either
> not
> > valid or not registered."
> >
> > Any ideas? Thanks,
> >
> > Alek
> >
> > P.S. Sorry for cross-posting. I tried the Interop group but did not get
> any
> > responses.
> >
> >
>
>

> ... but I am not sure why this limitation
> (not being able to instantiate WScript object) was imposed. ...

Because as an intrinsic host created object, WScript exposes functionality
of the host executing the script. It is not externally creatable since it
has no meaning in any other context. Certainly a new WScript instance
created inside a COM wrapped .NET component would have no relationship to
the client creating an instance your component, which might not even be a
WSH hosted script.

--
Michael Harris
Microsoft.MVP.Scripting
Sammamish WA US

Yes, but following the same analogy, you can also say that intrinsic ASP
objects (Request, Response, Session, etc) should not be
creatable/retrievable from another COM object written in C++/VB, since this
COM object can be invoked from any program, not just ASPs. However,
intrinsic ASP objects can be retrieved from C++/VB using context objects.
What I am saying is that it would be nice if a similar approach were
available for retrieving intrinsic WScript objects, because there are
situations (like mine) when it is needed. If a program which is not invoked
in the context of WSH tries to get intrinsic WScript object an error should
be generated, but if it is invoked from a WSH hosted script, there is no
reason why the objects cannot be "creatable".

Alek

"Michael Harris (MVP)" <mikhar at mvps dot org> wrote in message
news:(E-Mail Removed)...
> > ... but I am not sure why this limitation
> > (not being able to instantiate WScript object) was imposed. ...
>
> Because as an intrinsic host created object, WScript exposes functionality
> of the host executing the script. It is not externally creatable since it
> has no meaning in any other context. Certainly a new WScript instance
> created inside a COM wrapped .NET component would have no relationship to
> the client creating an instance your component, which might not even be a
> WSH hosted script.
>
> --
> Michael Harris
> Microsoft.MVP.Scripting
> Sammamish WA US
>

ASP runs in COM+ environment that has context. COM(-) has no way to setup
context - you are right, this would be nice to be able to have application
context object, not only for scripts. But COM(-) is designed so that
components should be completely independant on caller.

WSH is designed to run on Win9x and does not use COM+.

//------------------------------------
Regards,
Vassiliev V. V.
http://www-sharp.com -
Scripting/HTA/.Net Framework IDE

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ ×
ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:(E-Mail Removed)...
> Yes, but following the same analogy, you can also say that intrinsic ASP
> objects (Request, Response, Session, etc) should not be
> creatable/retrievable from another COM object written in C++/VB, since
this
> COM object can be invoked from any program, not just ASPs. However,
> intrinsic ASP objects can be retrieved from C++/VB using context objects.
> What I am saying is that it would be nice if a similar approach were
> available for retrieving intrinsic WScript objects, because there are
> situations (like mine) when it is needed. If a program which is not
invoked
> in the context of WSH tries to get intrinsic WScript object an error
should
> be generated, but if it is invoked from a WSH hosted script, there is no
> reason why the objects cannot be "creatable".
>
> Alek
>
> "Michael Harris (MVP)" <mikhar at mvps dot org> wrote in message
> news:(E-Mail Removed)...
> > > ... but I am not sure why this limitation
> > > (not being able to instantiate WScript object) was imposed. ...
> >
> > Because as an intrinsic host created object, WScript exposes
functionality
> > of the host executing the script. It is not externally creatable since
it
> > has no meaning in any other context. Certainly a new WScript instance
> > created inside a COM wrapped .NET component would have no relationship
to
> > the client creating an instance your component, which might not even be
a
> > WSH hosted script.
> >
> > --
> > Michael Harris
> > Microsoft.MVP.Scripting
> > Sammamish WA US
> >
>
>

OK, I see. Thanks for the info.

Alek

"Viatcheslav V. Vassiliev" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> ASP runs in COM+ environment that has context. COM(-) has no way to setup
> context - you are right, this would be nice to be able to have application
> context object, not only for scripts. But COM(-) is designed so that
> components should be completely independant on caller.
>
> WSH is designed to run on Win9x and does not use COM+.
>
> //------------------------------------
> Regards,
> Vassiliev V. V.
> http://www-sharp.com -
> Scripting/HTA/.Net Framework IDE
>
> "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ ×
> ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:(E-Mail Removed)...
> > Yes, but following the same analogy, you can also say that intrinsic ASP
> > objects (Request, Response, Session, etc) should not be
> > creatable/retrievable from another COM object written in C++/VB, since
> this
> > COM object can be invoked from any program, not just ASPs. However,
> > intrinsic ASP objects can be retrieved from C++/VB using context
objects.
> > What I am saying is that it would be nice if a similar approach were
> > available for retrieving intrinsic WScript objects, because there are
> > situations (like mine) when it is needed. If a program which is not
> invoked
> > in the context of WSH tries to get intrinsic WScript object an error
> should
> > be generated, but if it is invoked from a WSH hosted script, there is no
> > reason why the objects cannot be "creatable".
> >
> > Alek
> >
> > "Michael Harris (MVP)" <mikhar at mvps dot org> wrote in message
> > news:(E-Mail Removed)...
> > > > ... but I am not sure why this limitation
> > > > (not being able to instantiate WScript object) was imposed. ...
> > >
> > > Because as an intrinsic host created object, WScript exposes
> functionality
> > > of the host executing the script. It is not externally creatable since
> it
> > > has no meaning in any other context. Certainly a new WScript instance
> > > created inside a COM wrapped .NET component would have no relationship
> to
> > > the client creating an instance your component, which might not even
be
> a
> > > WSH hosted script.
> > >
> > > --
> > > Michael Harris
> > > Microsoft.MVP.Scripting
> > > Sammamish WA US
> > >
> >
> >
>
>