Why does reading from an SslStream across AppDomains succeed but return an empty buffer?

Question

When reading normally from an SslStream using the Read(byte[] buffer, int offset, int count) method, I get the expected results.

However, if I move the SslStream object into a new AppDomain, the read still appears to function correctly (i.e. the correct number of bytes read is returned), but the buffer array is empty.

Why is this?

score 6 · Accepted Answer · edited May 23 '17 at 12:27

After some investigation, it appears that the contents of parameter arrays are not marshalled across AppDomains (probably for performance reasons).

Therefore, the data in the buffer parameter is only passed one way. Modifications to the array in the remote AppDomain will not be seen by the caller in the local AppDomain.

The way to force data in array parameters to be returned is to add the [Out] attribute to the parameter.

To solve the problem stated in the question, create a wrapper class for the SslStream and use that instead:

[Serializable]
internal class SslStreamWrapper : SslStream
{
    public SslStreamWrapper(
        Stream innerStream,
        Boolean leaveInnerStreamOpen,
        RemoteCertificateValidationCallback validationCallback,
        LocalCertificateSelectionCallback selectionCallback)
     : base(innerStream, leaveInnerStreamOpen, validationCallback, selectionCallback)
    {
    }

    // Add the [Out] attribute to the 'buffer' parameter.
    public override Int32 Read([In, Out] Byte[] buffer, Int32 offset, Int32 count)
    {
        return base.Read(buffer, offset, count);
    }
}

The class has the [Serializable] attribute, allowing it to be passed between AppDomains, and the implicit [In] parameter is included for consistency with other Stream classes.

Many other .NET classes inheriting from Stream (such as MemoryStream and BufferedStream - and even Stream itself) include the [In, Out] attributes for the buffer parameter in the Read() method.

I wonder if it was a deliberate choice to omit them for SslStream... This goes for all versions of .NET.

I would use composition instead of inheritance - write a `CrossAppDomainStreamWrapper` or somesuch which delegates all the calls to a stream passed into the constructor. That way it's more reusable. — Jon Skeet, Jun 20 '12 at 06:27

score 0 · Answer 2 · answered Jul 18 '18 at 06:22

Here's the code for alternative solution of using composition instead of inheritance, suggested by @JonSkeet in a comment on the accepted answer:

[Serializable]
public class CrossAppDomainStreamWrapper : Stream
{
    public CrossAppDomainStreamWrapper(Stream stream) => Stream = stream;

    public Stream Stream { get; }
    public override bool CanRead => Stream.CanRead;
    public override bool CanSeek => Stream.CanSeek;
    public override bool CanWrite => Stream.CanWrite;
    public override long Length => Stream.Length;
    public override long Position
    {
        get => Stream.Position;
        set => Stream.Position = value;
    }

    public override void Flush() => 
       Stream.Flush();
    public override long Seek(long offset, SeekOrigin origin) =>
        Stream.Seek(offset, origin);
    public override void SetLength(long value) =>
       Stream.SetLength(value);
    public override int Read([In, Out] byte[] buffer, int offset, int count) =>
       Stream.Read(buffer, offset, count);
    public override void Write(byte[] buffer, int offset, int count) =>
       Stream.Write(buffer, offset, count);
}

Why does reading from an SslStream across AppDomains succeed but return an empty buffer?

2 Answers2