Registering object _instances_ instead of _types_ with .NET remoting?

Question

There's something I'm just not getting about .NET remoting. Well, two things actually:

1. Why is the emphasis back on classes that inherit from MarshalByRef instead of interfaces ala the original COM style (which I liked)?

2. Why is it that .NET remoting always forces you to effectively create some sort of object pool instead of allowing you to associate specific instances with a URL?

Server code:

RemotingConfiguration.RegisterWellKnownServiceType(typeof(RemotingTypes.Server), "MyURL", WellKnownObjectMode.Singleton);

Client code:

RemotingConfiguration.RegisterWellKnownServiceType(typeof(RemotingTypes.Server), "MyURL", WellKnownObjectMode.Singleton);

But suppose I want to create the "Server" instance myself and then just bind it to an endpoint?

RemotingTypes.Server myInstance = new RemotingTypes.Server();

What now? How can I associate "myInstance" with the URL "MyURL" ?

Answer 1

I can't really address points 1 and 2 as I have no experience of COM and I don't understand 2, but to answer your specific final question, if you use the system.Activator class, you can do this:

RemotingTypes.Server  myInstance = (RemotingTypes.Server) Activator.GetObject(typeof(RemotingTypes.Server), MyUrl);

It means you have to bind it at construction time, but it's all client side.

See my similar question.

Answer 2

The problem with Nickd's answer: I wanted to know how to associate an already created instance with a URL, rather than how to get .NET remoting to do this for me (some instance that I have created that does not have a default constructor, for example).

I was hoping there'd be some epic response explaining the "philosophy" behind .NET remoting, and why it's inextricably coupled to the type system...

What I've concluded instead is simply that: a) It's because .NET remoting sucks. Don't use it b) Use WCF instead