Не удалось найти элемент конечной точки по умолчанию


370

Я добавил прокси в веб-сервис для решения VS2008 / .NET 3.5. При построении клиента .NET выдает эту ошибку:

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

Поиск этой ошибки говорит мне использовать полное пространство имен в контракте. Вот мой 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, так что это тоже не проблема.

Есть какие-нибудь подсказки?


Если это выполняется на веб-сервере, вам нужно добавить .svc. Пример: « 192.168.100.87:7001/soap/IMySOAPWebService.svc
Даррен C

Служба не является службой .NET, она не работает на веб-сервере.
edosoft

Я решил эту проблему в проектах, разработанных в .NET, но у меня есть несколько проектов в VB6, и у меня та же проблема. Любые идеи?
Габриэль Интриаго

Ответы:


588

«Эта ошибка может возникнуть, если вы вызываете службу в библиотеке классов и вызываете библиотеку классов из другого проекта».

В этом случае вам нужно будет включить параметры конфигурации WS в основные проекты app.config, если это winapp или web.config, если это веб-приложение. Это способ пойти даже с PRISM и WPF / Silverlight.


1
Это не было причиной для моей конкретной проблемы, но я уверен, что это поможет другим. Спасибо
edosoft

9
Есть ли способ автоматически объединить два? Что если библиотека классов обновит свою конфигурацию? Вы просто застряли, не забывая обновить скопированную информацию конфигурации во всех проектах, которые ссылаются на нее? Это исправление слишком сильно зависит от бдительности разработчика ...
Шон Хэнли,

1
Я получаю ту же ошибку для приложения WP7 (я полагаю, Silverlight), и мне потребовалось слишком много времени, чтобы заметить, что ServiceReferences.ClientConfigэто происходит в каталоге проекта. Копирование <bindings>и <client>элементов из файла в моей библиотеке моего основного приложения (которые ранее были пустыми) есть вещи работать.
Дэвид Мейсон

4
Причина, по которой это происходит (насколько я понимаю), заключается в том, что значения конфигурации считываются из основного проекта в решении, будь то web, winforms, wpf и т. Д. Скажем, например, у вас есть проект библиотеки классов для доступа к базе данных, запись connectionString должен быть в конфигурации основного проекта, а не в конфигурации библиотеки классов.
Кьяран Бруен

6
Таким образом, мы можем заключить, что, если мы используем WCF в библиотеке, было бы лучше закодировать настройки напрямую, как показано на ссылке stackoverflow.com/questions/7688798/… .
Youngjae

90

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

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();
} 

редактировать

Если вы используете https, вам нужно использовать, BasicHttpsBindingа не BasicHttpBinding.


1
Это полезный ответ. В веб-службе, которую я использую, пользовательская конечная точка должна была быть связана в начальном объявлении объекта. Это не сработает, если я попытаюсь сделать это позже.
Пол Морель

2
Как бы я ни подозревал, что верхний ответ тоже мог бы сработать, ваше решение сработало, и мне кажется предпочтительнее взламывать мои собственные файлы конфигурации.
Сэм, я говорю, восстанови Монику

Работает шарм! Я предпочитаю устанавливать конечную точку в коде, а не распространять файл app.config с моим приложением.
Дэниел Джи,

1
Если это веб-служба Https, не забудьте изменить BasicHttpBinding () на BasicHttpsBinding ()
Энтони

Это решение лучше всего подходит для таких приложений, как EXCEL-DNA, в которых нет app.config или web.config.
user781700

75

Протестировав несколько вариантов, я наконец решил это с помощью

Контракт «IMySOAPWebService»

т.е. без полного пространства имен в конфиге. По какой-то причине полное имя не удалось решить правильно


3
Кажется, что название контракта должно быть написано точно так же, как и клиент. В моем случае var proxy = new ExternalServices.ServiceClient("MyServiceEndpoint");это сработало, когда я добавил пространство имен к контракту:contract="ExternalServices.IMyService"
Анатолий Миронов

Это не сработало для меня. Моя проблема может быть немного другой. Я получаю эту ошибку время от времени не всегда. В чем может быть проблема. Может ли ошибка быть на стороне сервиса? _Спасибо
albatross

57

У меня была такая же проблема. Оказывается, для веб-ссылки вы должны указать URL-адрес в качестве первого параметра для конструктора:

new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");

Для веб-ссылки СЕРВИСА нового стиля вы должны указать имя, которое относится к записи конечной точки в конфигурации:

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>

Довольно чертовски сложно удалить туннельное видение «это работало в более старой программе» ...


3
Ах, ха! Это исправило это для меня, раньше я просто использовал пустой конструктор, который продолжал давать сбои: new WebService.WebServiceSoapClient (); // провал
Трэвис

Этот солутин работал !!! но мне действительно любопытно, почему конечная точка по умолчанию не была загружена? есть идеи, в чем могут быть причины?
Дипти Мехта

@ Andomar извините, что поднял старую ветку. Есть ли одно преимущество перед другим - WebReference и ServiceReference? Я думаю, что первое было бы более удобно для меня, но ServiceReference - это крутая новая вещь, я думаю ...
Kev

17

У меня была такая ситуация, когда я имел

  • Служба WCF где-то размещена
  • Основной проект
  • Потребительский проект типа «библиотека классов», который имеет ссылку на службу для службы WCF
  • Основной проект вызывает методы из потребительского проекта

Теперь у проекта Consumer были все связанные настройки конфигурации в <system.serviceModel>Tag моего app.config, и он по-прежнему выдавал ту же ошибку, что и выше.

Все, что я сделал, это добавил один и тот же тег <system.serviceModel>в файл app.config моего основного проекта, и, наконец, мы были в порядке.

Реальная проблема, так как в моем случае это было чтение неправильного файла конфигурации. Вместо app.config потребителя он ссылался на конфигурацию основного проекта. Мне понадобилось два часа, чтобы понять это.


1
Одни и те же. Найдите <system.serviceModel>в своей библиотеке, а затем скопируйте в app.config вашего основного приложения. Еще один признак того, что библиотека классов app.configs не читается во время выполнения. Я трачу оооочень много времени, компенсируя этот недосмотр (IMO). Если я хочу, чтобы библиотека прочитала ее конфигурацию из своего app.config, позвольте ей. В противном случае, зачем вообще нужен app.config для библиотек классов?
SteveCinq

15

«Эта ошибка может возникнуть, если вы вызываете службу в библиотеке классов и вызываете библиотеку классов из другого проекта».

«В этом случае вам нужно будет включить параметры конфигурации 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 ...
            }

Подробности в этой статье .


15

Несколько ответов здесь приводят к правильному решению, когда вы сталкиваетесь с ошеломляющей ошибкой обращения к службе из файла класса: скопируйте информацию о конфигурации службы в ваш app.config web.config консоли или приложения Windows. Похоже, что ни один из этих ответов не показывает вам, что копировать. Давайте попробуем исправить это.

Вот что я скопировал из файла конфигурации моей библиотеки классов в файл конфигурации моего консольного приложения, чтобы обойти эту безумную ошибку для службы, которую я пишу, называемой "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>


14

Этот сводил меня с ума.

Я использую Silverlight 3 Prism (CAB) с WCF

Когда я вызываю службу WCF в модуле Prism, я получаю ту же ошибку:

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

Оказывается, он ищет в файле .xap оболочки файл ServiceReferences.ClientConfig, а не в файле модуля ServiceReferences.ClientConfig. Я добавил свою конечную точку и привязку к существующему файлу ServiceReferences.ClientConfig в моем приложении Silverlight Shell (оно вызывает собственные службы WCF).

Затем мне пришлось пересобрать приложение Shell, чтобы сгенерировать новый файл .xap для папки ClientBin моего веб-проекта.

Теперь эта строка кода наконец работает:

MyServiceClient myService = new MyServiceClient();

11

Я получал эту ошибку в приложении ASP.NET, где служба WCF была добавлена ​​в библиотеку классов, которая добавляется в приложение ASP.NET в виде ссылочного DLL-файла в папке bin. Чтобы устранить эту ошибку, параметры конфигурации в файле app.config в библиотеке классов, ссылающейся на службу WCF, необходимо скопировать в параметры web.config для сайта / приложения ASP.NET.


Хотя другие ответы могли бы описать ту же проблему. Этот ответ описал мою точную ситуацию, и я наконец понял проблему. Спасибо за спасение моего дня
Wouter Vanherck

10

Я обнаружил (как и при копировании в App.config пользовательского интерфейса, так как я использовал интерфейс библиотеки классов), мне пришлось ставить префикс имени привязки с именем ссылки на службу (моя 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" />

1
Я должен был сделать то же самое. Я действительно не понимаю, почему.
Бриг

8

У меня была та же проблема, но изменение пространства имен контракта не сработало для меня. Поэтому я попробовал веб-ссылку в стиле .Net 2 вместо ссылки на службу .Net 3.5. Это сработало.

Чтобы использовать веб-ссылку в Visual Studio 2008, нажмите «Добавить ссылку на службу», затем нажмите «Дополнительно», когда появится диалоговое окно. В этом вы найдете параметр, который позволит вам использовать веб-ссылку вместо ссылки на службу.


2
Это то, что я тоже делал. Я хотел бы, чтобы проблема имела смысл для меня.
Джарретт Видман

Это сработало и для меня. Теперь у меня есть все это ненужное барахло в моем решении (Settings.Settings, новая папка веб-ссылок) без уважительной причины. Придется вернуться и снова посетить это, когда у меня будет больше времени.
Майк К

Согласовано. У меня была та же проблема, и я исправил ее, изменив на веб-ссылку.
Стивен Хоскинг

7

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

Информация, введенная другими, устраняет первопричину этого. Если вы пытаетесь написать автоматизированные тестовые случаи, а тестируемый модуль фактически вызовет интерфейс сервиса, вам нужно добавить ссылку на сервис в тестовый проект. Это разновидность приложения, использующего библиотечный тип ошибок. Я не сразу понял это, потому что мой код, который использует интерфейс , не находится в библиотеке . Однако, когда тест фактически выполняется, он будет выполняться из тестовой сборки, а не тестируемой сборки.

Добавление сервисной ссылки в проект модульного тестирования решило мою проблему.


7

У меня есть ситуация, которая в модуле тестирования. Я скопировал файл app.config в проект модульного тестирования. Таким образом, проект модульного тестирования также содержит информацию о конечной точке.


2
Я не скопировал полный app.config, но system.serviceModelраздел. Это все!
Kwrl

То же самое, за исключением того, что я скопировал в system.serviceModelapp.config консольного приложения
AlbatrossCafe

5

Я сталкивался с этой проблемой однажды. Это было потому, что я все еще разрабатывал интерфейс, который использует сервис WCF. Я настроил тестовое приложение и продолжил разработку. Затем в процессе разработки я изменил некоторые пространства имен сервисов. Поэтому я дважды проверил "system.serviceModel -> client -> endpoint -> contract" в web.config, чтобы соответствовать классу WCF. Тогда проблема решена.


4

Пространство имен в вашей конфигурации должно отражать остальную часть пути к пространству имен после пространства имен вашего клиента по умолчанию (как настроено в свойствах проекта). Основываясь на вашем опубликованном ответе, я предполагаю, что ваш клиент настроен для использования в пространстве имен Fusion.DataExchange.Workflows. Если вы переместили код клиента в другое пространство имен, вам потребуется обновить конфигурацию, чтобы она соответствовала оставшемуся пути к пространству имен.


3

У меня та же проблема. Я пользуюсь службой WCF в библиотеке классов и вызываю библиотеку классов из Windows Application project. Но я забыл изменить <system.serviceModel>в файле конфигурации Windows-приложения Project такой же <system.serviceModel>, как файл app.Config библиотеки классов.
решение: измените конфигурацию внешнего проекта так же, как конфигурацию wcf библиотеки классов.


3

Привет, я столкнулся с той же проблемой, но лучшее решение - позволить .NET настроить вашу конфигурацию на стороне клиента. Я обнаружил, что когда я добавляю ссылку на службу со строкой запроса http: /namespace/service.svc? Wsdl = wsdl0, она НЕ создает конечные точки конфигурации на стороне клиента. Но когда я удаляю? Wsdl-wsdl0 и использую только URL http: /namespace/service.svc, он создает конфигурацию конечной точки в файле конфигурации клиента. для краткого удаления "? WSDL = WSDL0".


3

Не помещайте строку объявления клиента службы в качестве поля класса, вместо этого создайте экземпляр для каждого метода, который используется в. Таким образом, проблема будет исправлена. Если вы создаете экземпляр клиента службы как поле класса, тогда возникает ошибка времени разработки!


3

В случае, если вы используете приложение WPF, использующее инфраструктуру PRISM, конфигурация должна существовать в вашем начальном проекте (то есть в проекте, где находится ваш загрузчик).


2

Эта ошибка может возникнуть, если вы вызываете службу в библиотеке классов и вызываете библиотеку классов из другого проекта.


2

Кажется, есть несколько способов создать / исправить эту проблему. Для меня продукт CRM, который я использую, был написан на нативном коде и может вызывать мою DLL-библиотеку .NET, но я сталкиваюсь с информацией о конфигурации, которая должна быть в / над основным приложением. Для меня приложение CRM - это не .NET, поэтому мне пришлось поместить его в мой файл machine.config (а не туда, где я хочу). Кроме того, поскольку моя компания использует Websense, мне было трудно даже добавить ссылку на сервис из-за проблемы 407 Proxy Authentication Required, которая требовала изменения в machine.cong.

Прокси-решение:

Чтобы заставить работать Справочник службы WCF, мне пришлось скопировать информацию из app.config моей DLL в основной конфигурационный файл приложения (но для меня это был machine.config). И мне также пришлось скопировать информацию о конечной точке в тот же файл. Как только я это сделал, он начал работать на меня.


2

Хорошо. Мой случай был немного другим, но, наконец, я нашел решение для этого: у меня есть Console.EXE -> DLL -> Invoking WS1 -> DLL -> Invoking WS2

У меня были и конфигурации сервисной модели WS1, и WS2 в Console.EXE.config в соответствии с рекомендациями. - не решил проблему.

Но это все еще не работало, пока я не добавил WebReference WS2 в WS1 и не только в DLL, которая фактически создает и вызывает прокси WS2.


2

Если вы ссылаетесь на веб-сервис в своей библиотеке классов, вам нужно скопировать app.config в ваше приложение Windows или консольное приложение.

решение: измените конфигурацию внешнего проекта так же, как конфигурацию wcf библиотеки классов.

Работал для меня


2

У меня была такая же проблема
что и при использовании настольного приложения и веб-службы Global Weather.

Я удалил сервисную ссылку и добавил веб-ссылку, и проблема решена Спасибо


2

Решением для меня было удалить имя конечной точки из атрибута имени конечной точки в клиентском web.config, это позволило прокси использовать

ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");

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


2

Позвольте мне добавить еще одну вещь для поиска. ( Том Хэй Ответ уже намекает на это, но я хочу быть явным)

Мой web.configфайл имел следующее определение:

<protocolMapping>
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

Я уже использовал basicHttpsBinding для одной ссылки, но затем я добавил новую ссылку, которая требовала basicHttpBinding (нет). Все, что мне нужно было сделать, это добавить это к моему protocolMappingследующему:

<protocolMapping>
    <add binding="basicHttpBinding" scheme="http" />
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

Как правильно указывает LR , это должно быть определено в нужных местах. Для меня это означало один в файле app.config моего модульного теста, а также один в файле web.config основного сервисного проекта.


2

У меня была эта ошибка, когда я ссылался на Контракт в элементе файла конфигурации без оператора глобальной области видимости.

т.е.

<endpoint contract="global::MyNamepsace.IMyContract" .../>

работает, но

<endpoint contract="MyNamepsace.IMyContract" .../>

выдает ошибку «Не удалось найти элемент конечной точки по умолчанию, который ссылается на контракт».

Сборка, содержащая MyNamepsace.IMyContract, находится в сборке, отличной от основного приложения, поэтому это может объяснить необходимость использования разрешения глобальной области видимости.


2

Когда вы добавляете сервисную ссылку

введите описание изображения здесь

остерегайтесь пространства имен, которое вы вводите:

введите описание изображения здесь

Вы должны добавить его к имени вашего интерфейса:

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" 
            contract="MyNamespace.IMySOAPWebService" />
</client>

2

Я получил ту же ошибку, и я перепробовал много вещей, но не сработал, потом я заметил, что мой «контракт» не был одинаковым на всех проектах, я изменил контракт, как и на все проекты внутри решения, и чем он работал. Это проект А

<client>
    <endpoint address="https://xxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference.IIntegrationService" name="basic" />
</client>

Проект Б:

<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>

1

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.