none
What does the "remote" mean in System Namespace page? RRS feed

  • Question

  • https://msdn.microsoft.com/en-us/library/system(v=vs.110).aspx

    "Other classes provide services supporting data type conversion, method parameter manipulation, mathematics, remote and local program invocation"

    The page just shows 3 occurrences of "remote".

    Thanks!


    • Edited by PowerDesign Saturday, June 20, 2015 9:17 AM
    Saturday, June 20, 2015 9:16 AM

Answers

  • It refers to "remoting" - calling method on objects from another app domain (which may even be running in another process and on another machine). Such objects need to inherit from MarshalByRefObject which is one of the types you can find in the System namespace.

    See the remoting documentation for more information: https://msdn.microsoft.com/en-us/library/kwdt6w2k(v=vs.100).aspx

    Saturday, June 20, 2015 3:24 PM
    Moderator

All replies

  • It refers to "remoting" - calling method on objects from another app domain (which may even be running in another process and on another machine). Such objects need to inherit from MarshalByRefObject which is one of the types you can find in the System namespace.

    See the remoting documentation for more information: https://msdn.microsoft.com/en-us/library/kwdt6w2k(v=vs.100).aspx

    Saturday, June 20, 2015 3:24 PM
    Moderator
  • Hi, Mike, thanks! Well, it recommends WCF for new development.

    Which one do you think takes less effort, Remoting or WCF?

    Sunday, June 21, 2015 1:27 AM
  • I'd say it depends on what you are trying to achieve.

    Remoting may appear simpler at first: you just inherit from MarshalByRefObject, register some remoting channels and you can start making calls. At the same time this simplicity may later lead to problems, for example in some scenarios it is preferable to create an interface and make remote calls via that interface instead of calling the object methods directly. Remoting configuration is simpler than WCF configuration but you may soon find that it's also more limited in what it can do. Remoting isn't interoperable with anything and only works in the desktop version of the .NET Framework.

    Sunday, June 21, 2015 8:31 AM
    Moderator
  • At the same time this simplicity may later lead to problems, for example in some scenarios it is preferable to create an interface and make remote calls via that interface instead of calling the object methods directly.

    Hi,

    For interface, I see something here, although I think I won't need to use it:

    Basic Remoting Task List:

    https://msdn.microsoft.com/en-us/library/bxcsax42(v=vs.100).aspx

    "Alternatively you can define an interface in a shared assembly, implement that interface on the remote object, and reference the shared assembly in the client application."

    Otherwise, I think .Net Remoting should meet the needs of my simply application, although I don't really like learning legacy technologies : )

    Thanks.

    Monday, June 22, 2015 5:40 AM
  • "Otherwise, I think .Net Remoting should meet the needs of my simply application, although I don't really like learning legacy technologies : )"

    Well, if the needs of your application are simple then there's not much to learn anyway. Unless you need more advanced features like encryption and authentication getting remoting to work it's pretty simple. I don't remember the exact details but I think remoting has limited security options. It is possible to extend it but it requires a bit of code and at that point you may as well forget about remoting and use WCF which as a lot more security feature built-in.

    Monday, June 22, 2015 10:45 AM
    Moderator
  • I was trying to achieve something with .Net Remoting, with this simple introduction:

    https://msdn.microsoft.com/en-us/library/xws7132e(v=vs.100).aspx

    Unfortunately, it crashes:

    Unhandled Exception: System.Runtime.Remoting.RemotingException: Requested Servic
    e not found

    Server stack trace:
       at System.Runtime.Remoting.Channels.SoapServerFormatterSink.ProcessMessage(IS
    erverChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestH
    eaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& response
    Headers, Stream& responseStream)

    Exception rethrown at [0]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req
    Msg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
    ta, Int32 type)
       at RemotableType.SayHello()
       at client.Main(String[] args)


    Any ideas?

    Thanks.
    • Edited by PowerDesign Wednesday, June 24, 2015 7:15 AM
    Wednesday, June 24, 2015 7:14 AM
  • That sample code works fine for me. "Requested service not found" usually implies that the client connected to the server but the server and client use different URLs. Like one using RemotableType.rem and the other RemotableType2.rem. But I suppose you simply copy pasted the config files so this sounds like an unlikely mistake.

    Unfortunately I don't know what else could cause this particular error.

    Note that you do not have to use configuration files. For example the client code could also use Activator.GetObject:

    RemotableType remoteObject = (RemotableType)Activator.GetObject(typeof(RemotableType), "http://localhost:8989/RemotableType.rem");
    

    while the server could manually register the necessary channel and remote type:

    using System;
    using System.Runtime.Remoting;
    using System.Runtime.Remoting.Channels;
    using System.Runtime.Remoting.Channels.Http;
    
    class Program
    {
        static void Main()
        {
            ChannelServices.RegisterChannel(new HttpServerChannel(8989), false);
            RemotingConfiguration.RegisterWellKnownServiceType(typeof(RemotableType), "RemotableType.rem", WellKnownObjectMode.Singleton);
            Console.WriteLine("Listening for requests. Press enter to exit...");
            Console.ReadLine();
        }
    }
    
    Note: requires a reference to the System.Runtime.Remoting assembly.

    Each approach has its pros and cons. Configuration files can be changed without also changing the code. But if you want the user to supply a port or channel name then it may make sense to create the configuration in code so you don't have to ask them to modify the .config file.

    Thursday, June 25, 2015 5:37 AM
    Moderator
  • Hi Mike, may I send you my code for examination or could you send me yours (the config file version, including code)? Many thanks!
    • Edited by PowerDesign Thursday, June 25, 2015 6:32 AM
    Thursday, June 25, 2015 6:27 AM
  • "may I send you my code for examination"

    You could upload it somewhere (OneDrive for example) and I can take a look. Or you could simply post the config files here in case you have changed them.

    "or could you send me yours (the config file version)? "

    I simply copy pasted the config files that were included in that MSDN article. I didn't make any modfications to them.

    Thursday, June 25, 2015 6:31 AM
    Moderator
  • https://onedrive.live.com/?id=B0C13E8E964C7376%218690&cid=B0C13E8E964C7376&group=0

    Many thanks!

    Thursday, June 25, 2015 6:37 AM
  • It seems that you have a typo in the listener.exe.config file. You have wellknow and it's supposed to be wellknown.
    Thursday, June 25, 2015 7:07 AM
    Moderator
  • Great : ) thanks for this quick solution.

    As I type in the .config file in Visual Studio, the first several tag made use of IntelliSense to suggest complete words, the rest of the tags just didn't benefit from the suggestion : )

    Connecting to another machine in LAN is even faster than to localhost : )
    • Edited by PowerDesign Thursday, June 25, 2015 7:43 AM
    Thursday, June 25, 2015 7:16 AM
  • "Connecting to another machine in LAN is even faster than to localhost : )"

    Yeah, I noticed that there's a delay with this configuration. If you change the client config to use 127.0.0.1 or the actual IP of the machine instead of localhost then that delay is gone.

    Thursday, June 25, 2015 7:50 AM
    Moderator
  • Cool!
    Thursday, June 25, 2015 8:04 AM