Десериализация FileStream на клиенте с помощью WCF

Я очень новичок в WCF, поэтому заранее извиняюсь, если что-то исказил.

Это использует .NET 4.0 RC1.

Используя WCF, я пытаюсь десериализовать ответ с сервера. Базовый ответ имеет Stream в качестве единственного MessageBodyMember.

public abstract class StreamedResponse
{
  [MessageBodyMember]
  public Stream Stream { get; set; }

  public StreamedResponse()
  {
    this.Stream = Stream.Null;
  }
}

Производные версии этого класса на самом деле являются сериализованными, но у них нет атрибута MessageBodyMember (у них есть другие базовые типы, такие как int, string и т. д., указанные как значения MessageHeader).

[MessageContract]
public class ChildResponse : StreamedResponse
{
  [DataMember]
  [MessageHeader]
  public Guid ID { get; set; }

  [DataMember]
  [MessageHeader]
  public string FileName { get; set; }

  [DataMember]
  [MessageHeader]
  public long FileSize { get; set; }

  public ChildResponse() : base()
  {
  }
}

Поток всегда является FileStream, в моем конкретном случае (но не всегда).

Сначала WCF сказал, что FileStream не является известным типом, поэтому я добавил его в список известных типов, и теперь он сериализуется. Также на первый взгляд кажется, что он десериализуется на стороне клиента (это тип FileStream).

Проблема в том, что он не кажется пригодным для использования. Все CanRead, CanWrite и т. д. являются ложными, а свойства Length, Position и т. д. вызывают исключения при использовании. То же самое с ReadByte().

Что мне не хватает, что помешало бы мне получить действительный FileStream?


person Nathan    schedule 05.04.2010    source источник


Ответы (1)


Короткий ответ: вы не можете получить экземпляр FileStream. В WCF вы работаете за границами домена приложения (вам не обязательно это делать, но предполагается, что это так). Из-за этого вы не можете сериализовать FileStream в значение и транспортировать его через барьер домена приложения (FileStream зависит от домена приложения, в первую очередь потому, что он работает с неуправляемыми дескрипторами файлов, которые не имеют смысла за пределами текущий домен приложения).

При этом, если вам действительно нужна информация о потоке, а также о содержимом, вы, вероятно, захотите добавить информацию о потоке в виде заголовков сообщений, а затем получить эти заголовки, как экземпляр Stream, который вы получаете с обеих сторон. никогда не будет фактическим типом потока, который был установлен на стороне вызывающего/вызываемого.

person casperOne    schedule 05.04.2010