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

Я добавил прокси в веб-сервис для решения 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, так что это тоже не проблема.

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

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

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

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

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

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

Контракт «IMySOAPWebService»

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

У меня была такая же проблема. Оказывается, для веб-ссылки вы должны указать 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>

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

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

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

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

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

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

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

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

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

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

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

Я использую 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();

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

Я обнаружил (как и при копировании в 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" />

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мой 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 основного сервисного проекта.

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

т.е.

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

работает, но

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

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

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

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

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

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

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

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

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

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