> Hi,
> Just recently encountered a problem while building an
> application with multiple domains. If I try to marshal an
> object/interface from one of the non-default domains I am
> unable to connect to it from another application. If the
> object lives in the default domain, everything works as
> it should.
> The second application(client) is able to obtain a proxy
> to the remote object with no problem, however the actual
> connection (tcp/http) is not activated until the first
> method call is made on the proxy object. This is when I
> get the 'Service not found' error. Traced through the
> call stack and with the help of the Rotor source code
> determined that the function
> System.Runtime.Remoting.Channels.BinaryServerFormatterSink
> .ProcessMessage method was throwing the remoting
> exception on the server side. Apparently the function
> RemotingServices.GetServerTypeForUri(<uri>) was
> returning 'null' indicating that it couldn't match the
> URI with a registered/marshaled object. Since this method
> is declared as 'private static', a copy of it exists in
> each application domain, so I'm assuming that Remoting
> only calls the method in the default domain when trying
> to resolve a URI and the object I'm trying to connect to
> is registered in another app domain. If I move the object
> to the default domain, everything works as expected. I
> know that remoting channels are domain specific but was
> hoping that there was a workaround that didn't involve
> relocating the marshaled objects.
> In case you're wondering why I've got multiple app
> domains - it's because they are used to host user written
> plug-ins to the main application (for security/fault
> isolation).
> Any comments would be greatly appreciated.
> Thanks,
> Bill

>
> Hi Markus,
> I'm not sure (couldn't quite get a mental picture of how your
> client/server app is structured) but it could very well be the case as
> you described - although cross domain remoting (on the same PC) uses an
> optimized (memory -> memory) data transfer channel and is quite fast.
> Speed will also be affected by the type of marshalling you do
> (MarshalByRef or MarshalByValue) and the 'chunkiness' of the method
> calls. Just out of curiosity, are you running version 1.0 or 1.1 of the
> NET Framework?
> I don't use a remoting configuration file for channel assignment as the
> app is designed to run on any system and configuring a specific IP
> address may not work in all environments. I let .NET pick any free
> channel when the Server starts up, then get the IP address it chose and
> write it to the Registry where client apps (on the same machine) can use
> it to make a dynamic connection.
>
> Regards,
> Bill
>
>
> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!

"Markus Reiner" <m.reiner@gmx-nospam.de> wrote in message
news:e4WsmSw5DHA.360@TK2MSFTNGP12.phx.gbl...
> Hi Bill,
>
> I'm using .NET 1.1 and have only one MBRO (named "Connection" :-) ).
> The other objects are serializable. You are right the cross domain
> channel is quite fast but I think the performance loss is because of
> the serialization of the objects between the domains.
>
> Bye
>
> Markus
>
> "Bill Gowans" <bgowans@ati.com> schrieb im Newsbeitrag
> news:#Bts0Kp5DHA.2692@TK2MSFTNGP09.phx.gbl...
> >
> > Hi Markus,
> > I'm not sure (couldn't quite get a mental picture of how your
> > client/server app is structured) but it could very well be the case as
> > you described - although cross domain remoting (on the same PC) uses an
> > optimized (memory -> memory) data transfer channel and is quite fast.
> > Speed will also be affected by the type of marshalling you do
> > (MarshalByRef or MarshalByValue) and the 'chunkiness' of the method
> > calls. Just out of curiosity, are you running version 1.0 or 1.1 of the
> > NET Framework?
> > I don't use a remoting configuration file for channel assignment as the
> > app is designed to run on any system and configuring a specific IP
> > address may not work in all environments. I let .NET pick any free
> > channel when the Server starts up, then get the IP address it chose and
> > write it to the Registry where client apps (on the same machine) can use
> > it to make a dynamic connection.
> >
> > Regards,
> > Bill
> >
> >
> > *** Sent via Developersdex http://www.developersdex.com ***
> > Don't just participate in USENET...get rewarded for it!
>
>