service web ne peut pas sérialiser une interface

J’ai une interface comme celle-ci:

public interface IDocument : ISerializable { Boolean HasBeenUploaded { get; set; } void ISerializable.GetObjectData(SerializationInfo, StreamingContext) { } }

Il existe trois documents qui en héritent, qui sont tous parfaitement sérialisés. Mais lors de la création d’un service Web simple, cela ne fait rien, où ils peuvent être téléchargés …

 public class DCService : System.Web.Services.WebService { [WebMethod] public Boolean ReceiveDocument(IDocument document) { DBIO io = new DBIO(); return io.InsertIntoDB(document); // does nothing; just returns true } }

Je reçois ceci en essayant de l’exécuter: “Je ne peux pas sérialiser l’interface IDocument”

Je ne sais pas trop pourquoi cela poserait un problème. Je sais que certaines personnes ont eu des problèmes parce qu’elles ne voulaient pas forcer les sous-classes à implémenter la sérialisation personnalisée, mais c’est ce que je fais, et jusqu’à présent, cela a été un succès.

edit> Si je crée des méthodes Web individuelles qui acceptent les objects qui implémentent l’interface, cela fonctionne correctement, mais cela affaiblit le contrat entre le client / serveur (et compromet l’objective initial de l’interface)

Vous devrez peut-être utiliser un atsortingbut XmlInclude pour votre méthode Web. Un exemple peut être trouvé ici . Nous avons déjà rencontré ce problème et avons ajouté des atsortingbuts XmlInclude à la fois à notre classe de proxy de service Web sur le client et à certaines méthodes de service Web.

 [WebMethod] [XmlInclude(typeof(MyDocument))] public Boolean ReceiveDocument(IDocument document) { DBIO io = new DBIO(); return io.InsertIntoDB(document); // does nothing; just returns true }

Asp.net doit avoir besoin de savoir quelle classe elle instanciera lors de l’appel de cette méthode. C’est pourquoi cela fonctionne lors de la définition de plusieurs méthodes avec des classes spécifiques, c’est-à-dire que l’appel vous indiquera quelle classe utiliser.

Déterminez si vous souhaitez que le client envoie le même ensemble d’informations pour n’importe quel document ou si vous devez vraiment pouvoir envoyer des informations différentes pour différents documents. Dans ce dernier cas, vous devez faire en sorte que le client connaisse les classes qui implémentent l’IDocument, et vous le faites avec XmlInclude (comme l’a signalé firedfly).

Si vous souhaitez au contraire toujours envoyer les mêmes informations et pas maintenant pour des classes spécifiques, définissez une classe avec ces informations et vous obtiendrez ainsi les mêmes méthodes. Si vous devez jouer avec IDocument dans le rest du code de service, utilisez une logique appropriée dans le service pour obtenir une instance d’IDocument à l’aide des données reçues.

+1 pour firedfly, toutefois, il convient de noter que l’atsortingbut XmlInclude peut être ajouté à la classe de service Web plutôt qu’à chaque méthode (ou type de base, qui est également une option). Je l’ai testé et le code est bien généré, en gardant la structure d’inheritance.

Je l’ai tiré de la section des commentaires du même blog auquel il a fait référence. Le mérite revient donc au PO.

BTW ce n’est pas un commentaire sur le post de firedfly car je n’ai pas assez de réputation pour commenter