[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Preventing a RCW from being remoted

(Jeremy)

9/23/2004 5:17:00 PM

I want to pass a COM object reference between two managed processes (A & B)
which are communicating via TCP/IP remoting. So, I instantiate a RCW in
process A, and return it to B during as the return value of a remote method
call. However, what seems to be happening is that B gets a proxy to A's
RCW. What I really want to happen is that B will get direct reference (e.g.
its own in-process RCW) to the COM object. Basically, I want what would
happen if you used CoMarshalInterface/CoUnmarshalInterface and passed the
marshalled bytes. Do I have to resort to actually doing this through
P/Invoke, or is there some more natural way in .NET?

Thanks
Jeremy



5 Answers

(Jeremy)

9/23/2004 5:41:00 PM

0

Perhaps I mischaracterized the problem, since the CLR is supposed to do
exactly the CoMarshal/CoUnMarshalInterface thing in this situation. The
problem is, once I have passed the reference across the remoting boundary, a
call to it results in the old "This remoting proxy has no
channel sink which means either the server has no registered server
channels..."

"Jeremy Lew" <jslew@hotmail.com> wrote in message
news:u$WagEZoEHA.1176@TK2MSFTNGP12.phx.gbl...
> I want to pass a COM object reference between two managed processes (A &
B)
> which are communicating via TCP/IP remoting. So, I instantiate a RCW in
> process A, and return it to B during as the return value of a remote
method
> call. However, what seems to be happening is that B gets a proxy to A's
> RCW. What I really want to happen is that B will get direct reference
(e.g.
> its own in-process RCW) to the COM object. Basically, I want what would
> happen if you used CoMarshalInterface/CoUnmarshalInterface and passed the
> marshalled bytes. Do I have to resort to actually doing this through
> P/Invoke, or is there some more natural way in .NET?
>
> Thanks
> Jeremy
>
>
>


Ken Kolda

9/23/2004 7:22:00 PM

0

Is it the case that you're passing this object from the client to the server
and then invoking the methods on the server? If so, that means that you have
registered the channel incorrectly on the client. When you register it, you
should use

Channel chan = new TcpChannel(0);

The "0" tells .NET to setup a server channel in the client as well so it can
handle callbacks from the server.

Ken


"Jeremy Lew" <jslew@hotmail.com> wrote in message
news:O0gQMSZoEHA.556@tk2msftngp13.phx.gbl...
> Perhaps I mischaracterized the problem, since the CLR is supposed to do
> exactly the CoMarshal/CoUnMarshalInterface thing in this situation. The
> problem is, once I have passed the reference across the remoting boundary,
a
> call to it results in the old "This remoting proxy has no
> channel sink which means either the server has no registered server
> channels..."
>
> "Jeremy Lew" <jslew@hotmail.com> wrote in message
> news:u$WagEZoEHA.1176@TK2MSFTNGP12.phx.gbl...
> > I want to pass a COM object reference between two managed processes (A &
> B)
> > which are communicating via TCP/IP remoting. So, I instantiate a RCW in
> > process A, and return it to B during as the return value of a remote
> method
> > call. However, what seems to be happening is that B gets a proxy to A's
> > RCW. What I really want to happen is that B will get direct reference
> (e.g.
> > its own in-process RCW) to the COM object. Basically, I want what would
> > happen if you used CoMarshalInterface/CoUnmarshalInterface and passed
the
> > marshalled bytes. Do I have to resort to actually doing this through
> > P/Invoke, or is there some more natural way in .NET?
> >
> > Thanks
> > Jeremy
> >
> >
> >
>
>


(Jeremy)

9/23/2004 9:34:00 PM

0

No, the server is creating this object and returning it to the client.

"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:u24x0KaoEHA.692@TK2MSFTNGP12.phx.gbl...
> Is it the case that you're passing this object from the client to the
server
> and then invoking the methods on the server? If so, that means that you
have
> registered the channel incorrectly on the client. When you register it,
you
> should use
>
> Channel chan = new TcpChannel(0);
>
> The "0" tells .NET to setup a server channel in the client as well so it
can
> handle callbacks from the server.
>
> Ken
>
>
> "Jeremy Lew" <jslew@hotmail.com> wrote in message
> news:O0gQMSZoEHA.556@tk2msftngp13.phx.gbl...
> > Perhaps I mischaracterized the problem, since the CLR is supposed to do
> > exactly the CoMarshal/CoUnMarshalInterface thing in this situation. The
> > problem is, once I have passed the reference across the remoting
boundary,
> a
> > call to it results in the old "This remoting proxy has no
> > channel sink which means either the server has no registered server
> > channels..."
> >
> > "Jeremy Lew" <jslew@hotmail.com> wrote in message
> > news:u$WagEZoEHA.1176@TK2MSFTNGP12.phx.gbl...
> > > I want to pass a COM object reference between two managed processes (A
&
> > B)
> > > which are communicating via TCP/IP remoting. So, I instantiate a RCW
in
> > > process A, and return it to B during as the return value of a remote
> > method
> > > call. However, what seems to be happening is that B gets a proxy to
A's
> > > RCW. What I really want to happen is that B will get direct reference
> > (e.g.
> > > its own in-process RCW) to the COM object. Basically, I want what
would
> > > happen if you used CoMarshalInterface/CoUnmarshalInterface and passed
> the
> > > marshalled bytes. Do I have to resort to actually doing this through
> > > P/Invoke, or is there some more natural way in .NET?
> > >
> > > Thanks
> > > Jeremy
> > >
> > >
> > >
> >
> >
>
>


Ken Kolda

9/23/2004 11:31:00 PM

0

Darn. Are you accessing the remote object as a SAO or a CAO? And are you
able to use other remoted objects that aren't RCWs?


"Jeremy Lew" <jslew@hotmail.com> wrote in message
news:%23fqZHUboEHA.1668@TK2MSFTNGP14.phx.gbl...
> No, the server is creating this object and returning it to the client.
>
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
> news:u24x0KaoEHA.692@TK2MSFTNGP12.phx.gbl...
> > Is it the case that you're passing this object from the client to the
> server
> > and then invoking the methods on the server? If so, that means that you
> have
> > registered the channel incorrectly on the client. When you register it,
> you
> > should use
> >
> > Channel chan = new TcpChannel(0);
> >
> > The "0" tells .NET to setup a server channel in the client as well so it
> can
> > handle callbacks from the server.
> >
> > Ken
> >
> >
> > "Jeremy Lew" <jslew@hotmail.com> wrote in message
> > news:O0gQMSZoEHA.556@tk2msftngp13.phx.gbl...
> > > Perhaps I mischaracterized the problem, since the CLR is supposed to
do
> > > exactly the CoMarshal/CoUnMarshalInterface thing in this situation.
The
> > > problem is, once I have passed the reference across the remoting
> boundary,
> > a
> > > call to it results in the old "This remoting proxy has no
> > > channel sink which means either the server has no registered server
> > > channels..."
> > >
> > > "Jeremy Lew" <jslew@hotmail.com> wrote in message
> > > news:u$WagEZoEHA.1176@TK2MSFTNGP12.phx.gbl...
> > > > I want to pass a COM object reference between two managed processes
(A
> &
> > > B)
> > > > which are communicating via TCP/IP remoting. So, I instantiate a
RCW
> in
> > > > process A, and return it to B during as the return value of a remote
> > > method
> > > > call. However, what seems to be happening is that B gets a proxy to
> A's
> > > > RCW. What I really want to happen is that B will get direct
reference
> > > (e.g.
> > > > its own in-process RCW) to the COM object. Basically, I want what
> would
> > > > happen if you used CoMarshalInterface/CoUnmarshalInterface and
passed
> > the
> > > > marshalled bytes. Do I have to resort to actually doing this
through
> > > > P/Invoke, or is there some more natural way in .NET?
> > > >
> > > > Thanks
> > > > Jeremy
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>


yooooooooooooo

10/26/2009 3:28:00 PM

0

On Oct 23, 12:15 am, Tom St Denis <t...@iahu.ca> wrote:
> On Oct 22, 12:06 pm, Keith Thompson <ks...@mib.org> wrote:
>
> > Tom St Denis <t...@iahu.ca> writes:
> > [...]
>
> > > yeah yeah yeah I get it.  It's all academic anyways since essentially
> > > all platforms nowadays don't do that.  All of ARM, PPC, MIPS, and x86
> > > [which makes up the vast majority of 32/64-bit processors] have at
> > > least a 32-bit range for signed longs.
>
> > > But I guess my bad for not having the ISO spec memorized in all
> > > aspects.
>
> > Bad?  Not at all.  You missed something and didn't get the joke.  It's
> > not a big deal; why make it one?
>
> I DON'T KNOW!!! :-)
>
> Is the damn week over yet?  ...
>
> Tom

yeah. It's over.ha.