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

Question

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

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

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

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

Описание:

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

Эта ошибка на самом деле генерируется в OnStart; моего exe, когда я выполняю этот вызов ServiceHost.Open(), Я видел множество постов, где другие люди сталкивались с этой проблемой, однако большинство, если не все, утверждают, что название сервиса или контракт; пространство имен и имя класса, не указываются. Я проверил обе эти записи в моем конфигурационном файле; в exe, а также в dll, и они совпадают идеально. У меня в офисе были другие люди, которые дважды проверяли меня, чтобы убедиться, что я не ослепну в один момент, но, конечно, они пришли к тому же выводу, что и я, что все выглядело так, как будто указано правильно. Я действительно в растерянности относительно того, что происходит в данный момент. Может ли кто-нибудь помочь мне с этим вопросом?

Другая причина, по которой это может происходить, состоит в том, что app.config никогда не читается; по крайней мере, не тот, который, я думаю, должен быть прочитан Может ли это быть проблемой? Если да, то как я могу решить эту проблему? Опять же, любая помощь будет оценена.

94

.net wcf exception-handling wcf-endpoint wcf-configuration

Источник

user280626 24 фев '10 в 19:27

17 ответов

Другие вопросы по тегам .net wcf exception-handling wcf-endpoint wcf-configuration

user167611 22 июл '10 в 02:00 2010-07-22 02:00 · Answer 1 · 2010-07-22 02:00

Я только что имел эту проблему и решил ее, добавив пространство имен к имени службы, например

 <service name="TechResponse">

стал

 <service name="SvcClient.TechResponse">

Я также видел, что это разрешается с помощью Web.config вместо App.config.

101

Источник

user167611 22 июл '10 в 02:00

user442518 08 сен '10 в 14:21 2010-09-08 14:21 · Answer 2 · 2010-09-08 14:21

Конечная точка также должна иметь пространство имен:

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

13

Источник

user442518 08 сен '10 в 14:21

user614716 13 фев '11 в 01:36 2011-02-13 01:36 · Answer 3 · 2011-02-13 01:36

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

11

Источник

user614716 13 фев '11 в 01:36

user73482 24 фев '10 в 19:36 2010-02-24 19:36 · Answer 4 · 2010-02-24 19:36

Стоит подумать: у вас полностью отключен WCF от WindowsService (WS)? WS - это больно, потому что у вас нет большого контроля или видимости для них. Я пытаюсь смягчить это, имея все свои вещи, не относящиеся к WS, в своих собственных классах, чтобы их можно было тестировать независимо от хоста WS. Использование этого подхода может помочь вам устранить все, что происходит со средой выполнения WS, в частности с вашим сервисом.

Джон, вероятно, прав, что это проблема файла.config. WCF всегда будет искать контекст выполнения.config. Поэтому, если вы размещаете WCF в разных контекстах выполнения (то есть тестируете с помощью консольного приложения и развертываете с помощью WS), вам необходимо убедиться, что данные конфигурации WCF перемещены в соответствующий файл.config. Но основная проблема для меня заключается в том, что вы не знаете, в чем проблема, потому что WS Goo мешает. Если вы еще не сделали рефакторинг для того, чтобы вы могли запускать свой сервис в любом контексте (то есть в модульном тесте или в консоли), то я бы поступил так. Если вы развернете свою службу в модульном тесте, она, скорее всего, потерпит неудачу так же, как вы видите на WS, который гораздо легче отлаживать, чем пытаться сделать это с отвратительным подключением WS.

user696627 20 мар '13 в 17:36 2013-03-20 17:36 · Answer 5 · 2013-03-20 17:36

Я получил более подробное исключение, когда я добавил его программно - 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();

5

Источник

user696627 20 мар '13 в 17:36

user1557482 05 дек '14 в 11:50 2014-12-05 11:50 · Answer 6 · 2014-12-05 11:50

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

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

<service name="ServiceNameSpace">

Не забывайте, что метка сервиса требует полного имени класса сервиса.

<service name="ServiceNameSpace.ServiceClass">

Для других людей, которые похожи на меня.

user6271132 20 ноя '18 в 16:02 2018-11-20 16:02 · Answer 7 · 2018-11-20 16:02

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

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

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

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

и в файле App.config в разделе services я ссылался на старое имя serviceclass, меняя его на исправленную для меня новую проблему 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>

user175388 22 сен '10 в 12:10 2010-09-22 12:10 · Answer 8 · 2010-09-22 12:10

У меня такая же проблема. Все работает в 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.

user856784 21 июл '11 в 20:08 2011-07-21 20:08 · Answer 9 · 2011-07-21 20:08

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

Например: если имя класса CalculatorService и файл конфигурации ссылается на Calculatorservice ... вы получите эту ошибку.

user249348 23 май '11 в 21:18 2011-05-23 21:18 · Answer 10 · 2011-05-23 21:18

Я только что проработал эту проблему на моем сервисе. Вот ошибка, которую я получил:

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

Вот два шага, которые я использовал, чтобы исправить это:

Используйте правильное полное имя класса:

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

Включите конечную точку с mexHttpBinding и, самое главное, используйте контракт IMetadataExchange:
```
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
```

user587342 27 фев '16 в 17:52 2016-02-27 17:52 · Answer 11 · 2016-02-27 17:52

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

2

Источник

user587342 27 фев '16 в 17:52

user410937 31 окт '12 в 18:26 2012-10-31 18:26 · Answer 12 · 2012-10-31 18:26

Эта ошибка возникает, если файл конфигурации хост-приложения вашей службы WCF не имеет правильной конфигурации.

Запомните этот комментарий из конфигурации:

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

Если у вас есть служба WCF, размещенная в IIS, во время выполнения через VS.NET она прочитает app.config проекта библиотеки служб, но прочитает web-файл хоста после развертывания. Если web.config не имеет идентичный <system.serviceModel> Конфигурация вы получите эту ошибку. Обязательно скопируйте конфигурацию из app.config, как только она будет усовершенствована.

user3699830 01 сен '16 в 08:21 2016-09-01 08:21 · Answer 13 · 2016-09-01 08:21

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

Я перенесу некоторые службы 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>

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

Я надеюсь, что это экономит ваше время.

user830384 05 июл '11 в 20:06 2011-07-05 20:06 · Answer 14 · 2011-07-05 20:06

Моя проблема заключалась в том, что я переименовал свой класс Service1 по умолчанию для файла.svc в более осмысленное имя, в результате чего web.config поведение Configuration и конечная точка соответствовали старому соглашению об именах. Попробуйте исправить ваш web.config.

1

Источник

user830384 05 июл '11 в 20:06

user197591 18 мар '16 в 02:07 2016-03-18 02:07 · Answer 15 · 2016-03-18 02:07

Для тех, кто работает с консольным приложением для размещения службы WCF, следует помнить, что файл Web.config в проекте WCF полностью игнорируется. Если твой system.serviceModel Конфигурация есть, тогда вам нужно переместить этот раздел конфигурации в App.config вашего консольного проекта.

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

user105539 04 окт '17 в 04:05 2017-10-04 04:05 · Answer 16 · 2017-10-04 04:05

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

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

user351154 11 авг '21 в 00:43 2021-08-11 00:43 · Answer 17 · 2021-08-11 00:43

Как уже упоминали другие, моя проблема заключалась в том, что у меня не было system.serviceModelв моем приложении для хостинга app.config. Например:

      <configuration>
  ...
  <system.serviceModel>
    <services>
      <service name="Services.MyServiceManager">
        <endpoint address="net.tcp://localhost:8009/MyService"
                  binding="netTcpBinding"
                  contract="Contracts.IMyService" />
      </service>
    </services>
  </system.serviceModel>
</configuration>