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

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 никогда не читается; по крайней мере, не тот, который, я думаю, должен быть прочитан. Может ли это быть проблемой? Если да, то как я могу решить эту проблему? Опять же, любая помощь будет оценена.

Answer 1

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

 <service name="TechResponse">

стал

 <service name="SvcClient.TechResponse">

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

<service name="ServiceNameSpace">

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

<service name="ServiceNameSpace.ServiceClass">

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

Answer 6

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

Answer 7

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

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

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

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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

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

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