Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette rubrique répertorie un certain nombre de problèmes connus rencontrés par les clients lors du développement de clients et de services WCF. Si le problème que vous rencontrez ne figure pas dans cette liste, nous vous recommandons de configurer le suivi pour votre service. Cela génère un fichier de trace que vous pouvez afficher avec la visionneuse de fichiers de trace et obtenir des informations détaillées sur les exceptions qui peuvent se produire dans le service. Pour plus d’informations sur la configuration du suivi, consultez : Configuration du suivi. Pour plus d’informations sur la visionneuse de fichiers de trace, consultez : Outil Visionneuse de trace de service (SvcTraceViewer.exe).
-
Erreur HTTP 404.3 – Introuvable La page que vous demandez ne peut pas être traitée en raison de la configuration de l’extension. Si la page est un script, ajoutez un gestionnaire. Si le fichier doit être téléchargé, ajoutez une carte MIME. Erreur détaillée InformationModule StaticFileModule.
Quelle est l’adresse de base ? Comment se rapporte-t-il à une adresse de point de terminaison ?
Après avoir installé Windows 7 et IIS, lorsque j’essaie d’accéder à un service WCF, j’obtiens le message d’erreur suivant : Erreur HTTP 404.3 – Introuvable
Voici le message d'erreur complet :
Erreur HTTP 404.3 – Introuvable La page que vous demandez ne peut pas être traitée en raison de la configuration de l’extension. Si la page est un script, ajoutez un gestionnaire. Si le fichier doit être téléchargé, ajoutez une carte MIME. Erreur détaillée InformationModule StaticFileModule.
Ce message d’erreur se produit lorsque « Activation HTTP Windows Communication Foundation » n’est pas explicitement défini dans le Panneau de configuration. Pour définir cette option, cliquez sur Programmes dans le coin inférieur gauche de la fenêtre. Cliquez sur Activer ou désactiver les fonctionnalités Windows. Développez l'élément Microsoft .NET Framework 3.5.1, puis sélectionnez Activation HTTP de Windows Communication Foundation.
Parfois, je reçois une exception MessageSecurityException sur la deuxième demande si mon client est inactif pendant un certain temps après la première demande. Que se passe-t-il?
La deuxième requête peut échouer principalement pour deux raisons : (1) la session a expiré ou (2) le serveur Web qui héberge le service est recyclé. Dans le premier cas, la session est valide jusqu’à ce que le service expire. Lorsque le service ne reçoit pas de demande du client pendant la période spécifiée dans la liaison du service (ReceiveTimeout), le service met fin à la session de sécurité. Les messages clients suivants engendrent une MessageSecurityException. Le client doit de nouveau établir une session sécurisée avec le service pour envoyer de futurs messages ou utiliser un jeton de contexte de sécurité avec état. Les jetons de contexte de sécurité avec état permettent également à une session sécurisée de survivre à un serveur Web en cours de recyclage. Pour plus d’informations sur l’utilisation de jetons de contexte sécurisé avec état dans une session sécurisée, consultez Guide pratique pour créer un jeton de contexte de sécurité pour une session sécurisée. Vous pouvez également désactiver les sessions sécurisées. Lorsque vous utilisez la liaison <wsHttpBinding>, vous pouvez définir la propriété establishSecurityContext sur false pour désactiver les sessions sécurisées. Pour désactiver les sessions sécurisées pour d’autres liaisons, vous devez créer une liaison personnalisée. Pour plus d’informations sur la création d’une liaison personnalisée, consultez Guide pratique pour créer une liaison personnalisée à l’aide de SecurityBindingElement. Avant d’appliquer l’une de ces options, vous devez comprendre les exigences de sécurité de votre application.
Mon service commence à rejeter les nouveaux clients après qu’environ 10 clients interagissent avec lui. Que se passe-t-il?
Par défaut, les services ne peuvent avoir que 10 sessions simultanées. Par conséquent, si les liaisons de service utilisent des sessions, le service accepte de nouvelles connexions clientes jusqu’à ce qu’il atteigne ce nombre, après quoi il refuse les nouvelles connexions clientes jusqu’à la fin de l’une des sessions actuelles. Vous pouvez prendre en charge davantage de clients de plusieurs façons. Si votre service ne requiert pas de sessions, n’utilisez pas de liaison avec session. (Pour plus d’informations, consultez Utilisation de sessions.) Une autre option consiste à augmenter la limite de session en modifiant la valeur de la MaxConcurrentSessions propriété en fonction du nombre approprié à votre situation.
Puis-je charger ma configuration de service à partir d’un autre emplacement que le fichier de configuration de l’application WCF ?
Oui, toutefois, vous devez créer une classe personnalisée ServiceHost qui remplace la ApplyConfiguration méthode. À l’intérieur de cette méthode, vous pouvez appeler la base pour charger la configuration en premier (si vous souhaitez également charger les informations de configuration standard), mais vous pouvez également remplacer entièrement le système de chargement de configuration. Si vous souhaitez charger la configuration à partir d’un fichier de configuration différent du fichier de configuration de l’application, vous devez analyser le fichier de configuration vous-même et charger la configuration.
L’exemple de code suivant montre comment remplacer la ApplyConfiguration méthode et configurer directement un point de terminaison.
public class MyServiceHost : ServiceHost
{
public MyServiceHost(Type serviceType, params Uri[] baseAddresses)
: base(serviceType, baseAddresses)
{
Console.WriteLine("MyServiceHost Constructor");
}
protected override void ApplyConfiguration()
{
string straddress = GetAddress();
Uri address = new Uri(straddress);
Binding binding = GetBinding();
base.AddServiceEndpoint(typeof(IData), binding, address);
}
string GetAddress()
{
return "http://MyMachine:7777/MyEndpointAddress/";
}
Binding GetBinding()
{
WSHttpBinding binding = new WSHttpBinding();
binding.Security.Mode = SecurityMode.None;
return binding;
}
}
Mon service et mon client fonctionnent très bien, mais je ne peux pas les amener à travailler quand le client est sur un autre ordinateur ? Que se passe-t-il?
En fonction de l’exception, il peut y avoir plusieurs problèmes :
Vous devrez peut-être remplacer les adresses de point de terminaison client par le nom d’hôte et non par « localhost ».
Vous devrez peut-être ouvrir le port à l’application. Pour plus d’informations, consultez les instructions de pare-feu des exemples du Kit de développement logiciel (SDK).
Pour d’autres problèmes possibles, consultez la rubrique d’exemples Exécution des exemples Windows Communication Foundation.
Si votre client utilise des informations d’identification Windows et que l’exception est une SecurityNegotiationException, configurez Kerberos comme suit.
Ajoutez les informations d’identité à l’élément endpoint dans le fichier App.config du client :
<endpoint address="http://MyServer:8000/MyService/" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IServiceExample" contract="IServiceExample" behaviorConfiguration="ClientCredBehavior" name="WSHttpBinding_IServiceExample"> <identity> <userPrincipalName value="name@corp.contoso.com"/> </identity> </endpoint>Exécutez le service auto-hébergé sous le compte System ou NetworkService. Vous pouvez exécuter cette commande pour créer une fenêtre de commande sous le compte système :
at 12:36 /interactive "cmd.exe"Hébergez le service sous Internet Information Services (IIS), qui, par défaut, utilise le compte de nom de principal de service (SPN).
Inscrivez un nouveau SPN auprès du domaine à l’aide de SetSPN. Pour ce faire, vous devez être administrateur de domaine.
Pour plus d’informations sur le protocole Kerberos, consultez Concepts de sécurité utilisés dans WCF et :
Lorsque je lève une FaultException<Exception> où le type est une exception, je reçois toujours un type FaultException général sur le client, et non le type générique. Que se passe-t-il?
Il est vivement recommandé de créer votre propre type de données d’erreur personnalisé et de l'utiliser comme type de détail dans votre contrat de faute. La raison est que l’utilisation de types d’exceptions fournis par le système :
Crée une dépendance de type qui supprime l’une des plus grandes forces des applications orientées service.
On ne peut pas compter sur des exceptions qui se sérialisent de manière standard. Certains, comme SecurityExceptionceux-ci, peuvent ne pas être sérialisables du tout.
Expose les détails de l’implémentation interne aux clients. Pour plus d’informations, consultez Spécification et gestion des erreurs dans les contrats et les services.
Toutefois, si vous déboguez une application, vous pouvez sérialiser les informations d’exception et les retourner au client à l’aide de la ServiceDebugBehavior classe.
Il semble que les opérations unidirectionnelles et de demande-réponse ont à peu près la même vitesse de retour lorsque la réponse ne contient aucune donnée. Que se passe-t-il ?
Spécifier qu’une opération est une seule façon signifie que le contrat d’opération accepte un message d’entrée et ne retourne pas de message de sortie. Dans WCF, tous les appels clients sont renvoyés lorsque les données sortantes ont été écrites sur le fil ou qu’une exception est levée. Les opérations monodirectionnelles fonctionnent de la même façon et elles peuvent lever si le service ne peut pas être localisé ou bloquer si le service n'est pas préparé à accepter les données du réseau. En règle générale, dans WCF, les appels unidirectionnel retournent au client plus rapidement que la requête-réponse ; mais toute condition qui ralentit l’envoi des données sortantes sur le réseau ralentit les opérations unidirectionnelles ainsi que les opérations de demande-réponse. Pour plus d’informations, consultez One-Way Services et accès aux services à l’aide d’un client WCF.
J’utilise un certificat X.509 avec mon service et j’obtiens un System.Security.Cryptography.CryptographicException. Que se passe-t-il?
Cela se produit généralement après la modification du compte d’utilisateur sous lequel le processus de travail IIS s’exécute. Par exemple, dans Windows XP, si vous modifiez le compte d’utilisateur par défaut sous lequel le Aspnet_wp.exe s’exécute depuis ASPNET vers un compte d’utilisateur personnalisé, vous pouvez voir cette erreur. Si vous utilisez une clé privée, le processus qui l’utilise doit disposer des autorisations nécessaires pour accéder au fichier stockant cette clé.
Si c’est le cas, vous devez accorder des privilèges d’accès en lecture au compte du processus pour le fichier contenant la clé privée. Par exemple, si le processus de travail IIS s’exécute sous le compte Bob, vous devez accorder à Bob un accès en lecture au fichier contenant la clé privée.
Pour plus d’informations sur la façon de donner au compte d’utilisateur approprié l’accès au fichier qui contient la clé privée d’un certificat X.509 spécifique, consultez Guide pratique pour rendre les certificats X.509 accessibles à WCF.
J'ai remplacé les majuscules du premier paramètre d'une opération par des minuscules ; à présent, mon client lève une exception. Que se passe-t-il ?
Les valeurs des noms de paramètres dans la signature de l’opération font partie du contrat et respectent la casse. Utilisez l’attribut lorsque vous devez faire la System.ServiceModel.MessageParameterAttribute distinction entre le nom du paramètre local et les métadonnées qui décrivent l’opération pour les applications clientes.
J’utilise l’un de mes outils de suivi et j’obtiens une exception EndpointNotFoundException. Que se passe-t-il?
Si vous utilisez un outil de suivi qui n’est pas le mécanisme de suivi WCF fourni par le système et que vous recevez un EndpointNotFoundException indicateur indiquant qu’il existe une incompatibilité de filtre d’adresse, vous devez utiliser la ClientViaBehavior classe pour diriger les messages vers l’utilitaire de suivi et rediriger ces messages vers l’adresse du service. La ClientViaBehavior classe modifie l’en-tête Via d’adressage pour spécifier l’adresse réseau suivante séparément du récepteur final, indiquée par l’en-tête d’adressage To . Toutefois, lorsque vous effectuez cette opération, ne modifiez pas l’adresse du point de terminaison, qui est utilisée pour établir la To valeur.
L’exemple de code suivant montre un exemple de fichier de configuration client.
<endpoint
address="http://localhost:8000/MyServer/"
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IMyContract"
behaviorConfiguration="MyClient"
contract="IMyContract"
name="WSHttpBinding_IMyContract">
</endpoint>
<behaviors>
<endpointBehaviors>
<behavior name="MyClient">
<clientVia viaUri="http://localhost:8001/MyServer/"/>
</behavior>
</endpointBehaviors>
</behaviors>
Quelle est l’adresse de base ? Comment se rapporte-t-il à une adresse de point de terminaison ?
Une adresse de base est l’adresse racine d’une ServiceHost classe. Par défaut, si vous ajoutez une classe ServiceMetadataBehavior à votre configuration de service, le langage de description des services Web (WSDL) pour tous les points de terminaison publiés par l’hôte est récupéré à partir de l’adresse de base HTTP, plus toute adresse relative fournie au comportement des métadonnées configuré, plus « ?wsdl ». Si vous connaissez ASP.NET et IIS, l’adresse de base est équivalente au répertoire virtuel.
Partage d’un port entre un point de terminaison de service et un point de terminaison mex à l’aide de NetTcpBinding
Si vous spécifiez l’adresse de base d’un service en tant que net.tcp ://MyServer :8080/MyService et ajoutez les points de terminaison suivants :
<services>
<service name="Microsoft.Samples.NetTcp.CalculatorService">
<endpoint address="calcsvc" binding ="netTcpBinding" contract="Microsoft.Samples.NetTcp.ICalculator"/>
<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange" />
</service>
</services>
Et si vous modifiez l’un des paramètres NetTcpBinding, comme indiqué dans l’extrait de code de configuration suivant :
<bindings>
<netTcpBinding>
<binding closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" transactionFlow="false" transferMode="Buffered" transactionProtocol="OleTransactions" hostNameComparisonMode="StrongWildcard" listenBacklog="10" maxBufferPoolSize="524288" maxBufferSize="65536" maxConnections="11" maxReceivedMessageSize="65536">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384"/>
<reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
<security mode="Transport">
<transport clientCredentialType="Windows" protectionLevel="EncryptAndSign"/>
</security>
</binding>
</netTcpBinding>
</bindings>
Vous verrez une erreur comme suit : Exception non gérée : System.ServiceModel.AddressAlreadyInUseException : Il existe déjà un écouteur sur le point de terminaison IP 0.0.0.0.0:9000 Vous pouvez contourner cette erreur en spécifiant une URL complète avec un autre port pour le point de terminaison MEX, comme indiqué dans l’extrait de code de configuration suivant :
<services>
<service name="Microsoft.Samples.NetTcp.CalculatorService">
<endpoint address="calcsvc" binding ="netTcpBinding" contract="Microsoft.Samples.NetTcp.ICalculator"/>
<endpoint address="net.tcp://localhost:9001/servicemodelsamples/mex" binding="mexTcpBinding" contract="IMetadataExchange" />
</service>
</services>
Lors de l’appel d’une application HTTP web WCF à partir d’une application SOAP WCF, le service renvoie l’erreur suivante : 405, méthode non autorisée
L'appel d'une application WCF HTTP web (un service qui utilise WebHttpBinding et WebHttpBehavior) à partir d'un service WCF peut générer l'exception suivante : Unhandled Exception: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: The remote server returned an unexpected response: (405) Method Not Allowed. Cette exception se produit parce que WCF remplace l'élément sortant OperationContext par le service entrant OperationContext. Pour résoudre ce problème, créez un OperationContextScope à l'intérieur de l'opération de service HTTP Web du WCF. Par exemple:
public string Echo(string input)
{
using (new OperationContextScope(this.InnerChannel))
{
return base.Channel.Echo(input);
}
}