Transport : UDP

L’exemple de transport UDP montre comment implémenter la monodiffusion UDP et la multidiffusion en tant que transport Windows Communication Foundation (WCF) personnalisé. L’exemple décrit la procédure recommandée pour créer un transport personnalisé dans WCF, à l’aide de l’infrastructure de canal et en suivant les bonnes pratiques WCF. Les étapes de création d’un transport personnalisé sont les suivantes :

Choisissez les modèles d’échange de messages de canal (IOutputChannel, IInputChannel, IDuplexChannel, IRequestChannel ou IReplyChannel) pris en charge par ChannelFactory et ChannelListener. Déterminez ensuite si vous prendrez en charge les variantes de session de ces interfaces.
Créez une fabrique de canaux et un écouteur qui prennent en charge votre modèle d’échange de messages.
Vérifiez que toutes les exceptions spécifiques au réseau sont normalisées à la classe dérivée appropriée de CommunicationException.
Ajoutez un <élément de liaison> qui ajoute le transport personnalisé à une pile de canaux. Pour plus d’informations, consultez Ajout d’un élément de liaison.
Ajoutez une section d’extension d’élément de liaison pour exposer le nouvel élément de liaison au système de configuration.
Ajoutez des extensions de métadonnées pour communiquer des fonctionnalités à d’autres points de terminaison.
Ajoutez une liaison qui préconfigure une pile d’éléments de liaison en fonction d’un profil bien défini. Pour plus d’informations, consultez Ajout d’un élément Binding standard.
Ajoutez une section de liaison et un élément de configuration pour rendre la liaison visible au système de configuration. Pour plus d'informations, consultez Ajout de la prise en charge de la configuration.

Modèles d’échange de messages

La première étape de l’écriture d’un transport personnalisé consiste à décider quels modèles d’échange de messages (MEPs) sont requis pour le transport. Il existe trois députés parmi lesquels choisir :

Datagramme (IInputChannel/IOutputChannel)

Lorsque vous utilisez un MEP datagramme, un client envoie un message en utilisant un échange de type « déclenché et oublié » (fire and forget). Un échange de ce type requiert une confirmation hors bande de la réussite de la remise. Le message peut être perdu en transit et n’atteindre jamais le service. Si l’opération d’envoi se termine correctement du côté du client, cela ne garantit pas que le récepteur distant ait reçu le message. Le datagramme est un bloc de construction fondamental pour la messagerie, car vous pouvez créer vos propres protocoles, y compris des protocoles fiables et des protocoles sécurisés. Les canaux de datagramme client implémentent l'interface IOutputChannel et les canaux de datagramme de service implémentent l’interface IInputChannel.
Demande-réponse (IRequestChannel/IReplyChannel)

Dans ce MEP, un message est envoyé et une réponse est reçue. Le modèle se compose de paires demande-réponse. Des exemples d’appels de requête-réponse sont des appels de procédure distante (RPC) et des GET de navigateur. Ce modèle est également appelé Half-Duplex. Dans ce MEP, les canaux clients implémentent IRequestChannel et les canaux de service implémentent IReplyChannel.
Duplex (IDuplexChannel)

Le MEP duplex permet à un client d'envoyer un nombre arbitraire de messages et de les recevoir dans n’importe quel ordre. Le MEP duplex est similaire à une conversation téléphonique, où chaque mot prononcé correspond à un message. Étant donné que les deux côtés peuvent envoyer et recevoir dans ce MEP, l’interface implémentée par le client et les canaux de service est IDuplexChannel.

Chacun de ces députés peut également prendre en charge des sessions. La fonctionnalité ajoutée fournie par un canal prenant en charge les sessions est qu’elle met en corrélation tous les messages envoyés et reçus sur un canal. Le modèle Request-Response est une session à deux messages autonome, car la demande et la réponse sont corrélées. En revanche, le modèle Request-Response qui prend en charge les sessions implique que toutes les paires demande/réponse sur ce canal sont corrélées les unes avec les autres. Six MEP sont donc disponibles au total : datagramme, demande-réponse, duplex, datagramme avec sessions, demande-réponse avec sessions et duplex avec sessions.

Remarque

Pour le transport UDP, le seul MEP pris en charge est le Datagram, car UDP est par nature un protocole « envoyer et oublier ».

ICommunicationObject et cycle de vie des objets WCF

WCF a une machine à états commune utilisée pour gérer le cycle de vie des objets tels que IChannel, IChannelFactory et IChannelListener qui sont utilisés pour la communication. Il existe cinq états dans lesquels ces objets de communication peuvent exister. Ces états sont représentés par l’énumération CommunicationState et sont les suivants :

Créé : il s’agit de l’état d’un ICommunicationObject lorsqu'il est instancié pour la première fois. Aucune entrée/sortie (E/S) ne se produit dans cet état.
Opening : les objets passent à cet état lorsque Open est appelé. À ce stade, les propriétés sont immuables et les entrées/sorties peuvent commencer. Cette transition est valide uniquement à partir de l’état Créé.
Ouvert : les objets passent à cet état lorsque le processus ouvert se termine. Cette transition est valide uniquement à partir de l’état Ouverture. À ce stade, l’objet est entièrement utilisable pour le transfert.
Closing : les objets passent à cet état lorsque Close est appelé pour un arrêt approprié. Cette transition est valide uniquement à partir de l’état Ouvert.
Fermé : lorsque l'état est fermé, les objets ne sont plus utilisables. En général, la plupart des configurations sont toujours accessibles pour l’inspection, mais aucune communication ne peut se produire. Cet état équivaut à être supprimé.
Erreur : dans l’état d’erreur, les objets sont accessibles à l’inspection, mais ne sont plus utilisables. Lorsqu’une erreur non récupérable se produit, l’objet passe à cet état. La seule transition valide de cet état est dans l’état Closed .

Des événements se déclenchent pour chaque transition d'état. La Abort méthode peut être appelée à tout moment et entraîne la transition immédiate de l’objet de son état actuel vers l’état Fermé. L’appel Abort met fin à tout travail non terminé.

Channel Factory et Channel Listener

L’étape suivante de l’écriture d’un transport personnalisé consiste à créer une implémentation de IChannelFactory pour les canaux clients et de IChannelListener pour les canaux de service. La couche de canal utilise un modèle de fabrication pour construire des canaux. WCF fournit des utilitaires de classe de base pour ce processus-ci.

La CommunicationObject classe implémente ICommunicationObject et applique l’ordinateur d’état décrit précédemment à l’étape 2.
La ChannelManagerBase classe implémente CommunicationObject et fournit une classe de base unifiée pour ChannelFactoryBase et ChannelListenerBase. La ChannelManagerBase classe fonctionne conjointement avec ChannelBase, qui est une classe de base qui implémente IChannel.
La ChannelFactoryBase classe implémente ChannelManagerBase et IChannelFactory consolide les CreateChannel surcharges en une OnCreateChannel méthode abstraite.
La ChannelListenerBase classe implémente IChannelListener. Elle se charge de la gestion d'état de base.

Dans cet exemple, l’implémentation de fabrique est contenue dans UdpChannelFactory.cs et l’implémentation de l’écouteur est contenue dans UdpChannelListener.cs. Les IChannel implémentations se trouvent dans UdpOutputChannel.cs et UdpInputChannel.cs.

Fabrique de canaux UDP

Le UdpChannelFactory dérive de ChannelFactoryBase. L’exemple remplace GetProperty pour fournir l’accès à la version du message de l’encodeur de message. L’exemple remplace également OnClose pour que nous puissions démonter notre instance de BufferManager lorsque la machine d'état passe à un autre état.

Canal de sortie UDP

Le UdpOutputChannel implémente IOutputChannel. Le constructeur valide les arguments et construit un objet de destination EndPoint en fonction de l’objet EndpointAddress passé.

this.socket = new Socket(this.remoteEndPoint.AddressFamily, SocketType.Dgram, ProtocolType.Udp);

Le canal peut être fermé de façon appropriée ou incorrecte. Si le canal est fermé correctement, le socket est fermé et un appel est effectué à la méthode de classe OnClose de base. Si une exception est alors levée, l'infrastructure appelle Abort pour veiller à ce que le canal soit nettoyé.

this.socket.Close(0);

Nous implémentons Send() ensuite etBeginSend()/EndSend() . Cela se décompose en deux sections principales. Tout d’abord, nous sérialisons le message dans un tableau d’octets.

ArraySegment<byte> messageBuffer = EncodeMessage(message);

Ensuite, nous envoyons les données obtenues sur le câble.

this.socket.SendTo(messageBuffer.Array, messageBuffer.Offset, messageBuffer.Count, SocketFlags.None, this.remoteEndPoint);

Le UdpChannelListener

L’élément UdpChannelListener implémenté par l’exemple dérive de la classe ChannelListenerBase. Il utilise un seul socket UDP pour recevoir des datagrammes. La OnOpen méthode reçoit des données à l’aide du socket UDP dans une boucle asynchrone. Les données sont ensuite converties en messages à l’aide de l’infrastructure d’encodage de messages.

message = MessageEncoderFactory.Encoder.ReadMessage(new ArraySegment<byte>(buffer, 0, count), bufferManager);

Étant donné que le même canal de datagramme représente des messages qui arrivent de plusieurs sources, l'UdpChannelListener est un écouteur Singleton. Il y a, au plus, un objet IChannel actif associé à cet écouteur à la fois. L’exemple génère un autre uniquement si un canal retourné par la AcceptChannel méthode est ensuite supprimé. Lorsqu'un message est reçu, il est mis en file d'attente dans ce canal singleton.

UdpInputChannel

La UdpInputChannel classe implémente IInputChannel. Il se compose d’une file d’attente de messages entrants alimentée par le socket UdpChannelListener. Ces messages sont retirés de la file d'attente par la IInputChannel.Receive méthode.

Ajout d’un élément de liaison

Maintenant que les fabrications de canaux sont construites, nous devons les exposer à l’exécution de ServiceModel via une liaison. Une liaison est une collection d’éléments de liaison qui représente la pile de communication associée à une adresse de service. Chaque élément de la pile est représenté par un <élément de liaison> .

Dans l’exemple, l’élément de liaison est UdpTransportBindingElement, qui dérive de TransportBindingElement. Il substitue les méthodes suivantes pour générer les fabrications associées à notre liaison.

public IChannelFactory<TChannel> BuildChannelFactory<TChannel>(BindingContext context)
{
    return (IChannelFactory<TChannel>)(object)new UdpChannelFactory(this, context);
}

public IChannelListener<TChannel> BuildChannelListener<TChannel>(BindingContext context)
{
    return (IChannelListener<TChannel>)(object)new UdpChannelListener(this, context);
}

Il contient également des membres permettant de cloner BindingElement et de retourner notre schéma (soap.udp).

Ajout de la prise en charge des métadonnées pour un élément de liaison de transport

Pour intégrer notre transport dans le système de métadonnées, nous devons prendre à la fois en charge l'importation et l'exportation de stratégie. Cela nous permet de générer des clients de notre liaison via l’outil utilitaire de métadonnées ServiceModel (Svcutil.exe).

Ajout de la prise en charge de WSDL

L’élément de liaison de transport d’une liaison est chargé d’exporter et d’importer les informations d’adressage dans les métadonnées. Lorsque vous utilisez une liaison SOAP, l’élément de liaison de transport doit également exporter un URI de transport correct dans les métadonnées.

Exportation du WSDL

Pour exporter les informations d’adressage, UdpTransportBindingElement implémente l’interface IWsdlExportExtension. La ExportEndpoint méthode ajoute les informations d’adressage correctes au port WSDL.

if (context.WsdlPort != null)
{
    AddAddressToWsdlPort(context.WsdlPort, context.Endpoint.Address, encodingBindingElement.MessageVersion.Addressing);
}

L’implémentation UdpTransportBindingElement de la ExportEndpoint méthode exporte également un URI de transport lorsque le point de terminaison utilise une liaison SOAP.

WsdlNS.SoapBinding soapBinding = GetSoapBinding(context, exporter);
if (soapBinding != null)
{
    soapBinding.Transport = UdpPolicyStrings.UdpNamespace;
}

Importation WSDL

Pour étendre le système d’importation WSDL pour gérer l’importation des adresses, nous devons ajouter la configuration suivante au fichier de configuration pour Svcutil.exe, comme indiqué dans le fichier Svcutil.exe.config.

<configuration>
  <system.serviceModel>
    <client>
      <metadata>
        <policyImporters>
          <extension type=" Microsoft.ServiceModel.Samples.UdpBindingElementImporter, UdpTransport" />
        </policyImporters>
      </metadata>
    </client>
  </system.serviceModel>
</configuration>

Lors de l’exécution de Svcutil.exe, il existe deux options pour obtenir Svcutil.exe pour charger les extensions d’importation WSDL :

Pointez Svcutil.exe vers notre fichier de configuration à l’aide de /SvcutilConfig:<fichier>.
Ajoutez la section de configuration à Svcutil.exe.config dans le même répertoire que Svcutil.exe.

Le UdpBindingElementImporter type implémente l’interface IWsdlImportExtension . La ImportEndpoint méthode importe l’adresse à partir du port WSDL.

BindingElementCollection bindingElements = context.Endpoint.Binding.CreateBindingElements();
TransportBindingElement transportBindingElement = bindingElements.Find<TransportBindingElement>();
if (transportBindingElement is UdpTransportBindingElement)
{
    ImportAddress(context);
}

Ajout du soutien à la politique

L’élément de liaison personnalisé peut exporter des assertions de stratégie dans la liaison WSDL pour un point de terminaison de service afin d’exprimer les fonctionnalités de cet élément de liaison.

Exportation de stratégie

Le type UdpTransportBindingElement implémente IPolicyExportExtension pour ajouter la prise en charge de l’exportation de stratégie. En conséquence, System.ServiceModel.MetadataExporter inclut UdpTransportBindingElement dans la génération de stratégie des liaisons qui l’incluent.

Dans IPolicyExportExtension.ExportPolicy, nous ajoutons une assertion pour UDP et une autre assertion si nous sommes en mode multidiffusion. Cela est dû au fait que le mode multidiffusion affecte la façon dont la pile de communication est construite, et doit donc être coordonné entre les deux côtés.

ICollection<XmlElement> bindingAssertions = context.GetBindingAssertions();
XmlDocument xmlDocument = new XmlDocument();
bindingAssertions.Add(xmlDocument.CreateElement(
UdpPolicyStrings.Prefix, UdpPolicyStrings.TransportAssertion, UdpPolicyStrings.UdpNamespace));
if (Multicast)
{
    bindingAssertions.Add(xmlDocument.CreateElement(
        UdpPolicyStrings.Prefix,
        UdpPolicyStrings.MulticastAssertion,
        UdpPolicyStrings.UdpNamespace));
}

Étant donné que les éléments de liaison de transport personnalisés sont responsables de la gestion de l’adressage, l’implémentation de IPolicyExportExtension sur UdpTransportBindingElement doit également gérer l’exportation des assertions de politique WS-Addressing appropriées pour indiquer la version de WS-Addressing utilisée.

AddWSAddressingAssertion(context, encodingBindingElement.MessageVersion.Addressing);

Importation de stratégie

Pour étendre le système d’importation de stratégie, nous devons ajouter la configuration suivante au fichier de configuration pour Svcutil.exe, comme indiqué dans le fichier Svcutil.exe.config.

<configuration>
  <system.serviceModel>
    <client>
      <metadata>
        <policyImporters>
          <extension type=" Microsoft.ServiceModel.Samples.UdpBindingElementImporter, UdpTransport" />
        </policyImporters>
      </metadata>
    </client>
  </system.serviceModel>
</configuration>

Ensuite, nous implémentons IPolicyImporterExtension à partir de notre classe inscrite (UdpBindingElementImporter). Dans ImportPolicy(), nous examinons les assertions dans notre espace de noms et traitons celles permettant de générer le transport et de vérifier s’il s’agit d’une multidiffusion. Nous devons également supprimer les assertions que nous gérons de la liste des assertions de liaison. Là encore, lors de l’exécution de Svcutil.exe, il existe deux options d’intégration :

Pointez Svcutil.exe vers notre fichier de configuration à l’aide de /SvcutilConfig:<fichier>.
Ajoutez la section de configuration à Svcutil.exe.config dans le même répertoire que Svcutil.exe.

Ajout d’une liaison standard

Notre élément de liaison peut être utilisé de deux façons :

Via une liaison personnalisée : une liaison personnalisée permet à l’utilisateur de créer sa propre liaison en fonction d’un ensemble arbitraire d’éléments de liaison.
En utilisant une liaison fournie par le système qui inclut notre élément de liaison. WCF fournit un certain nombre de ces liaisons définies par le système, telles que BasicHttpBinding, NetTcpBindinget WsHttpBinding. Chacune de ces liaisons est associée à un profil bien défini.

L'exemple implémente la liaison de profil dans SampleProfileUdpBinding, lequel dérive de Binding. Le SampleProfileUdpBinding contient jusqu’à quatre éléments de liaison : UdpTransportBindingElement, TextMessageEncodingBindingElement CompositeDuplexBindingElement, et ReliableSessionBindingElement.

public override BindingElementCollection CreateBindingElements()
{
    BindingElementCollection bindingElements = new BindingElementCollection();
    if (ReliableSessionEnabled)
    {
        bindingElements.Add(session);
        bindingElements.Add(compositeDuplex);
    }
    bindingElements.Add(encoding);
    bindingElements.Add(transport);
    return bindingElements.Clone();
}

Ajout d'un importateur de liaison standard personnalisé

Svcutil.exe et le WsdlImporter type, par défaut, reconnaît et importe les liaisons définies par le système. Sinon, la liaison est importée en tant qu’instance CustomBinding . Pour permettre à Svcutil.exe et WsdlImporter d’importer SampleProfileUdpBinding, UdpBindingElementImporter agit également comme un importateur de liaison standard personnalisé.

Un importateur de liaison standard personnalisé implémente la ImportEndpoint méthode sur l’interface IWsdlImportExtension pour examiner l’instance CustomBinding importée à partir de métadonnées pour voir si elle aurait pu être générée par une liaison standard spécifique.

if (context.Endpoint.Binding is CustomBinding)
{
    Binding binding;
    if (transportBindingElement is UdpTransportBindingElement)
    {
        //if TryCreate is true, the CustomBinding will be replace by a SampleProfileUdpBinding in the
        //generated config file for better typed generation.
        if (SampleProfileUdpBinding.TryCreate(bindingElements, out binding))
        {
            binding.Name = context.Endpoint.Binding.Name;
            binding.Namespace = context.Endpoint.Binding.Namespace;
            context.Endpoint.Binding = binding;
        }
    }
}

En règle générale, l’implémentation d’un importateur de liaison standard personnalisé implique de vérifier les propriétés des éléments de liaison importés pour vérifier que seules les propriétés qui auraient pu être définies par la liaison standard ont changé et que toutes les autres propriétés sont leurs valeurs par défaut. Une stratégie de base pour l’implémentation d’un importateur de liaison standard consiste à créer une instance de la liaison standard, à propager les propriétés des éléments de liaison vers l’instance de liaison standard prise en charge par la liaison standard et à comparer les éléments de liaison de la liaison standard avec les éléments de liaison importés.

Ajout de la prise en charge de la configuration

Pour exposer notre transport via la configuration, nous devons implémenter deux sections de configuration. Le premier est un BindingElementExtensionElement pour UdpTransportBindingElement. Cela permet aux CustomBinding implémentations de référencer notre élément de liaison. La deuxième est Configuration pour SampleProfileUdpBinding.

Élément d’extension de l’élément de liaison

La section UdpTransportElement est un BindingElementExtensionElement qui expose UdpTransportBindingElement au système de configuration. Avec quelques remplacements de base, nous définissons notre nom de section de configuration, le type de notre élément de liaison et la façon de créer notre élément de liaison. Nous pouvons ensuite inscrire notre section d’extension dans un fichier de configuration, comme indiqué dans le code suivant.

<configuration>
  <system.serviceModel>
    <extensions>
      <bindingElementExtensions>
        <add name="udpTransport" type="Microsoft.ServiceModel.Samples.UdpTransportElement, UdpTransport" />
      </bindingElementExtensions>
    </extensions>
  </system.serviceModel>
</configuration>

L’extension peut être référencée à partir de liaisons personnalisées pour utiliser UDP comme transport.

<configuration>
  <system.serviceModel>
    <bindings>
      <customBinding>
       <binding configurationName="UdpCustomBinding">
         <udpTransport/>
       </binding>
      </customBinding>
    </bindings>
  </system.serviceModel>
</configuration>

Section de liaison

La section SampleProfileUdpBindingCollectionElement est un StandardBindingCollectionElement qui expose SampleProfileUdpBinding au système de configuration. La majeure partie de l’implémentation est déléguée au SampleProfileUdpBindingConfigurationElement, qui dérive de StandardBindingElement. SampleProfileUdpBindingConfigurationElement a des propriétés correspondant aux propriétés de SampleProfileUdpBinding, et des fonctions pour mapper depuis la liaison ConfigurationElement. Enfin, nous substituons OnApplyConfiguration dans notre SampleProfileUdpBinding, tel qu'indiqué dans l'exemple de code suivant.

protected override void OnApplyConfiguration(string configurationName)
{
    if (binding == null)
        throw new ArgumentNullException("binding");

    if (binding.GetType() != typeof(SampleProfileUdpBinding))
    {
        throw new ArgumentException(string.Format(CultureInfo.CurrentCulture,
            "Invalid type for binding. Expected type: {0}. Type passed in: {1}.",
            typeof(SampleProfileUdpBinding).AssemblyQualifiedName,
            binding.GetType().AssemblyQualifiedName));
    }
    SampleProfileUdpBinding udpBinding = (SampleProfileUdpBinding)binding;

    udpBinding.OrderedSession = this.OrderedSession;
    udpBinding.ReliableSessionEnabled = this.ReliableSessionEnabled;
    udpBinding.SessionInactivityTimeout = this.SessionInactivityTimeout;
    if (this.ClientBaseAddress != null)
        udpBinding.ClientBaseAddress = ClientBaseAddress;
}

Pour inscrire ce gestionnaire auprès du système de configuration, nous ajoutons la section suivante au fichier de configuration approprié.

<configuration>
  <configSections>
     <sectionGroup name="system.serviceModel">
        <sectionGroup name="bindings">
          <section name="sampleProfileUdpBinding" type="Microsoft.ServiceModel.Samples.SampleProfileUdpBindingCollectionElement, UdpTransport" />
        </sectionGroup>
     </sectionGroup>
  </configSections>
</configuration>

Elle peut ensuite être référencée à partir de la section de configuration serviceModel.

<configuration>
  <system.serviceModel>
    <client>
      <endpoint configurationName="calculator"
                address="soap.udp://localhost:8001/"
                bindingConfiguration="CalculatorServer"
                binding="sampleProfileUdpBinding"
                contract= "Microsoft.ServiceModel.Samples.ICalculatorContract">
      </endpoint>
    </client>
  </system.serviceModel>
</configuration>

Service de test UDP et client

Le code de test pour l’utilisation de cet exemple de transport est disponible dans les répertoires UdpTestService et UdpTestClient. Le code de service se compose de deux tests : un test configure des liaisons et des points de terminaison à partir du code et l’autre le fait par le biais de la configuration. Les deux tests utilisent deux points de terminaison. Un point de terminaison utilise SampleUdpProfileBinding avec le paramètre <reliableSession> défini sur true. L'autre utilise une liaison personnalisée avec UdpTransportBindingElement. Cela équivaut à utiliser SampleUdpProfileBinding avec <reliableSession> défini sur false. Les deux tests créent un service, ajoutent un point de terminaison pour chaque liaison, ouvrent le service, et puis attendent que l’utilisateur appuie sur ENTRÉE avant de fermer le service.

Lorsque vous démarrez l’application de test de service, vous devez voir la sortie suivante.

Testing Udp From Code.
Service is started from code...
Press <ENTER> to terminate the service and start service from config...

Vous pouvez ensuite exécuter l’application cliente de test sur les points de terminaison publiés. L’application de test client crée un client pour chaque point de terminaison et envoie cinq messages à chaque point de terminaison. Sortie sur le client :

Testing Udp From Imported Files Generated By SvcUtil.
0
3
6
9
12
Press <ENTER> to complete test.

Sortie complète sur le service :

Service is started from code...
Press <ENTER> to terminate the service and start service from config...
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
   adding 0 + 0
   adding 1 + 2
   adding 2 + 4
   adding 3 + 6
   adding 4 + 8

Pour exécuter l’application cliente sur des points de terminaison publiés à l’aide de la configuration, appuyez sur Entrée sur le service, puis réexécutez le client de test. La sortie suivante doit s'afficher sur le service.

Testing Udp From Config.
Service is started from config...
Press <ENTER> to terminate the service and exit...

L’exécution du client génère à nouveau la même chose que les résultats précédents.

Pour régénérer le code client et la configuration à l’aide de Svcutil.exe, démarrez l’application de service, puis exécutez la Svcutil.exe suivante à partir du répertoire racine de l’exemple.

svcutil http://localhost:8000/udpsample/ /reference:UdpTransport\bin\UdpTransport.dll /svcutilConfig:svcutil.exe.config

Notez que Svcutil.exe ne génère pas la configuration de l’extension de liaison pour le SampleProfileUdpBinding. Vous devez donc l’ajouter manuellement.

<configuration>
  <system.serviceModel>
    <extensions>
      <!-- This was added manually because svcutil.exe does not add this extension to the file -->
      <bindingExtensions>
        <add name="sampleProfileUdpBinding" type="Microsoft.ServiceModel.Samples.SampleProfileUdpBindingCollectionElement, UdpTransport" />
      </bindingExtensions>
    </extensions>
  </system.serviceModel>
</configuration>

Pour configurer, générer et exécuter l’exemple

Pour générer la solution, suivez les instructions de Création des exemples Windows Communication Foundation.
Pour exécuter l’exemple dans une configuration à un ou plusieurs ordinateurs, conformez-vous aux instructions figurant dans la rubrique Exécution des exemples Windows Communication Foundation.
Reportez-vous à la section précédente « Service de test UDP et client ».

Last updated on 2025-06-19

Partager via