10

I have been trying to serialize an array across an AppDomain boundary, using the following code:

public int Read(byte[] buffer, int offset, int count)
{
    return base.Read(buffer, offset, count);
}

As a guess, after noticing the attributes elsewhere, I marked the method's parameters with [In] and [Out] attributes, which seemed to cause the parameters to behave as if they were passed by reference.

For example:

public int Read([In, Out] byte[] buffer, int offset, int count)
{
    return base.Read(buffer, offset, count);
}

Before I added the attributes, the contents of the buffer variable were lost after returning from the method across an AppDomain boundary.

The class (SslStream) was inheriting from MarshalByRefObject but not marked with the Serializable attribute. Is this the only way to make a parameter pass-by-value? Are these attributes being recognised somehow by .NET when the class is being serialised? And do they truly cause the parameter to be passed by reference, or are the contents just copied?

g t
  • 7,287
  • 7
  • 50
  • 85

2 Answers2

12

This is a remarkably poorly documented feature of .NET Remoting. It doesn't have anything to do with whether your class is [Serializable] or derived from MarshalByRefObject. At issue here is how the argument is marshaled across the AppDomain boundary. The call itself is made under the hood by Remoting. Arrays do not automatically get marshaled back after the call, clearly a performance optimization. Only the [Out] attribute is required, [In] is implied. I could not find any relevant documentation about this in MSDN, just a blog post from somebody that ran into the same issue (scroll down to "Using OutAttribute in Remoting").

Some code to play with:

using System;
using System.Runtime.InteropServices;

class Program {
    static void Main(string[] args) {
        var ad = AppDomain.CreateDomain("second");
        var t = (Test)ad.CreateInstanceAndUnwrap(typeof(Test).Assembly.FullName, typeof(Test).FullName);
        var b = new byte[] { 1 };
        t.Read(b);
        System.Diagnostics.Debug.Assert(b[0] == 2);
    }
}

class Test : MarshalByRefObject {
    public void Read([Out]byte[] arg) {
        arg[0] *= 2;
    }
}
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Excellent, thanks! I'd never heard of these attributes before, yet the problem I was facing would have been almost unsolvable without the [Out] attribute. Lucky I noticed them in dotPeek/ILSpy. It seems surprising that arrays are not marshalled back too, as now I have to wrap the entire class with a class which has the attributed method. Pity they can't be applied from the caller's side... – g t Jan 31 '12 at 08:26
  • 2
    Checking further, a lot of Stream classes in System namespace do have the 'buffer' parameter of their Read() method marked with the [In] [Out] attributes. I wonder if the NegotiateStream and SslStream in System.IO should also have these attributes, as they're not there in .NET 4. – g t Jan 31 '12 at 08:52
2

To note, there has been additional documentation added since the original accepted answer was posted.

The definition of the directional attributes is:

  • [In]: Data modified in the unmanaged code is not written back to managed code. All data passed by value is treated as [In] by default.
  • [In/Out]: Data modified in the unmanaged code writes back to managed code. Data passed by reference (including by using the ref keyword) are treated as [In/Out] by default.
  • [Out]: Parameters modified by the out C# keyword must as expected be passed back - and default to [Out]. Using [Out] explicitly will behave identically to [In/Out] ([In] is always assumed).

So the key uses of explicitly modifying these are:

  • To instruct the program not to pass back modified data passed by reference - by using [In]
  • To instruct the program to return modified data passed to the unmanaged code - by using [In/Out] or simply [Out] (they are equivalent).

The latter of these is particularly useful for reference types which pass by value by default, such as arrays of value types - e.g. byte[].

Haighstrom
  • 577
  • 5
  • 16