Désérialisation d'un FileStream sur le client en utilisant WCF

Question

Je suis très nouveau à WCF, donc je m'excuse d'avance si je déforme quelque chose.

Ceci utilise .NET 4.0 RC1. En utilisant WCF, j'essaye de désérialiser une réponse du serveur. La réponse de base a un flux en tant que seul MessageBodyMember.

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

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

Les versions dérivées de cette classe sont en fait ce qui est sérialisé, mais ils n'ont pas un attribut MessageBodyMember (ils ont d'autres types de base tels que int, string, etc. répertorié comme valeurs 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() 
    { 
    } 
} 

Le flux est toujours un FileStream, dans mon cas spécifique (mais peut ne pas l'être toujours). Dans un premier temps, WCF a déclaré que FileStream n'était pas un type connu, donc je l'ai ajouté à la liste des types connus et maintenant il se sérialise. Il semble également, à première vue, le désérialiser du côté du client (c'est le type FileStream).

Le problème est qu'il ne semble pas être utilisable. Toutes les propriétés CanRead, CanWrite, etc. sont fausses, et les propriétés Length, Position, etc, affichent des exceptions lorsqu'elles sont utilisées. Pareil avec ReadByte().

Qu'est-ce qui me manque pour obtenir un FileStream valide?

Answer 1

La réponse courte est que vous ne pouvez pas obtenir une instance FileStream. Dans WCF, vous travaillez à travers des limites de domaine d'application (vous n'êtes pas obligé de le faire, mais il est supposé que vous l'êtes). Pour cette raison, vous ne pouvez pas sérialiser un FileStream en une valeur et le transporter à travers la barrière d'app-domain (le FileStream est spécifique au domaine d'application, notamment parce qu'il fonctionne avec des handles de fichiers non gérés qui n'ont pas de sens en dehors de le domaine d'application actuel). Cela étant dit, si vous avez vraiment besoin d'informations sur le flux ainsi que sur le contenu, alors vous voudrez probablement ajouter les informations sur le flux comme en-têtes de message, puis récupérer ces en-têtes, comme l'instance Stream que vous obtenez de chaque côté ne sera jamais le type de flux réel qui a été défini du côté appel/appelé.