Re: DCOM

Greg,

My initial guess is that you should not mess up his processing as long
as he is making all of his component calls on the default interface of
the component in question. I reckon you could create a com+ app, drop
the component into the com+ app. You may need to restart IIS (from the
cmd prompt use "iisreset") just to ensure that it has released the DLL.

If you want to perform remote connections the above is the simplest
approach.

..hope this helps..

Regards

PAK


-----Original Message-----
From: Technical discussion of VBCOM [mailto:[email protected]]
On Behalf Of Greg Robinson
Sent: 25 October 2002 12:47
To: [email protected]
Subject: Re: [VBCOM] DCOM

PAK, this is what I typically do (COM+ then export the Proxy).  The case
here involves another developer who installed the DLL on the server and
is using it from ASP without COM+.  I now need to use the same DLL
remotely
and I do not want to 'disturb' his processing.

I am looking for alternatives as it may be a hard sell to the business
owner
of the server to use COM+ simply for this reason (not for transactions
or
other COM+ services).


>-- Original Message --
>Date:         Thu, 24 Oct 2002 21:28:33 +0100
>Reply-To:     Technical discussion of VBCOM <[email protected]>
>From:         Paul Kirby <[email protected]>
>Subject: Re: [VBCOM] DCOM
>To:           [email protected]
>
>
>Greg,
>
>Can I suggest a way forward? Try placing the DLL in it's own COM+
>application [and then export the proxy]. If this fails then we will
need
>to work on other solutions.
>
>ASP does not care if the component is running within the same process
or
>not [it is resolved @ creation time by SCM], it may however depend on
>what the component is doing. Generally this is the way that I've always
>implemented DLL's called form ASP pages [separate com+ application].
>
>Hth
>
>Regards
>
>PAK
>
>
>-----Original Message-----
>From: Technical discussion of VBCOM [mailto:[email protected]]
>On Behalf Of Greg Robinson
>Sent: 24 October 2002 13:02
>To: [email protected]
>Subject: [VBCOM] DCOM
>
>I am using a 3rd party DLL on a web server.  This DLL is instantiated
>with
>late binding via Server.CreateObject.
>
>I also want to use this 3rd party DLL from client workstations using
>DCOM.
> On the web server, the IIS site is set to medium pooling, so, it is my
>understanding the 3rd party DLL runs under DLLHOST.EXE.
>
>If I want to now remote to this DLL, I will need to export a client
>proxy.
> I can do this easily by placing the DLL in a COM+ package.  However,
>what
>if i cannot, for whatever reason, place the DLL in a COM+ package?  How
>do I remote to this  DLL without COM+?  Or, how do I create the
>surrogate
>process for that DLL to run in and how do I create a client proxy I can
>install on my client workstations?
>
>And finally, if I do create a COM+ application and add the 3rd party
DLL
>to and Export a proxy from with the wizard, will this effect how my ASP
>client uses the DLL?
>
>
>
>
>Greg Robinson
>Director of Training and .NET Technologies
>Scribble Software and Training
>www.scribblesoftware.com
>www.scribbletraining.com
>
>You can read messages from the VBCOM archive, unsubscribe from VBCOM,
or
>subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
>You can read messages from the VBCOM archive, unsubscribe from VBCOM,
or
>subscribe to other DevelopMentor lists at http://discuss.develop.com.



Greg Robinson
Director of Training and .NET Technologies
Scribble Software and Training
www.scribblesoftware.com
www.scribbletraining.com

You can read messages from the VBCOM archive, unsubscribe from VBCOM, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

You can read messages from the VBCOM archive, unsubscribe from VBCOM, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.