Ответ 1
Проверяя несколько вариантов, я, наконец, решил это, используя
Договор = "IMySOAPWebService"
то есть. без полного пространства имен в конфиге. По какой-то причине полное имя не удалось правильно разрешить
Я добавил прокси к веб-сервису в решение VS2008/.NET 3.5. При построении клиента .NET выдает эту ошибку:
Не удалось найти конечную точку по умолчанию элемент, который ссылается на контракт "IMySOAPWebService" в сервисе образную конфигурацию клиента. Это может быть потому, что нет файл конфигурации был найден для вашего приложения или потому, что нет конечной точки элемент, соответствующий этому контракту, может можно найти в клиентском элементе
Поиск этой ошибки говорит мне использовать полное пространство имен в контракте. Здесь мой app.config с полным пространством имен:
<client>
<endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
binding="basicHttpBinding" bindingConfiguration="IMySOAPWebServicebinding"
contract="Fusion.DataExchange.Workflows.IMySOAPWebService" name="IMySOAPWebServicePort" />
</client>
Я использую XP local (я упоминаю об этом, потому что в ряде хитов Google упоминается win2k3) Файл app.config копируется в app.exe.config, так что это также не проблема.
Любые подсказки?
Проверяя несколько вариантов, я, наконец, решил это, используя
Договор = "IMySOAPWebService"
то есть. без полного пространства имен в конфиге. По какой-то причине полное имя не удалось правильно разрешить
"Эта ошибка может возникнуть, если вы вызываете службу в библиотеке классов и вызываете библиотеку классов из другого проекта."
В этом случае вам нужно будет включить настройки конфигурации WS в основные проекты app.config, если это winapp или web.config, если это веб-приложение. Это способ пойти даже с PRISM и WPF/Silverlight.
Я решил это (я думаю, как могли предположить другие), создав сами экземпляры адреса привязки и конечных точек - потому что я не хотел добавлять новые настройки в файлы конфигурации (это замена некоторой существующей библиотеки код, который широко используется, и ранее использовался более ранний справочник по веб-сервисам и т.д.), и поэтому я хотел иметь возможность отказаться от него, не добавляя новые настройки конфигурации везде.
var remoteAddress = new System.ServiceModel.EndpointAddress(_webServiceUrl);
using (var productService = new ProductClient(new System.ServiceModel.BasicHttpBinding(), remoteAddress))
{
//set timeout
productService.Endpoint.Binding.SendTimeout = new TimeSpan(0,0,0,_webServiceTimeout);
//call web service method
productResponse = productService.GetProducts();
}
Edit
Если вы используете https, вам нужно использовать BasicHttpsBinding
, а не BasicHttpBinding
.
У меня была такая же проблема. Оказывается, для web REFERENCE вам нужно указать URL-адрес в качестве первого параметра для конструктора:
new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");
Для нового стиля web SERVICE REFERENCE вы должны указать имя, которое относится к записи конечной точки в конфигурации:
new WebService.WebServiceSoapClient("WebServiceEndpoint");
С соответствующей записью в Web.config
или App.config
:
<client>
<endpoint address="http://myservice.com/moo.aspx"
binding="basicHttpBinding"
bindingConfiguration="WebService"
contract="WebService.WebServiceSoap"
name="WebServiceEndpoint" />
</client>
</system.serviceModel>
Довольно чертовски трудно удалить туннельное видение "он работал в старой программе"...
У меня была такая ситуация, когда у меня была
Теперь у проекта Consumer был все связанный параметр конфигурации в теге <system.serviceModel>
моего app.config, он все еще выдавал ту же ошибку, что и выше.
Все, что я сделал, добавляет тот же тег <system.serviceModel>
к моему основному файлу app.config проекта, и, наконец, нам было хорошо идти.
Реальная проблема, насколько это было в моем случае, это чтение неправильного файла конфигурации. Вместо потребительского app.config он ссылался на основную конфигурацию proj. мне потребовалось два часа, чтобы понять это.
Это меня сбило с ума.
Я использую Silverlight 3 Prism (CAB) с WCF
Когда я вызываю службу WCF в модуле Prism, я получаю ту же ошибку:
Не удалось найти элемент конечной точки по умолчанию, который ссылается на контракт "IMyService" в разделе конфигурирования клиентской модели сервиса. Эта может быть, потому что для вашего приложения не найден файл конфигурации или потому, что элемент конечной точки, соответствующий этому контракту, не найден в клиентском элементе
Оказывается, что он ищет в файле Shell.xap файл ServiceReferences.ClientConfig, а не в файле ServiceReferences.ClientConfig модуля. Я добавил свою конечную точку и привязку к существующему файлу ServiceReferences.ClientConfig в приложении Silverlight Shell (он называет его собственными службами WCF).
Затем мне пришлось перестроить приложение Shell, чтобы сгенерировать новый .xap файл для моей клиентской папки веб-проекта.
Теперь эта строка кода работает:
MyServiceClient myService = new MyServiceClient();
"Эта ошибка может возникнуть, если вы вызываете службу в библиотеке классов и вызываете библиотеку классов из другого проекта."
"В этом случае вам нужно будет включить настройки конфигурации WS в основные проекты app.config, если это winapp или web.config, если это веб-приложение. Это способ пойти даже с PRISM и WPF/Silverlight."
Да, но если вы не можете изменить основной проект (например, Orchard CMS), вы можете сохранить конфигурацию службы WCF в своем проекте.
Вам необходимо создать сервис-помощник с методом генерации клиента:
public static class ServiceClientHelper
{
public static T GetClient<T>(string moduleName) where T : IClientChannel
{
var channelType = typeof(T);
var contractType = channelType.GetInterfaces().First(i => i.Namespace == channelType.Namespace);
var contractAttribute = contractType.GetCustomAttributes(typeof(ServiceContractAttribute), false).First() as ServiceContractAttribute;
if (contractAttribute == null)
throw new Exception("contractAttribute not configured");
//path to your lib app.config (mark as "Copy Always" in properties)
var configPath = HostingEnvironment.MapPath(String.Format("~/Modules/{0}/bin/{0}.dll.config", moduleName));
var configuration = ConfigurationManager.OpenMappedExeConfiguration(new ExeConfigurationFileMap { ExeConfigFilename = configPath }, ConfigurationUserLevel.None);
var serviceModelSectionGroup = ServiceModelSectionGroup.GetSectionGroup(configuration);
if (serviceModelSectionGroup == null)
throw new Exception("serviceModelSectionGroup not configured");
var endpoint = serviceModelSectionGroup.Client.Endpoints.OfType<ChannelEndpointElement>().First(e => e.Contract == contractAttribute.ConfigurationName);
var channelFactory = new ConfigurationChannelFactory<T>(endpoint.Name, configuration, null);
var client = channelFactory.CreateChannel();
return client;
}
}
и используйте его:
using (var client = ServiceClientHelper.GetClient<IDefaultNameServiceChannel>(yourLibName)) {
... get data from service ...
}
Подробнее см. в этой статье.
Я получал эту ошибку в приложении ASP.NET, где WCF-служба была добавлена в библиотеку классов, которая добавляется в приложение ASP.NET в качестве файла .dll, на который указан .dll в папке bin. Чтобы устранить эту ошибку, настройки конфигурации в файле app.config в библиотеке классов, ссылающиеся на службу WCF, необходимо скопировать в настройки web.config для сайта/приложения ASP.NET.
Я нашел (а также копирование в клиентский интерфейс UI App.config, поскольку я использовал интерфейс библиотеки классов) мне пришлось префикс имени привязки с именем Service Reference (my ServiceReference
в ниже).
например:.
<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISchedulerService"
contract="ServiceReference.ISchedulerService"
name="BasicHttpBinding_ISchedulerService" />
вместо созданного по умолчанию:
<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISchedulerService"
contract="ISchedulerService"
name="BasicHttpBinding_ISchedulerService" />
У меня была та же проблема, но изменение пространства имен контрактов для меня не работало. Поэтому я попробовал веб-ссылку типа .Net 2 вместо справочной ссылки .Net 3.5. Это сработало.
Чтобы использовать веб-ссылку в Visual Studio 2008, нажмите "Добавить ссылку на службу", затем нажмите "Дополнительно", когда появится диалоговое окно. В этом случае вы найдете вариант, который позволит вам использовать веб-ссылку вместо ссылки на службу.
Тестирование проблемы с небиблиотечным приложением, которое потребляет услугу, может вызвать эту проблему.
Информация, внесенная другими пользователями, является основной причиной этого. Если вы пытаетесь написать автоматические тестовые примеры, и тестируемый модуль фактически вызовет интерфейс службы, вам необходимо добавить ссылку на службу в тестовый проект. Это вкус приложения, использующего тип ошибки библиотеки. Я не сразу это понял, потому что мой код, который использует интерфейс, не находится в библиотеке. Однако, когда тест действительно выполняется, он будет запускаться из тестовой сборки, а не с тестируемой сборки.
Добавление ссылки на службу в проект unit test разрешило мою проблему.
У меня есть ситуация, которая в Unit test. Я скопировал файл app.config в проект unit test. Таким образом, проект unit test также содержит информацию о конечной точке.
Я столкнулся с этой проблемой один раз. Это связано с тем, что я все еще разрабатывал интерфейс, который использует службу WCF. Я настроил тестовое приложение и продолжил разработку. Затем в процессе разработки я изменил некоторые пространства имен служб. Поэтому я дважды проверял "system.serviceModel → client → endpoint → contract" в web.config для соответствия классу WCF. Тогда проблема решена.
Несколько ответов здесь затрагивают правильное решение, когда вы сталкиваетесь с неясно скрывающейся ошибкой ссылки на службу из файла класса: скопируйте конфигурационную информацию в свой app.config web.config вашего консольного или оконного приложения. Ни один из этих ответов не показывает вам, что копировать. Попробуем исправить это.
Вот то, что я скопировал из моего конфигурационного файла библиотеки классов, в конфигурационный файл консольного приложения, чтобы обойти эту сумасшедшую ошибку для службы, которую я пишу, называется "TranslationServiceOutbound".
В основном вы хотите все в разделе system.serviceModel:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ITranslationServiceOutbound" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://MyHostName/TranslationServiceOutbound/TranslationServiceOutbound.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ITranslationServiceOutbound"
contract="TranslationService.ITranslationServiceOutbound" name="BasicHttpBinding_ITranslationServiceOutbound" />
</client>
Пространство имен в вашем config должно отражать остальную часть пути пространства имен после вашего пространства имен клиентов по умолчанию (как это задано в свойствах проекта). Основываясь на вашем ответе, я предполагаю, что ваш клиент настроен на использование в пространстве имен Fusion.DataExchange.Workflows. Если вы переместили код клиента в другое пространство имен, вам нужно будет обновить конфигурацию, чтобы соответствовать оставшемуся пути пространства имен.
Просто для кого-то другого с той же проблемой; Я написал unit test для моего метода, который пытался подключиться к моей службе. С этим единственным исключением это случалось каждый раз - я понятия не имею, почему. Когда я запускал его из winform, он отлично работает.
Эта ошибка может возникнуть, если вы вызываете службу в библиотеке классов и вызываете библиотеку классов из другого проекта.
У меня есть одна и та же проблема. Я использовал службу WCF в библиотеке классов и вызывая библиотеку классов из окна Application project.but, я Forget Change <system.serviceModel>
В файле конфигурации приложения Windows. Проект аналогичен <system.serviceModel>
файла приложения Class Library.Config.
Решение: измените конфигурацию внешнего проекта так же, как и конфигурацию wcf библиотеки классов.
Если вы ссылаетесь на веб-службу в своей библиотеке классов, вам нужно скопировать app.config в приложение Windows или консольное приложение.
Решение: измените конфигурацию внешнего проекта так же, как и конфигурацию wcf библиотеки классов.
Работал для меня
Не помещайте строку объявления клиента службы в поле класса, вместо этого создайте экземпляр для каждого используемого метода. Поэтому проблема будет исправлена. Если вы создаете экземпляр клиента службы как поле класса, тогда возникает ошибка времени разработки!
Привет, я столкнулся с одной и той же проблемой, но лучшим решением является позволить .NET настроить вашу конфигурацию на стороне клиента. Я обнаружил это, когда добавляю ссылку на службу с строкой запроса http:/namespace/service.svc? Wsdl = wsdl0, она НЕ создает конечные точки конфигурации на стороне клиента. Но когда я удаляю wsdl-wsdl0 и использую только URL http:/namespace/service.svc, он создает конфигурацию конечной точки в файле конфигурации клиента. для короткого remoe "? WSDL = WSDL0".
В случае, если вы используете приложение WPF с использованием инфраструктуры PRISM, тогда конфигурация должна существовать в вашем проекте запуска (т.е. в проекте, где находится ваш загрузочный файл).
Кажется, существует несколько способов создания/устранения этой проблемы. Для меня продукт CRM, который я использую, был написан в собственном коде и способен вызвать мою .NET-библиотеку, но я нахожусь в информации о конфигурации, которая должна быть в/над основным приложением. Для меня CRM-приложение не является .NET, поэтому мне пришлось поместить его в файл machine.config(а не там, где я его хочу). Кроме того, поскольку моя компания использует Websense, мне пришлось нелегко даже добавить ссылку на службу из-за ошибки 407 Proxy Authentication Required, требующей модификации machine.cong.
Решение прокси:
Чтобы получить ссылку на службу WCF для работы, мне пришлось скопировать информацию из app.config моей DLL в основную конфигурацию приложения (но для меня это был machine.config). И мне также пришлось скопировать информацию о конечной точке в тот же файл. Как только я это сделал, он начал работать для меня.
Ok. Мой случай был немного разным, но, наконец, я нашел исправление для него: У меня есть Console.EXE → DLL → Вызов WS1 → DLL → Вызов WS2
У меня были как конфигурации сервисной модели WS1, так и WS2 в Console.EXE.config, как рекомендовано. - не решила проблему.
Но он все еще не работал, пока я не добавил WebReference от WS2 к WS1, а не только к DLL, которая фактически создает и вызывает прокси WS2.
У меня была такая же проблема
Я использовал настольное приложение и использовал веб-службу Global Weather
Я удалил ссылку на службу и добавил веб-ссылку, и проблема решена Спасибо
Решение для меня состояло в том, чтобы удалить имя конечной точки из атрибута Endpoint Name в клиенте web.config это позволило прокси использовать
ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");
только весь день работал. Кроме того, название контракта было неправильным, как только это исправление было на месте, хотя оно было неправильным, когда появилась первоначальная ошибка. Двойной, а затем тройной чек для имени подрядчика! attrib: Ian
Позвольте мне добавить еще одну вещь для поиска. (Ответ Тома Хейга уже намекает на него, но я хочу быть явным)
Мой файл web.config
имел следующие значения:
<protocolMapping>
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
Я уже использовал basicHttpsBinding для одной ссылки, но затем добавил новую ссылку, требующую basicHttpBinding (no s). Все, что мне нужно было сделать, это добавить это к моему protocolMapping
следующим образом:
<protocolMapping>
<add binding="basicHttpBinding" scheme="http" />
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
Как L.R. правильно указывает, это нужно определить в нужных местах. Для меня это означало один в моем проекте Unit Test app.config, а также один в основном проекте службы web.config.
У меня была эта ошибка, когда я ссылался на Контракт в элементе файла конфигурации без оператора глобальной области видимости.
то есть.
<endpoint contract="global::MyNamepsace.IMyContract" .../>
работает, но
<endpoint contract="MyNamepsace.IMyContract" .../>
дает сообщение "Не удалось найти элемент конечной точки по умолчанию, который ссылается на контракт".
Сборка, содержащая MyNamepsace.IMyContract, находится в другой сборке для основного приложения, поэтому это может объяснить необходимость использования разрешения глобальной области.
У меня такая же ошибка, и я попробовал кое-что, но не работал, чем заметил, что мой "контракт" был не таким же для целых проектов, я изменил контракт, как это было бы одинаково для всех проектов внутри решения, и чем он работал. Это проект A
<client>
<endpoint address="https://xxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference.IIntegrationService" name="basic" />
</client>
Проект B:
<client>
<endpoint address="xxxxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference1.IIntegrationService" name="basic" />
</client>
Наконец, я изменил для обоих:
<client>
<endpoint address="https://xxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="MyServiceReferrence.IIntegrationService" name="basic" />
</client>
При добавлении сервисной ссылки
остерегайтесь пространства имен, которое вы вводите:
Вы должны добавить его к имени вашего интерфейса:
<client>
<endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
binding="basicHttpBinding"
contract="MyNamespace.IMySOAPWebService" />
</client>