Недавно я создал службу 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 никогда не читается; по крайней мере, не тот, который, как мне кажется, должен читаться. Может ли это быть проблемой? Если да, то как я могу решить эту проблему. Опять же, любая помощь будет оценена по достоинству.
У меня возникла эта проблема и разрешили ее, добавив пространство имен к имени службы, например.
<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 мешает. Если вы еще не отредактировали это, чтобы вы могли запускать свою службу в любом контексте (то есть, unit test или консоль), тогда я бы посоветовал сделать это. Если вы развернули свое обслуживание в unit test, это, скорее всего, потерпит неудачу так же, как вы видите, с WS, который гораздо легче отлаживать, чем пытаться сделать это с помощью yucky WS plumbing.
Просто скопируйте файл 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();
У меня была та же проблема. Все работает в 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.
Для подготовки конфигурации для WCF сложно, и иногда определение типа сервиса остается незамеченным.
Я написал только пространство имен в теге службы, поэтому я получил ту же ошибку.
<service name="ServiceNameSpace">
Не забывайте, что тегу службы требуется полное имя класса сервиса.
<service name="ServiceNameSpace.ServiceClass">
Для других людей, которые похожи на меня.
Я просто справился с этой проблемой на моем сервисе. Вот ошибка, которую я получал:
Служба "EmailSender.Wcf.EmailService" имеет нулевые конечные точки приложения (без инфраструктуры). Возможно, это связано с тем, что файл конфигурации не был найден для вашего приложения или потому, что в файле конфигурации не найден ни один элемент службы, соответствующий имени службы, или потому, что в элементе службы не было определено никаких конечных точек.
Вот два шага, которые я использовал для его исправления:
Используйте правильное полное имя класса:
<service behaviorConfiguration="DefaultBehavior" name="EmailSender.Wcf.EmailService">
Включить конечную точку с помощью mexHttpBinding и, самое главное, использовать контракт IMetadataExchange:
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
Моя проблема заключалась в том, что я переименовал свой стандартный класс Service1 для .svc файла в более содержательное имя, что вызвало поведение web.configConfiguration и конечной точки в соответствии со старым соглашением об именах. Попробуйте исправить ваш web.config.
Я просто столкнулся с этой проблемой и проверил все вышеперечисленные ответы, чтобы убедиться, что я не заметил ничего очевидного. Ну, у меня была полуочевидная проблема. Моя оболочка моего имени класса в коде и имя класса, которое я использовал в файле конфигурации, не совпадали.
Например: если имя класса - CalculatorService и файл конфигурации относится к Calculatorservice... вы получите эту ошибку.
Эта ошибка возникает, если конфигурационный файл хостинг-приложения вашей службы WCF не имеет надлежащей конфигурации.
Помните этот комментарий из конфигурации:
При развертывании проекта библиотеки служб содержимое конфигурации файл должен быть добавлен в файл хоста app.config. Конфигурация системы не поддерживает файлы конфигурации для библиотек.
Если у вас есть служба WCF, размещенная в IIS, во время выполнения через VS.NET он прочитает файл app.config проекта библиотеки обслуживания, но прочитает веб-хост web.config после его развертывания. Если у web.config нет идентичной конфигурации <system.serviceModel>, вы получите эту ошибку. Обязательно скопируйте конфигурацию из app.config после ее улучшения.
Я запускал Visual Studio в режиме администратора, и это сработало для меня:) Кроме того, убедитесь, что файл app.config, который вы используете для записи конфигурации WCF, должен находиться в проекте, где используется класс "ServiceHost", а не в фактическом проекте службы WCF.
Одна важная вещь, которую следует помнить тем, кто работает с консольным приложением для размещения службы 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". Затем я сделал шаги для Create Service, чтобы я мог подключиться к моей службе WCF. Теперь у меня было два конечных точки в моем App.config, а не только на одном. Одна конечная точка была связана с подключением к Библиотеке услуг WCF, а другая - для ее размещения.