2009-02-05 12 views

Répondre

6

Eh bien, plutôt que d'utiliser l'IDE, vous pouvez utiliser svcutil à la ligne de commande via un script de construction? Ensuite, tout ce que vous avez à faire est de ré-exécuter la chauve-souris/script/tout ...

+0

C'est ce que nous faisons dans mon magasin. Nous reconstruisons toujours tous les proxies et les références dans Visual Build ... –

+0

Je vote pour cela aussi. Construire l'automatisation est la voie à suivre! –

+0

Avez-vous un exemple d'exécution d'une mise à jour de référence de service WSDL via la commande svcutil? – D3vtr0n

0

Je préfère éviter de définir des références aux services WCF via le mécanisme IDE, si je peux l'éviter. Je préfèrerais simplement fournir des procurations dans une bibliothèque de classes séparée. De cette façon, ce qui se passera normalement est qu'une mise à jour du référentiel de code source va casser la construction de la copie locale et il sera alors évident que quelque chose doit changer. Après tout, cela devrait être aussi douloureux que n'importe quel changement d'interface publique. Je ne suis pas fan de svcutil.exe.

1

Je n'utilise pas du tout les proxies générés. Je n'ai qu'un assemblage partagé entre mon client et mon serveur qui définit les interfaces de contrat de service + le tour de passe-passe suivant.

// this class can be used to instantiate a unidirectional proxy (one that doesn't require callbacks from the server) 
    public class UniDirectionalServiceProxy<T> : System.ServiceModel.ClientBase<T> where T : class 
    { 
     public UniDirectionalServiceProxy() 
     { 
     } 

     public UniDirectionalServiceProxy(string endpointConfigurationName) : 
      base(endpointConfigurationName) 
     { 
     } 

     public UniDirectionalServiceProxy(string endpointConfigurationName, string remoteAddress) : 
      base(endpointConfigurationName, remoteAddress) 
     { 
     } 

     public UniDirectionalServiceProxy(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) : 
      base(endpointConfigurationName, remoteAddress) 
     { 
     } 

     public UniDirectionalServiceProxy(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) : 
      base(binding, remoteAddress) 
     { 
     } 

     // new keyword allows us to supercede the inherited protected member and make it public. 
     public new T Channel 
     { 
      get 
      { 
       return base.Channel; 
      } 
     } 
    } 

Cela vous semble familier, n'est-ce pas? Construisez cet objet, puis changez simplement vos appels pour utiliser le membre Channel. Vous pouvez également utiliser ChannelFactory pour obtenir le même résultat (je suppose qu'ils ont fait de Channel un membre protégé de ClientBase pour encourager les développeurs à utiliser ChannelFactory), mais je préfère ce mécanisme car vous vous retrouvez avec un seul objet qui encapsule la communication contrôle et les appels à travers le fil. Évidemment, de cette façon vous perdez les méthodes async de svcutil, mais c'est assez facile de vous débrouiller avec les délégués.