Десериализация FileStream на клиенте с использованием WCF - PullRequest
Новая
       16

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

1 голос
/ 05 апреля 2010

Я очень новичок в 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 и т. Д. Имеют значение false, а свойства Length, Position и т. Д. Выдают исключения при использовании. То же самое с ReadByte ().

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

1 Ответ

1 голос
/ 05 апреля 2010

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

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

...