Не вдалося знайти елемент кінцевої точки за замовчуванням

Я додав проксі-сервер до веб-сервісу до рішення VS2008 / .NET 3.5. При побудові клієнта .NET видає цю помилку:

Не вдалося знайти елемент кінцевої точки за замовчуванням, на який посилається контракт "IMySOAPWebService", у розділі конфігурації клієнта ServiceModel. Це може бути через те, що для вашої програми не знайдено файлу налаштування або тому, що в елементі клієнта не було знайдено жодного елемента кінцевої точки, що відповідає цьому контракту.

Пошук цієї помилки підказує мені використовувати повний простір імен у договорі. Ось мій 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 (я згадую про це, оскільки в ряді звернень 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
• Основні методи виклику проекту від споживчого проекту

Тепер проект «Споживач» мав усі відповідні налаштування конфігурації в <system.serviceModel>тезі мого 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 в модулі призми, я отримую ту ж помилку:

Не вдалося знайти елемент кінцевої точки за замовчуванням, на який посилається контракт "IMyService", у розділі налаштування клієнтської моделі послуги. Це може бути через те, що для вашої програми не знайдено файлу конфігурації або тому, що в елементі клієнта не було знайдено елемента кінцевої точки, що відповідає цьому контракту

Виявляється, він шукає у файлі .xap Shell для файлу 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, натисніть "Додати службну довідку", а потім натисніть "Додатково", коли з'явиться діалогове вікно. У цьому випадку ви знайдете варіант, який дозволить вам використовувати веб-посилання замість посилання на службу.

Тестування пристрою небібліотечної програми, яка споживає послугу, може спричинити цю проблему.

Інформація, яку ввели інші, стосується першопричини цього. Якщо ви намагаєтеся писати автоматизовані тестові приклади, і пристрій, який ви тестуєте, фактично викликає сервісний інтерфейс, вам потрібно додати посилання на службу до тестового проекту. Це аромат програми за допомогою помилки типу бібліотеки. Я не відразу зрозумів це, хоча мій код, який споживає інтерфейс , не знаходиться в бібліотеці . Однак, коли тест фактично працює, він буде працювати з тестової збірки, а не збірки, що перевіряється.

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

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

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

Простір імен у вашому конфігурації має відображати решту шляху до імен після простору імен вашого клієнта за замовчуванням (як налаштовано у властивостях проекту). На основі вашої опублікованої відповіді, я гадаю, що ваш клієнт налаштований на простір імен "Fusion.DataExchange.Workflows". Якщо ви перемістили код клієнта в іншу область імен, вам потрібно буде оновити конфігурацію, щоб відповідати решті шляху простору імен.

У мене така ж проблема. Я використовую службу WCF у бібліотеці класів та дзвоню до бібліотеки класів із windows Application project.but I Forget Change <system.serviceModel>in Config File of windows application <system.serviceModel>Проектуйте той самий файл app.Config файлу бібліотеки класів.
рішення: змінити Конфігурація зовнішнього проекту та сама конфігурація wcf бібліотеки класів.

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

Не ставте рядок декларації клієнтського сервісу як поле класу, замість цього, створіть екземпляр для кожного методу, який використовується в. Отже, проблема буде вирішена. Якщо ви створюєте екземпляр клієнтського сервісу як поле класу, виникає помилка часу проектування!

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

Ця помилка може виникнути, якщо ви викликаєте службу в бібліотеці класів і дзвоните в бібліотеку класів з іншого проекту.

Здається, існує кілька способів створити / виправити цю проблему. Для мене продукт CRM, який я використовую, був написаний у власному коді та здатний викликати мій dnet .NET, але я натрапляю на інформацію про конфігурацію, яка потребує знаходження в / над основним додатком. Для мене додаток CRM не є .NET, тому мені довелося помістити його у свій файл machine.config (не там, де я цього хочу). Крім того, оскільки моя компанія використовує Websense, мені було важко навіть додати довідку про службу через проблему, необхідну 407 проксі-аутентифікацію, що вимагало внесення змін до 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

Я видалив посилання на службу та додав веб-посилання та вирішив проблему Спасибі

Для мене вирішенням було видалити ім’я кінцевої точки з атрибута Endpoint Name у клієнта web.config, що дозволило проксі використовувати

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

потренувались лише цілий день. Також ім'я контракту було помилковим, як тільки це виправлення було встановлено, хоча воно було неправильним, коли з'явилася початкова помилка. Подвійна, а потім потрійна перевірка рядків імен контракту !! attrib: Ian

Дозвольте мені додати ще одну річ, яку потрібно шукати. ( Тома Хей вже на це натякає, але я хочу бути явною)

У моєму web.configфайлі було визначено наступне:

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

Я вже використовував basicHttpsBinding для однієї посилання, але потім я додав нову посилання, яка вимагала basicHttpBinding (без s). Все, що я повинен був зробити, це додати це до мого 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>

Я отримав таку ж помилку, і я спробував багато речей, але нічого не вийшло, ніж я помітив, що мій "контракт" не був однаковим у всіх проектах, я змінив контракт, як це було б однаково для всіх проектів всередині рішення, і ніж він працював. Це проект 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>

У мене була та сама проблема, і вона була вирішена лише тоді, коли хост-додаток і DLL, який використовував цю кінцеву точку, мали одне і те ж ім'я посилання служби.