Registering _instances_ object instead of _types_ with .NET removal?
There's something I just don't understand about removing .NET. Well, actually two things:
-
Why is the emphasis on classes that inherit MarshalByRef instead of ala interfaces, the original COM style (which I liked)?
-
Why does .NET remote work always force you to efficiently create an object pool rather than letting you bind specific instances to 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 an instance of "Server" myself and then just bind it to an endpoint?
RemotingTypes.Server myInstance = new RemotingTypes.Server();
Now what? How can I link "myInstance" to the URL "MyURL"?
source to share
Problem with Nickd's answer: I wanted to know how to bind an already created instance to a url, not how to delete .NET for that for me (in some instance I created that doesn't have a default constructor, for example).
I was hoping there would be some epic answer explaining the "philosophy" to remove .NET and why it is inextricably linked to the type system ...
Instead, I concluded: a) This is because .NET removes the crap. Don't use it b) Use WCF instead
source to share
I can't really address points 1 and 2 as I have no experience with COM and I don't understand 2, but to answer your final question, if you are using the system.Activator class, you can do this:
RemotingTypes.Server myInstance = (RemotingTypes.Server) Activator.GetObject(typeof(RemotingTypes.Server), MyUrl);
This means you have to bind it at build time, but it's all on the client side.
See my similar question .
source to share