Le passage d'une classe dérivée à une méthode de service Web qui prend un type abstrait

Question

J'ai un problème bizarre qui fait ma tête dans

je les classes suivantes définies dans un seul projet.

public abstract class AbstractUnitModel { 

     public void executeRemoteModel(){} 

} 

//this class also implements a seperate interface, but I dont think that is the issue 
public class BlastFurnaceUnitModel : AbstractUnitModel, IUnitModel {} 

maintenant, si je tente quelque chose comme ça, il fonctionne comme prévu:

class Class1 
{ 

    public void method1() { 

     BlastFurnaceUnitModel b = new BlastFurnaceUnitModel(); 
     method2(b); 
    } 

    public void method2(AbstractUnitModel a) {} 

} 

maintenant, j'ai un autre projet qui expose une méthode Web. Cette méthode prend un AbstractUnitModel et l'exécute à distance, puis renvoie les résultats au client. Donc, sur le serveur d'avoir ceci:

[WebMethod] 
public AbstractUnitModel remotelyExecuteUnitModel(UnitModelWrapperInterface.AbstractUnitModel unitModel) 
     { 

      unitModel.executeRemoteModel(); 
      return unitModel; 

     } 

Et sur le client je ceci:

public void remoteExecution() { 

       var unitModelWebService = new UnitModelRemoteServer.RemoteModelExecutionWebService(); 
       unitModelWebService.remotelyExecuteUnitModelCompleted += new UnitModelRemoteServer.remotelyExecuteUnitModelCompletedEventHandler(remoteExecutionCompleted); 
       unitModelWebService.remotelyExecuteUnitModelAsync(this.remoteBF); 
      } 

Mais mon projet ne compilera pas, et je reçois ces erreurs: Erreur 109 La meilleure surcharge match de méthode pour 'CalibrationClient.UnitModelRemoteServer.RemoteModelExecutionWebService.remotelyExecuteUnitModelAsync (CalibrationClient.UnitModelRemoteServer.AbstractUnitModel)' a des arguments invalides

Erreur 110 Argument « 1 »: ne peut pas convertir « UnitModelWrapperInterface.BlastFurnaceUnitModel » à « CalibrationClient.UnitModelRemoteServer.AbstractUnitModel »

Je ne peux pas comprendre pourquoi ce qui se passe. J'ai des références dans le projet de serveur à l'espace de noms où AbstractUnitModel est défini. La seule chose qui m'a l'air un peu drôle est qu'il utilise AbstractUnitModel de l'espace de noms 'CalibrationClient' plutôt que UnitModelWrapperInterface. Il semble que lorsque VS génère le proxy pour un webservice sur le client, il crée une implémentation abstraite partielle de AbstractUnitModel. Est-ce la source de mon problème? Si oui, comment pourrais-je y remédier?

edit pour la solution: Comme indiqué, le client doit connaître toutes les classes qui pourraient être envoyées à travers le fil. J'ai fini par résoudre ce problème en supprimant les classes proxy générées et en référençant la bibliothèque commune. Pas idéal mais assez bon dans cette situation.

Answer 1

Vous pouvez essayer [XmlInclude]:

[XmlInclude(typeof(BlastFurnaceUnitModel))] 
public abstract class AbstractUnitModel {...} 

peine d'essayer, au moins ...

(modifier) ​​ou au niveau de la méthode:

[WebMethod(), XmlInclude(typeof(BlastFurnaceUnitModel))] 
public AbstractUnitModel remotelyExecuteUnitModel(...) {...} 

(moins sûr de la deuxième)

Answer 2

Cela se produit car l'outil WSDL crée des classes proxy (ouvrir le code de service fi le et vous les verrez) qui sont les classes utilisées pour instancier quand les objets viennent du service.

Si vous voulez éviter cela, il est préférable d'utiliser WCF. Cela concerne également les objets retournés polymorphes, car les services web ne peuvent pas gérer le polymorphisme (donc le type de retour de la méthode remotelyExecuteUnitModel est toujours AbstractUnitModel.)

Answer 3

La classe exposée dans votre WebService est créée dans un espace de noms différent à l'intérieur de votre service. référence.

Je crée généralement une méthode comme

WebServiceReferenceNS.AbstractUnitModel ToWebServiceModel(AbstractUnitModel unitModel) 
{ 
} 

pour préparer les classes pour le WebService. Mais j'aimerais voir s'il y a une solution plus élégante.