Michael,
The <implements type="ASP" /> TAG is indeed meaningless and is a remnant
from the a previous incarnation of the component.
This component is to be created from wsh not ASP.
I have got around this now by registering the component on the local machine
(although I'm not happy about it though!)
I would also like to twist this debate a bit further if I may (I have an
oustanding question about the above in another thread with you!)
In the WSC on the remote server I have the following bit of code:
Set WshShell = CreateObject("WScript.Shell")
Set WshSysEnv = WshShell.Environment("PROCESS")
load = WshSysEnv("COMPUTERNAME")
Now, if I run the script from the server, load = the server name,; fair
enough.
But, If I run the component remotely from a client I get the client computer
name returned back. Why is this? Am I misunderstanding DCOM here? Is DCOM
momentarily pulling the component across to the client for execution - hence
load = local computer? Or is the WScript.Shell call returning an instance to
the scrobj.dll on the local machine?
joel
Quote:
> Even assuming that you get the DCOMCNFG stuff straight on the server (or
use MTS on the remote box),
Quote:
> the WSC would still at least need to be registered in the client machine.
And if it were and you
Quote:
> did actually create an instance from the client side, the WSC will NOT be
running in an IIS/ASP
Quote:
> process on the server side, so the <implements type="ASP" /> would be
meaningless.
> But depending on what you ultimately want to accomplish with this, some or
all of the above may be
Quote:
> immaterial.
> In other words, "what's the problem you are trying to solve?"...
> --
> Michael Harris
> Microsoft.MVP.Scripting
> --
Quote:
> > Hi,
> > what do I need to do to use the SERVER parameter of the createObject
> > function?
> > I am hitting an error which I believe is something to do with DCOM
> > permissions.
> > Here is the server scripting proggy
> > <?xml version="1.0"?>
> > <component>
> > <registration
> > description="DCOMtest"
> > progid="DCOMtest.WSC"
> > version="1.00"
> > classid="{0e8dfc80-8f11-11d4-8de9-00508b8b1a1e}"
> > remotable="true"
> > </registration>
> > <public>
> > <property name="magic_number">
> > <get/>
> > </property>
> > <method name="load">
> > </method>
> > </public>
> > <implements type="ASP" id="ASP"/>
> > <script language="VBScript">
> > <![CDATA[
> > dim magic_number
> > magic_number = 2699
> > function get_magic_number()
> > get_magic_number = magic_number
> > end function
> > function load()
> > load = "Temporary Value"
> > end function
> > ]]>
> > </script>
> > </component>
> > Please note the 'remotable' property which I believe is important for
> > this.
> > Now here is the server proggy which correcly invokes the above code.
> > Proving that the code is ok
> > set myObj = CreateObject("DCOMtest.wsc")
> > msgbox myObj.magic_number
> > set myObj = nothing
> > Here is my code on the client machine:
> > option explicit
> > Dim myObj
> > set myObj = CreateObject("DCOMtest.wsc", "//blackbird/d$")
> > msgbox myObj.magic_number
> > 'msgbox 2
> > set myObj = nothing
> > I get a Windows Script Host error:
> > ActiveX component can't create obeject: 'DCOMtest.wsc'
> > Code: 800A01AD
> > any ideas?
> > My gut feeling is that this is permissions. VBscript doc says that the
> > server parameter only works "when Internet security is turned off".
> > Does this mean IE? I would have thought I was running outside of IEs
> > security blanket?
> > Also, what are the valid ways to specify the servername?
> > Why specify "\\server\sharename"? Surely you should just specify the
> > servername? (e.g. "\\JUNO\")
> > There is also another bell ringing regarding DCOM where the remote
> > server com component needs to be registered on the client machine. But
> > if this is the case, why use a server property in createobject?
> > any thoughts gratefully received
> > joel hughes
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
simple .wsc DCOM problem