0

I am having an issue with reading a property over a .NET remoting channel. Here is the beginning of my class:

[Serializable]
public class MachineID
{
    private string mySystemDeviceSerial = null;
    /// <summary>
    /// Returns the hard drive serial that Windows is installed on.
    /// </summary>
    public string SystemDeviceSerial
    {
        get { return mySystemDeviceSerial; }
    }

    private string mySystemName = null;
    /// <summary>
    /// Returns the current name of the system.
    /// </summary>
    public string SystemName
    {
        get { return mySystemName; }
    }

    private string myLastError = string.Empty;
    /// <summary>
    /// Returns the last error that occurred. Returns string.Empty if no error has occurred.
    /// </summary>
    public string LastError
    {
        get { return myLastError; }
    }

    private int myPort = -2;
    public int Port
    {
       get { return this.myPort; }
       set { this.myPort = value; }
    }

All properties are accessible just fine on the local machine. However, when I try to read the Port property from a client over a .NET remoting channel, I do not get the value that has been assigned to myPort, but rather, the initial value of -2. I am stumped on this, as the all of the string properties are able to be read fine. Any ideas? Am I not serializing this class properly?

It is worthy to note that all I have done to make this class and members serializable is add the [Serializable] attribute at the top of the class. I am not sure if this is the proper way to do this, so perhaps this could be a part of the issue?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
codewario
  • 19,553
  • 20
  • 90
  • 159
  • Do both computers have exactly the same assembly that contains this class? – Peter Ritchie Aug 29 '12 at 21:37
  • 2
    The only property with a setter. And it is getting marshaled by value. So the server's copy of the object isn't getting updated, somehow. Deriving from MarshalByRefObect is probably a quick fix. – Hans Passant Aug 29 '12 at 22:32
  • 1
    FYI, were you aware that Remoting has been deprecated in favor of WCF? – John Saunders Aug 30 '12 at 00:09
  • @JohnSaunders: I am aware, but the decision to update to WCF does not fall on my shoulders, though I have been pushing for it for a while. We kind of have an "if it's not broken, don't fix it" mentality here, even though there are many reasons we would benefit moving to WCF – codewario Aug 30 '12 at 01:40
  • @PeterRitchie yes, at this point they do, but as we release updates, this will not always be the case – codewario Aug 30 '12 at 01:44

1 Answers1

0

My guess (and I stress it is just a guess) is that you have the order wrong- that you are

  1. Retrieving an item from the remoting host
  2. Updating it (on the host), then
  3. Expecting the value in the client to be updated to the value you changed on the host.

When you use [Serializable], you are turning the object into a byte stream, transmitting it over the wire to the remoting client, then reconstituting it into a new object on the client. That means that the client's copy is completely disconnected from the server's copy. If you want the client's copy to always show the updated values from the server (without re-transmitting the whole object), make it inherit from MarshalByRefObject like @Hans-Passant suggests. That makes the client copy a transparent proxy that queries the server each time you access one of it's properties.

Chris Shain
  • 50,833
  • 6
  • 93
  • 125
  • Sort of. I'll give this a shot and let you know how it goes, but the myPort variable is set before any clients would be able to connect to the server. – codewario Aug 30 '12 at 01:41