Сервіс має нульові кінцеві точки додатків (неінфраструктурних)

Нещодавно я створив службу WCF (dll) та хост служби (exe). Я знаю, що моя служба WCF працює коректно, оскільки я можу успішно додати послугу до WcfTestClient.

Однак я, здається, стикаюся з проблемою, коли доходжусь до висловлення мого WCF від хоста служби (exe). Я можу додати посилання на WCF (dll) до мого хосту служби (exe) і створити необхідні компоненти для exe; такі як інсталятор служби, хост служби та app.config, скомпілюйте, а потім остаточно встановіть exe за допомогою InstallUtil. Але коли я намагався запустити службу в консолі керування Microsoft, служба відразу ж зупиняється після запуску.

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

Опис:

Послугу не можна запустити. System.InvalidOperationException: Служба 'Сервіс' має нульові кінцеві точки додатків (неінфраструктурних). Це може бути тому, що для вашої програми не знайдено файлу конфігурації, або тому, що у файлі конфігурації не знайдено елемента служби, що відповідає імені служби, або тому, що в елементі служби не визначено кінцевих точок.

Ця помилка фактично генерується в OnStart; мого колишнього, коли я виконую цей дзвінок ServiceHost.Open(). Я бачив численні публікації, де інші особи стикалися з цим питанням, проте більшість, якщо не всі, заявляють, що назва послуги або контракт; простору імен та імені класу не вказуються. Я перевірив обидва ці записи у своєму конфігураційному файлі; як в exe, так і в dll, і вони ВІДМІННІ збігаються. У мене в офісі двічі перевіряли людей, щоб переконатися, що я в один момент не осліп, але, звісно, ​​вони дійшли того самого висновку, що і я, що все виглядало так, як це було вказано правильно. Я справді заблукав у тому, що відбувається на даний момент. Хтось може мені допомогти з цим питанням?

Інша річ, яка виникла як можлива причина, що це може статися, полягає в тому, що app.config ніколи не читається; принаймні не ту, яку, на мою думку, слід читати. Можливо, це питання? Якщо так, то як я можу вирішити цю проблему. Знову ж, будь-яка допомога буде оцінена

Я просто мав цю проблему і вирішив її, додавши простір імен до імені служби, наприклад

 <service name="TechResponse">

стала

 <service name="SvcClient.TechResponse">

Я також бачив, як це вирішується за допомогою Web.config замість App.config.

Кінцева точка також повинна мати простір імен:

 <endpoint address="uri" binding="wsHttpBinding" contract="Namespace.Interface" />

Подумайте про одне: чи ваш WCF повністю від'єднаний від WindowsService (WS)? WS є болючим, тому що ви не маєте надто багато контролю над ними чи видимості. Я намагаюся пом'якшити це, маючи всі мої речі, що не належать до WS, у своїх власних класах, щоб їх можна було протестувати незалежно від WS хоста. Застосування цього підходу може допомогти вам усунути все, що відбувається із середовищем виконання WS та, зокрема, вашою службою.

Джон, ймовірно, правильно, що це проблема із файлом .config. WCF завжди буде шукати контекст виконання .config . Отже, якщо ви розміщуєте свій WCF у різних контекстах виконання (тобто тестуйте за допомогою консольного додатка та розгортайте за допомогою WS), вам потрібно переконатися, що дані конфігурації WCF переміщено у відповідний файл .config. Але основна проблема для мене полягає в тому, що ви не знаєте, в чому проблема, тому що WS goo заважає. Якщо ви ще не переробили це до того, щоб ви могли запустити свою службу в будь-якому контексті (тобто модульний тест або консоль), тоді я рекомендую це зробити. Якщо ви запустили свою службу в юніт-тесті, вона, швидше за все, зазнає невдачі так само, як ви спостерігаєте із WS, яку набагато простіше налагодити, ніж намагатися зробити це за допомогою негідної сантехніки WS.

Просто скопіюйте файл App.config із сервісного проекту в додаток хоста консолі та вставте сюди, а потім видаліть його із сервісного проекту.

Я отримав більш докладний виняток, коли додав його програмно - AddServiceEndpoint:

string baseAddress = "http://" + Environment.MachineName + ":8000/Service";
ServiceHost host = new ServiceHost(typeof(Service), new Uri(baseAddress));  

host.AddServiceEndpoint(typeof(MyNamespace.IService),
                        new BasicHttpBinding(), baseAddress);
host.Open();

Підготувати конфіграцію для WCF важко, і іноді визначення типу послуги залишається непоміченим.

Я написав у тегу служби лише простір імен, тож отримав ту саму помилку.

<service name="ServiceNameSpace">

Не забувайте, що мітка обслуговування потребує повноцінного імені класу обслуговування.

<service name="ServiceNameSpace.ServiceClass">

Для інших людей, які схожі на мене.

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

Під час реструктуризації коду я фактично змінив імена класів Service та IService та змінив ServiceHost, щоб вказати на це нове ім'я класу Service (як показано у фрагменті коду), але у файлі моїх програм App.Config я все ще використовував старе ім'я класу Service . (див. поле імені розділу конфігурації внизу фрагмента)

Ось фрагмент коду,

 ServiceHost myServiceHost = new ServiceHost(typeof(NewServiceClassName)); 

а у файлі App.config у розділі служби я мав на увазі старе ім’я serviceclass , змінивши його на New ServiceClassName, виправлену для мене проблему.

  <service name="ProjectName.OldServiceClassName"> 
        <endpoint address="" binding="basicHttpBinding" contract="ProjectName.IService">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
        <host>
          <baseAddresses>
            <add baseAddress=""/>
          </baseAddresses>
        </host>
      </service>

У мене була та сама проблема. Все працює у VS2010, але коли я запускаю той самий проект у VS2008, я отримую згаданий виняток.

Те, що я зробив у своєму проекті VS2008, щоб він працював, було додавання виклику AddServiceEndpointчлену мого об’єкта ServiceHost.

Ось мій фрагмент коду:

Uri baseAddress = new Uri("http://localhost:8195/v2/SystemCallbackListener");

ServiceHost host = new ServiceHost(typeof(SystemCallbackListenerImpl), baseAddress);

host.AddServiceEndpoint(typeof(CsfServiceReference.SystemCallbackListener),
                        new BasicHttpBinding(),
                        baseAddress);
host.Open();

Я не модифікував файл app.config. Але, думаю, кінцеву точку служби також можна було додати у файл .config.

Я щойно розробив це питання на своєму сервісі. Ось помилка, яку я отримував:

Послуга 'EmailSender.Wcf.EmailService' має нульові кінцеві точки (не інфраструктурні). Це може бути тому, що для вашої програми не знайдено файлу конфігурації, або тому, що у файлі конфігурації не знайдено елемента служби, що відповідає імені служби, або тому, що в елементі служби не визначено кінцевих точок.

Ось два кроки, я використовував, щоб виправити це:

1. Використовуйте правильну повну назву класу:

   <service behaviorConfiguration="DefaultBehavior" name="EmailSender.Wcf.EmailService">

2. Увімкніть кінцеву точку за допомогою mexHttpBinding, а головне, скористайтеся контрактом IMetadataExchange:

   <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>

Ця помилка виникає, якщо файл конфігурації хостингової програми вашої служби WCF не має належної конфігурації.

Запам’ятайте цей коментар із конфігурації:

Під час розгортання проекту бібліотеки служб вміст конфігураційного файлу повинен бути доданий до файлу app.config хоста. System.Configuration не підтримує конфігураційні файли для бібліотек.

Якщо у вас є служба WCF, розміщена в IIS, під час роботи через VS.NET вона буде читати app.config проекту бібліотеки служб, але прочитати хост web.config після розгортання. Якщо web.config не має однакової <system.serviceModel>конфігурації, ви отримаєте цю помилку. Обов’язково скопіюйте конфігурацію з app.config, як тільки вона буде вдосконалена.

Я просто зіткнувся з цим питанням і перевірив усі вищезазначені відповіді, щоб переконатися, що не пропускаю нічого очевидного. Ну, у мене була напів очевидна проблема. Мій регістр мого класу в коді та імені класу, який я використовував у файлі конфігурації, не збігався.

Наприклад: якщо ім'я класу - CalculatorService, а файл конфігурації посилається на Calculatorservice ... ви отримаєте цю помилку.

Я запустив Visual Studio в режимі адміністратора, і він у мене спрацював :) Крім того, переконайтеся, що файл app.config, який ви використовуєте для написання конфігурації WCF, повинен бути в проекті, де використовується клас "ServiceHost", а не у власне службі WCF проекту.

Моя проблема полягала в тому, що я перейменував свій клас Service1 за замовчуванням для файлу .svc на більш значуще ім'я, що спричинило відповідь web.config behaviourConfiguration та кінцевої точки старій умові іменування. Спробуйте виправити свій web.config.

Важливо пам’ятати тим, хто працює з додатком Console для розміщення служби WCF, - це те, що файл Web.config у проекті WCF повністю ігнорується. Якщо ваша system.serviceModelконфігурація є там, вам потрібно перемістити цей розділ конфігурації в App.config вашого проекту консолі.

Це на додаток до відповідей щодо забезпечення того, щоб простір імен був вказаний у правильних місцях.

Ще одна підказка - це справді вирішило цю проблему в моєму випадку.

Я переношу деякі служби WCF із консольної програми (яка конфігурує в коді декілька служб WCF) в Azure WebRole, щоб опублікувати їх у Azure. Щоразу, коли я додаю нову послугу, VS редагує мій web.config і додає такий рядок:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">

Ну, з усіма порадами та відповідями вище, я не міг змусити це працювати, поки не видалив усі атрибути в елементі serviceHostingEnvironment. Як бачите, я не рок-зірка WCF, але я зробив це для роботи з першою службою, просто налаштувавши її як:

<service name="FirstService" behaviorConfiguration="metadataBehavior">
                <endpoint address=""
                 binding="wsHttpBinding"
                 bindingConfiguration="WSHttpBinding_WcfServicesBinding"
                 contract="IFirstService" />

            </service>

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

Сподіваюся, це заощадить ваш час.

У мене сталася ця помилка в службі Windows, коли створена мною бібліотека служб WCF не була підключена для хостингу, але була підключена для підключення. Мені не вистачало кінцевої точки. (Я хотів як підключення, так і розміщення в моїй службі Windows, щоб я міг обслуговувати службу WCF до інших з’єднань, а також щоб основний процес моєї служби Windows також використовував її для виконання різних завдань за таймером / розкладом.)

Виправлення полягало в тому, що я правильно вибрав свій файл App.config і вибрав Редагувати конфігурацію WCF. Потім я зробив кроки для створення служби, щоб я міг підключитися до своєї служби WCF. Тепер у мене в App.config було дві кінцеві точки, а не лише одна. Одна кінцева точка призначена для підключення до бібліотеки служб WCF, а інша - для її розміщення.