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:
Why is the emphasis back on classes that inherit from MarshalByRef instead of interfaces ala the original COM style (which I liked)?
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" ?
Solution
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
OTHER TIPS
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.