Select specific channel on Activator.GetObject

Question

Suppose that you have registered two TcpChannels in .NET Remoting.

Then I try to get the proxy using Activator.GetObject using a url tcp://...

Is it possible to choose which channel to use?

Thanks in advance.

Answer 1

Did you solve this?

I've had exactly the same problem last week. (A slight unpublicised side-effect of nunit is that it fires up the default "tcp" channel when loading your dlls to run unit tests (my problem)... then I was creating a custom TcpClientChannel instance with custom sinks to talk to our server software... and our sinks weren't firing when I instantiated a server object)

There are 3 solutions:

1. If you want one to permanently override the other then simply pass the "priority" property into the IDictionary constructor on your TcpClientChannel. The default if not set is 1, so if you want it to override say the default "tcp" channel registration then set higher than 1. NB the "name" property must also be set, but can be string.Empty if required (and then you can have as many of these as you want)

2. Name your channels when registering, then write a nice IDisposable wrapper to call in a "using" construct, which calls ChannelServices.Unregister(...) on the channels you don't want to activate when calling Activator.GetObject(...). Then when your "using" block ends (i.e. calls Dispose()), just reload the channels you unregistered... ensure you use "lock" on some common object reference if its multi threaded within your app...this may create a bottleneck! (This is the approach I took, as my unit tests were using a pre-written library which created the server connection: the risk of instability in the production software for the sake of my unit testing was too high)

3. Temporarily bump the priority of your target channel using deep reflection (i.e. fiddling with private FieldInfos... namely the private int _channelPriority (i think)... use reflector to double check), before you call Activator.GetObject. This is also open to threading issues, and also not framework version-proof (so I avoided this one)