Именованный канал не найден при использовании WCF netNamedPipeBinding - PullRequest
8 голосов
/ 04 декабря 2009

Я разработчик сервиса WCF. Мои тестовые клиенты работают с ним очень хорошо. Но когда речь идет о реальных клиентах (использующих один и тот же клиентский прокси-сервер), происходит сбой. Тот же сервис WCF работает с netTcpBinding, эта ошибка возникает только с netNamedPipeBinding, даже с ConcurrencyMode = ConcurrencyMode.Single

Вот исключение

Конечная точка не прослушивала net.pipe: // локальный / MyService что может принять сообщение. Это часто вызвано неправильным адресом или действие SOAP. Смотрите InnerException, если настоящее время, для более подробной информации.

Трассировка стека серверов: в

System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName (Uri ури) в System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey (EndpointAddress адрес Uri via) в System.ServiceModel.Channels.CommunicationPool`2.TakeConnection (EndpointAddress адрес, Uri via, TimeSpan timeout, TKey & ключ) в System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection (TimeSpan тайм-аут) в System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen (TimeSpan тайм-аут) в System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan тайм-аут) в System.ServiceModel.Channels.ServiceChannel.OnOpen (TimeSpan тайм-аут) в System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan тайм-аут) в System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce (TimeSpan тайм-аут, каскад CallOnceManager)
в System.ServiceModel.Channels.ServiceChannel.EnsureOpened (TimeSpan тайм-аут) в System.ServiceModel.Channels.ServiceChannel.Call (String действие, логическое одностороннее, Операция ProxyOperationRuntime, Object [] ins, Object [] outs, TimeSpan тайм-аут) в System.ServiceModel.Channels.ServiceChannelProxy.InvokeService (IMethodCallMessage methodCall, ProxyOperationRuntime операция) в System.ServiceModel.Channels.ServiceChannelProxy.Invoke (Шеззаде сообщение)

Исключение переброшено в [0]: в System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (Шеззаде reqMsg, IMessage retMsg) в System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & msgData, тип Int32) на

Внутреннее исключение

PipeException: "Конечная точка канала 'net.pipe: // localhost / MyService' не найдена на вашем локальном компьютере."

Ответы [ 3 ]

21 голосов
/ 30 июня 2012

Трассировка стека показывает, что на стеке клиентского канала WCF произошла ошибка при попытке извлечь из URL-адреса службы фактическое имя именованного канала, используемого службой. Служба публикует имя канала (который представляет собой GUID, который изменяется при каждом перезапуске службы), помещая небольшую структуру в именованный раздел совместно используемой памяти , который содержит GUID в качестве одного из своих полей. Имя, используемое для раздела с общей памятью, получено из URL-адреса службы путем применения алгоритма, который компилируется в код WCF на стороне сервера и на стороне клиента для NetNamedPipeBinding.

Исключение, о котором сообщалось в вопросе, действительно означает, что после применения алгоритма к URL-адресу службы для получения имени клиентский код не смог открыть дескриптор раздела с общей памятью этого имени. Это может означать, как говорится в сообщении об исключении, что служба не прослушивает URL-адрес службы, используемый для получения имени. Но вместо этого это может означать, что раздел памяти существует, как и служба, но код на стороне клиента не выполняется в контексте безопасности, который позволяет ему получить доступ к общей памяти.

На платформах Windows до Vista весьма маловероятно, что клиенту WCF когда-либо не хватало бы разрешений безопасности для открытия общей памяти, считывания с нее идентификатора GUID канала и успешного подключения к каналу службы. Но на Vista и более поздних платформах есть новые механизмы безопасности, которые делают этот сценарий гораздо более распространенным сбоем.

Vista представила концепцию различных пространств имен для именованных объектов ядра: для каждого сеанса входа в систему существует глобальное (общесистемное) пространство имен и личное пространство имен. Клиентский код NetNamedPipeBinding будет пытаться использовать оба пространства имен при поиске раздела общей памяти, в котором объявлено имя канала. Если сервер создал общую память, используя глобальное имя, или если служба и клиент работают в одном сеансе входа в систему, клиент найдет то, что ищет. Однако, если сервис не может создать объект в глобальном пространстве имен (он всегда пытается это сделать первым), то он обратится к созданию в нем пространства имен частного сеанса, и тогда только клиенты, работающие в одном сеансе, смогут видеть Это. Создание объектов ядра глобального пространства имен требует специальных привилегий в Vista и более поздних платформах, которые обычно имеют только процессы и приложения Windows Service, работающие под именем «Администратор». Распространенной ошибкой является попытка создать клиент в службе Windows, пытающийся подключиться к службе WCF NetNamedPipe, размещенной в приложении, запущенном в интерактивном сеансе пользователя.

Механизм обязательной целостности Vista также может предотвращать подключение предполагаемого клиента к службе WCF NetNamedPipeBinding, если код клиента выполняется в контексте более низкой целостности (например, плагин браузера), чем код, на котором размещается служба.

Я полагаю, что описанные в этом вопросе симптомы, когда тестовые клиенты работают, но реальные клиенты не работают, почти наверняка вызваны тем, что контекст безопасности реальных клиентов несовместим с контекстом хоста службы для одного или другого из эти причины.

5 голосов
/ 29 марта 2013

Еще одна возможность исправить эту корневую проблему, если вы ищете эту ошибку и сталкиваетесь с этим сообщением - если вы получаете сообщение об ошибке, что по вашему адресу не найден адрес net.pipe (т. Е. http://localhost:1234/MyService/etc/) , убедитесь, что что Адаптер прослушивателя Net.Pipe Служба Windows запущена .(Я также запустил адаптер прослушивателя Net.Tcp)

Похоже, что служба не включена или не запущена в некоторых сценариях, особенно при развертывании на удаленном сервере, на котором не было установлено множество инструментов разработки,активно пользоваться этими услугами.Запуск службы исправил проблему.

3 голосов
/ 04 декабря 2009

Конечная точка, используемая вашим клиентом, должна соответствовать конечной точке, предоставляемой вашей службой WCF. Это означает, что кортеж адреса / привязки / контракта указанной конечной точки клиента должен точно соответствовать кортежу адреса / привязки / контракта конечной точки, предоставляемой вашей службой WCF. Если вы используете подход app.config, убедитесь, что все написано правильно как в сервисе WCF, так и в клиентских конфигурационных файлах. Если вы добавляете конечные точки программно, убедитесь, что в коде ничего не написано неправильно.

...