Ich bin Entwickler eines WCF-Dienstes. Meine Testkunden arbeiten sehr gut damit. Wenn es jedoch um echte Clients geht (die denselben Client-Proxy verwenden), schlägt es fehl. Derselbe WCF-Dienst funktioniert mit netTcpBinding. Dieser Fehler tritt nur bei netNamedPipeBinding auf, selbst bei ConcurrencyMode = ConcurrencyMode.Single
Hier ist die Ausnahme
Es gab keinen Endpunkt, auf den gewartet wurde net.pipe: // localhost / MeinService Das könnte die Nachricht akzeptieren. Das ist oft durch eine falsche Adresse verursacht oder SOAP-Aktion. Siehe InnerException, wenn Gegenwart, für weitere Details.
Server-Stack-Ablaufverfolgung: bei
System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName (Uri uri) bei System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey (EndpointAddress Adresse, Uri via) an System.ServiceModel.Channels.CommunicationPool'2.TakeConnection (EndpointAddress Adresse, Uri über, TimeSpan Timeout, TKey & amp; Schlüssel) um System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection (TimeSpan Timeout) um System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen (TimeSpan Timeout) um System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannel.OnOpen (TimeSpan Timeout) um System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce (TimeSpan Timeout, CallOnceManager-Kaskade)
beim System.ServiceModel.Channels.ServiceChannel.EnsureOpened (TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannel.Call (Zeichenfolge Aktion, Boolesche Einbahnstraße, ProxyOperationRuntime-Operation, Object [] ins, Object [] outs, TimeSpan Timeout) um System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (IMethodCallMessage methodCall, ProxyOperationRuntime Operation) bei System.ServiceModel.Channels.ServiceChannelProxy.Invoke (IMessage Nachricht)Ausnahme erneut bei [0]: um System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg) bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & amp; msgData, Int32 type) bei
Innere Ausnahme
PipeException: "Der Pipe-Endpunkt 'net.pipe: // localhost / MyService' wurde auf Ihrem lokalen Rechner nicht gefunden."
Der Stack-Trace zeigt, dass der clientseitige WCF-Channel-Stack fehlgeschlagen ist, wenn versucht wurde, den tatsächlichen Namen der Named Pipe, die vom Service verwendet wird, von der Service-URL abzuleiten. Der Dienst veröffentlicht den Pipe-Namen (eine GUID, die bei jedem Neustart des Diensts geändert wird), indem er eine kleine Struktur in Ein benannter gemeinsamer Speicherbereich , der die GUID als eines seiner Felder enthält. Der für den Shared Memory-Abschnitt verwendete Name wird von der Service-URL abgeleitet, indem ein Algorithmus angewendet wird, der sowohl in den serverseitigen als auch den clientseitigen WCF-Code für NetNamedPipeBinding kompiliert wird.
Die in der Frage gemeldete Ausnahme bedeutet, dass der clientseitige Code nach dem Anwenden des Algorithmus auf die Dienst-URL, um einen Namen zu erhalten, kein Handle für einen freigegebenen Speicherabschnitt dieses Namens öffnen konnte. Dies kann bedeuten, dass, wie die Ausnahmebedingungsnachricht besagt, kein Dienst auf die Dienst-URL wartet, die zum Ableiten des Namens verwendet wird. Es kann aber auch bedeuten, dass der Speicherbereich vorhanden ist und auch der Dienst, aber der clientseitige Code wird nicht in einem Sicherheitskontext ausgeführt, der den Zugriff auf den gemeinsamen Speicher ermöglicht.
Auf Windows-Plattformen vor Vista ist es ziemlich unwahrscheinlich, dass einem WCF-Client jemals die Sicherheitsberechtigungen zum Öffnen des gemeinsam genutzten Speichers fehlten, lesen Sie die GUID des Pipe-Namens aus und stellen Sie eine erfolgreiche Verbindung mit dem Service-Pipe her. Aber auf Vista und späteren Plattformen gibt es neue Sicherheitsmechanismen, die dies zu einem häufigeren Fehlerszenario machen.
Vista hat ein Konzept verschiedener Namespaces für benannte Kernel-Objekte eingeführt: Es gibt einen globalen (maschinenweiten) Namespace und einen privaten Namespace für jede Anmeldesitzung. Der NetNamedPipeBinding-Client-Code versucht beide Namespaces, wenn er nach dem Shared-Memory-Abschnitt sucht, der den Pipe-Namen anzeigt. Wenn der Server den gemeinsam genutzten Speicher mit einem globalen Namen erstellt hat oder wenn der Dienst und der Client in derselben Anmeldesitzung ausgeführt werden, wird der Client finden, wonach er sucht. Wenn der Dienst jedoch kein Objekt im Global-Namespace erstellen kann (er versucht dies immer zuerst), wird er auf den Namespace für die private Sitzung zurückgreifen, und nur die Clients, die in derselben Sitzung ausgeführt werden, können sehen es. Das Erstellen globaler Namespace-Kernel-Objekte erfordert eine spezielle Berechtigung in Vista- und späteren Plattformen, die in der Regel nur Windows-Dienstprozesse und -Anwendungen haben, auf denen "Als Administrator" ausgeführt wird. Ein häufiger Fehler ist es, einen Client in einem Windows-Dienst zu erstellen, der versucht, eine Verbindung mit einem WCF NetNamedPipe-Dienst herzustellen, der in einer Anwendung gehostet wird, die in der interaktiven Benutzersitzung ausgeführt wird.
Der Mandatory Integrity Mechanism von Vista kann auch verhindern, dass sich ein potenzieller Client mit einem WCF NetNamedPipeBinding-Dienst verbindet, wenn der Client-Code in einem niedrigeren Integritätskontext (z. B. einem Browser-Plug-in) als der Code ausgeführt wird, der den Dienst hostet.
>Ich würde mir vorstellen, dass die in der Frage gemeldeten Symptome, bei denen Test-Clients funktionieren, aber echte Clients nicht funktionieren, fast sicher durch den Sicherheitskontext der echten Clients verursacht werden, der mit dem des Service-Hosts für den einen oder anderen nicht übereinstimmt diese Gründe.
Eine weitere Möglichkeit, dieses Root-Problem zu beheben, wenn Sie nach diesem Fehler suchen und auf diesen Beitrag stoßen - wenn Sie einen Fehler bekommen, dass keine net.pipe -Adresse in Ihrer URL gefunden werden kann (zB http://localhost:1234/MyService/etc/ ) stellen Sie sicher dass der Net.Pipe Listener Adapter Windows-Dienst gestartet ist. (Ich startete auch Net.Tcp Listener Adapter)
Der Dienst scheint in einigen Szenarien nicht aktiviert oder gestartet zu sein, insbesondere nicht bei der Bereitstellung auf einem Remote-Server, auf dem möglicherweise nicht viele Entwicklungstools installiert waren, die diese Dienste aktiv nutzen. Durch das Starten des Dienstes wurde das Problem behoben.
Der von Ihrem Client verwendete Endpunkt muss einem Endpunkt entsprechen, der von Ihrem WCF-Dienst bereitgestellt wurde. Dies bedeutet, dass das Adress- / Bindungs- / Vertragstupel des angegebenen Clientendpunkts genau mit dem Adress- / Bindungs- / Vertragstupel eines Endpunkts übereinstimmen muss, der von Ihrem WCF-Dienst bereitgestellt wurde. Stellen Sie bei Verwendung der app.config-Methode sicher, dass sowohl in den WCF-Dienst- als auch in den Clientkonfigurationsdateien alles korrekt geschrieben ist. Wenn Sie die Endpunkte programmgesteuert hinzufügen, stellen Sie sicher, dass Sie nichts im Code falsch geschrieben haben.
Tags und Links wcf .net exception netnamedpipebinding