Je suis le développeur d'un service WCF. Mes clients testés fonctionnent très bien avec cela. Mais quand il s'agit de vrais clients (en utilisant le même proxy client), il échoue. Le même service WCF fonctionne avec NetCPPLINDING, cette erreur ne se produit qu'avec NetNamedpipeLinding, même avec ConcurrencyMode = ConcurrencyMode.Single
Voici l'exception
Il n'y avait pas d'écoute de crise finale à Net.Pipe: // localhost / mservice cela pourrait accepter le message. C'est souvent causé par une adresse incorrecte ou action du savon. Voir Infantaxception, si présent, pour plus de détails.
trace de pile de serveur: à
System.ServiceModel.Channel.PiPeconnectionInitiative.getPIPENNAME (URI URI) à System.ServiceModel.chancedPIPeconnectionPoolReMedic.NameDpiPeconnectionPiscine.getpoolkey (EndpointAddress adresse, uri via) à System.servicemodel.channelages.communicationpool`2.takeconnection (EndpointAddress Adresse, URI via, Timespan Timeout, Tkey & clé) à System.ServiceModel.Channel.ConnectionPoolHelper.establishConnection (Timespan délai d'attente) à System.servicemodel.channel.ClientFramingDuppexSessionChannel.onopen (Timespan délai d'attente) à System.servicemodel.channelels.communicationObject.open (Timespan délai d'attente) à Système.servicemodel.channel.servicechannel.onopen (Timespan délai d'attente) à System.servicemodel.channelels.communicationObject.open (Timespan délai d'attente) à System.ServiceModel.Channel.ServicechanNel.CallonCemanager.Callonce (Timespan Timeout, Calloncemanager Cascade)
à System.servicemodel.channelels.servicechannel.entureOpened (Timespan délai d'attente) à System.Servicemodel.Channel.ServicechanNel.Call (String Action, Boolean Owway, Commande de proxyopérationRunale, Objet [] INS, Object [] Outs, Timespan délai d'attente) à System.servicemodel.channelels.servicechannelProxy.invokeservice (imethodcallMessage MéthodeCall, ProxyOperationRuntime opération) à System.ServiceModel.channel.ServicechanNelProxy.invoke (IMESSAGE Message)Exception Rethrown à [0]: à Système.runtime.remoting.proxies.realproxy.HandlerturturnMessage (IMESSAGE REQMSG, IMESSAGE RETMSG) à System.runtime.remoting.proxies.realproxy.privateInvoke (MessageData & msgdata, type int32) à
Exception interne
PIPEEXception: "The Tuyal EndPoint" Net.Pipe: // localhost / myservice 'n'a pas pu être trouvé sur votre machine locale. "
3 Réponses :
Le noeud final utilisé par votre client doit correspondre à un noeud final exposé par votre service WCF. Cela signifie que l'adresse / la liaison / contractuel du point d'extrémité de client spécifié doit exactement correspondre à l'adresse / liaison / contrat TUPLE d'un point final exposé par votre service WCF. Si vous utilisez l'approche App.config, assurez-vous que tout est orthographié correctement dans les fichiers de service WCF et de configuration du client. Si vous ajoutez les points de terminaison par programme, assurez-vous que vous n'avez rien orthographié dans le code.
Merci d'avoir posté cela, mais ce n'était pas mon cas.
Le login compte-t-il dans ce cas? Si un processus appartenant à un utilisateur peut accéder à des tuyaux nommés créés par un autre utilisateur?
Je ne sais pas avec certitude. J'utilise des pipes nommées pour communiquer à partir de mon client de connexion local à mon service Windows System-Compte sur la même machine sans problème.
@Jader: Nul doute que votre besoin de réponse est parti depuis longtemps, mais pour l'amour de la postérité et dans l'espoir que cela peut aider les autres, j'ai posté une réponse que je pense explique ce que vous avez vu.
La trace de la pile montre que la pile de canaux WCF côté client a échoué lors de la tentative de dérivation de l'URL de service le nom réel du tuyau nommé utilisé par le service. Le service publie le nom du tuyau (qui est un GUID qui change chaque fois que le service redémarre) en plaçant une petite structure dans une section mémoire partagée nommée contenant le GUID comme l'un de ses champs. Le nom utilisé pour la section mémoire partagée est dérivé de l'URL de service en appliquant un algorithme compilé à la fois au code WCF côté serveur et côté client pour le NetNamedpipeLinding.
L'exception rapportée dans la question signifie vraiment que d'avoir appliqué l'algorithme à l'URL de service pour proposer un nom, le code côté client n'a pas pu ouvrir une poignée à une section de mémoire partagée de ce nom. Cela peut signifier que le message d'exception indique qu'il n'y a pas d'écoute de service sur l'URL de service utilisé pour dériver le nom. Mais cela peut plutôt dire que la section mémoire est là, de même que le service, mais le code côté client ne s'exécute pas dans un contexte de sécurité qui lui permet d'accéder à la mémoire partagée.
sur les plates-formes Windows avant Vista, il est assez improbable qu'un client de la WCF n'ait jamais manqué aux autorisations de sécurité pour ouvrir la mémoire partagée, lisez le guid de nom de la tuyauterie, puis connectez-vous avec succès au tuyau du service. Mais sur Vista et les plates-formes ultérieures, il existe de nouveaux mécanismes de sécurité qui en font un scénario d'échec beaucoup plus commun.
Vista a introduit un concept d'espaces de noms différents pour Nommé Kernel Objects: il existe un espace de noms global (machine à large) et un espace de noms privé pour chaque session de connexion. Le code client NetNamedpipeLinding essaiera les deux espaces de noms lorsque vous recherchez la section mémoire partagée qui annonce le nom du tuyau. Si le serveur a créé la mémoire partagée à l'aide d'un nom global ou si le service et le client s'exécutent dans la même session de connexion, le client trouvera ce qu'il recherche. Si, cependant, le service ne peut pas créer d'objet dans l'espace de noms global (il essaie toujours de le faire d'abord), il sera revenu à la création de l'espace de noms de session privé, puis seuls les clients exécutés dans la même session pourront voir ce. La création d'objets de noyau de noms globaux nécessite un privilège spécial dans Vista et des plates-formes ultérieures, qui ne disposent généralement que des processus de service Windows et des applications en cours d'exécution "en tant qu'administrateur". Un piège commun est d'essayer de créer un client dans un service Windows tente de se connecter à un service NetNamedpipe WCF hébergé dans une application exécutée dans la session d'utilisateur interactive.
Le mécanisme d'intégrité obligatoire Vista peut également empêcher un client putatif de connexion à un service de NetNamedPippePippePippePippePippePippePipIPIPED de WCF, si le code client est exécuté dans un contexte d'intégrité inférieur (par exemple, un plug-in de navigateur) que le code hébergeant le service.
J'imagine que les symptômes signalés dans la question, avec des clients testés travaillant, mais que les clients réels ne fonctionnent pas, sont presque certainement causés par le contexte de sécurité des vrais clients incompatibles avec celle de l'hôte de service, pour l'une ou l'autre de ces raisons.
C'était la réponse exacte pour mon problème réel. Pour le compte rendu, je devais juste démarrer Visual Studio avec une autorisation administrative pour le faire fonctionner. En outre, le démarrage de la clientèle et du serveur à partir d'une invite de commande était une solution. Merci beaucoup pour la réponse détaillée!
Oui, mais si je ne veux pas l'exécuter comme administrateur? Mes processus sont sur la même session.
@ Chris-Dickson merci pour une réponse descriptive. Je peux confirmer que NetNamedpipeLinding ne fonctionne pas lorsque le serveur est exécuté à l'intérieur de l'espace de noms local et que le client tente de se connecter à partir de l'utilisateur système via l'espace de noms global. Mais je ne comprends pas une chose. Lorsque j'essaie d'utiliser NamedpiPececLientstream et NamedPipeserverStream et essayez de reproduire le scénario dans lequel le serveur est exécuté à partir d'un utilisateur non administrateur et de client est exécuté à partir de l'utilisateur système, puis ils se connectent correctement. Comment est-ce possible? Quelle est la différence entre NetNamedpipeLinding et NamedPipeStreams? Merci!
Une autre possibilité de résoudre ce problème de racine si vous recherchez cette erreur et sur ce message - si vous obtenez une erreur qu'aucun Le service ne semble pas être activé ou démarré dans certains scénarios, en particulier lors du déploiement d'un serveur distant qui pourrait ne pas avoir de nombreux outils de développement installés qui utilisent activement ces services. Démarrer le service corrigé le problème. net.Pipe est trouvé sur votre URL (c.-à-d. http: // localhost: 1234 / myservice / etc / ) Assurez-vous que que l'adaptateur d'écoute net.Pipe Windows Service est commencé . (J'ai aussi démarré Net.TCP ADAPTER)
C'est exactement ce que mon problème était ... Mon site a fonctionné correctement, puis soudainement arrêté. A commencé le service et tout est bien couru bien après.
Alléluia! Pour les futurs lecteurs ::: Pour installer ce service Windows, je crois que le chemin est ::: "Tourner les fonctionnalités de Windows sur ou désactivé" /// ".NET Framework 4.6 Services avancés" /// "Services WCF" //// "Activation de la pipe nommée" (si ce service n'apparaît pas dans votre liste de services Windows-Services, vous devez l'installer). Merci!
Juste pour être clair - votre client et votre service sont sur la même machine? Si non nommé tuyaux ne fonctionnera pas ...
@Murph, oui ils sont sur la même machine.
Avez-vous réussi à résoudre ce problème? J'ai le même problème.
@TSURY Veuillez noter que les tuyaux nommés créés par une session élevée ne sont pas visibles pour les utilisateurs normaux et inversement. C'était la question pour moi la plupart du temps. J'exécutais une application en tant qu'utilisateur normal et une autre "comme administrateur"