Служба не имеет конечных точек приложения (не инфраструктуры)

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

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

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

Описание:

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

Эта ошибка фактически генерируется в OnStart; моего exe, когда я выполняю этот вызов 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. Если вы еще не реорганизовали это, чтобы вы могли запускать свою службу в любом контексте (то есть модульном тесте или консоли), я бы предложил сделать это. Если вы развернете свою службу в модульном тесте, она, скорее всего, выйдет из строя так же, как вы наблюдаете с 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">

Для других людей, подобных мне.

Сегодня я столкнулся с той же проблемой, разместив здесь свою ошибку и исправив ее, чтобы она могла кому-то помочь.

Во время реструктуризации кода я фактически изменил имена классов службы и IService и изменил ServiceHost, чтобы указать на это новое имя класса службы (как показано во фрагменте кода), но в моем файле App.Config приложений хоста я все еще использовал старое имя класса службы . (см. поле имени раздела конфигурации во фрагменте ниже)

Вот фрагмент кода,

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

и в файле App.config в разделе services я имел в виду старое имя класса обслуживания, изменив его на исправленную проблему 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 behaviorConfiguration и конечная точка соответствовали старому соглашению об именах. Попытайтесь исправить свой web.config.

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