Re: DCOM

It does help, thanks.

In essense, the only reason I would be dropping the DLL in a COM+ app is
for the 'ease of remoting' and I am wondering if this makes good sense.
 I may also be questioned by the other developer...like 'why is my DLL ru=
nning
in a COM+ application now?'  I assume future calls from the ASP page woul=
d
be 'serviced' by the COM+ application too just like calls from my EXEs?





>-- Original Message --
>Date:         Fri, 25 Oct 2002 21:06:18 +0100
>Reply-To:     Technical discussion of VBCOM <[email protected]>
>From:         Paul Kirby <[email protected]>
>Subject: Re: [VBCOM] DCOM
>To:           [email protected]
>
>
>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.



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.