Проблема с типом сервиса в директиве ServiceHost в сервисе wcf
Я разрабатываю простой сервис wcf для тестирования. Когда я тестирую этот сервис с локальным IIS 7.5, он работает правильно. Но когда я размещаю его в веб-IIS, я получаю эту ошибку:
Тип 'WcfServiceLibrary1.Service1', предоставленный как значение атрибута Service в директиве ServiceHost или предоставленный в элементе конфигурации system.serviceModel/serviceHostingEnvironment/serviceActivations, не найден.
И мой ServiceHost это:
<%@ ServiceHost Language="C#" Debug="true" Service="WcfServiceLibrary1.Service1" %>
Пожалуйста, помогите мне решить эту проблему
18 ответов
Поскольку я не смог найти это в любом из вопросов, которые я просматривал, добавив мой случай здесь:
У меня возникла эта проблема, когда я вручную изменил пространство имен в файле MyService.svc.cs и не изменил имя службы в соответствующем файле MyService.svc - оказалось, что это должно быть Service="namespace.classname".
Попробуйте использовать полное имя типа сборки.
Это [Fully Qualified Type Name], [Assembly]
куда [Fully Qualified Type Name] есть, в самых распространенных случаях YourNamespace.YourType
А также [Assembly] есть, в самых распространенных случаях YourAssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Это становится более сложным, чем это (универсальные типы, вложенные типы и т. Д.), Но вряд ли так будет в вашем случае.
Если ваше приложение использует параметры сборки по умолчанию, я рискну предположить, что директива должна выглядеть примерно так:
<%@ ServiceHost Language="C#" Debug="true"
Service="WcfServiceLibrary1.Service1,
WcfServiceLibrary1,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=null" %>
Хотя вы, вероятно, захотите избавиться от новых строк там.
Кроме того, убедитесь, что ваша DLL действительно была развернута
У меня была такая же проблема только при публикации моего сервиса, но он работал локально.
Оказалось, что служба ссылалась на DLL, которая не была развернута. Это супер особый случай, потому что это был системный dll (System.Web.Helpers), и, следовательно, проект даже не имел ссылки на него, и, таким образом, "Copy Local" не был установлен в true.
По умолчанию IIS ожидает увидеть файл svc в виртуальном каталоге и двоичные файлы в папке bin (как прокомментировал marc_s).
Однако конфигурация сборки по умолчанию для проектов библиотеки WCF - это сборка внутри папки bin/Debug (или bin/Release). Вы можете изменить путь вывода на "bin /" на вкладке "Build" свойств проекта.
Изменение этого решило эту ошибку для меня сегодня.
У меня была такая же проблема после того, как я развернул работающую службу в новом месте (новом сайте) в IIS. В inetmgr в дереве веб-сайтов по умолчанию я не щелкнул правой кнопкой мыши новый сайт и выбрал "Преобразовать в приложение" - все работает сейчас!
Наконец моя проблема решена.
Я удалил каталог службы на своем хосте и создал новый виртуальный каталог в пространстве хоста. Затем я скопировал свой сервис в новый каталог, где я его создал.
Теперь я могу просмотреть файл.svc для сервиса, и мой клиент будет использовать сервис.
Я не понимаю, почему возникла эта проблема! Я немного смущен!
Ответ, помеченный как ответ, очень сложен для понимания. На самом деле, хотя это и привело меня к решению моей аналогичной проблемы, я не знаю, так ли это, потому что я точно понимаю, что имел в виду автор.
Я обнаружил, указывал ли я приложение IIS на моей машине разработки на фактический каталог проекта, в котором находятся папки web.config, MyService.svc и bin, необходимые для приложения-службы WCF, это просто не будет работать, и выбрасывал это ошибка. Это несмотря на четырехкратную проверку каждого параметра и обеспечение того, чтобы все было эквивалентно другим простым работающим приложениям WCF.
В конечном итоге я решил проблему, опубликовав ее в другом каталоге, а не в зависимости от файлов проекта и самих каталогов.
Возможно, это было потому, что файлы были открыты в Visual Studio, когда я пытался запустить приложение WCF через IIS? Я не знаю, но Visual Studio предоставил localhost:59871/... работал. Я не знаю, использует ли этот экземпляр файлы проекта или временно опубликованную версию.
Проверьте, правильно ли указано пространство имен и класс, записанные в "Service" в "SeviceHost". Должно быть Service="namespace.classname",
Была эта проблема при запуске тестового проекта, который был встроен в мое решение.
Мне пришлось просмотреть в браузере, затем скопировать эту ссылку в новую ссылку на службу (удалить старую), а затем вставить ее, а не использовать кнопку утилиты обнаружения в ссылке на службу.
Убедитесь, что ваши скомпилированные библиотеки DLL перемещены в служебный каталог (каталог IIS).
Например, иногда Дженкинс не перемещает их автоматически.
Другой причиной этой проблемы часто является то, что служба wcf перемещается из одного каталога в другой, а файл svc не обновляется... самое простое решение - дважды проверить файл.svc и убедиться, что определение службы определено правильно.
Как ни странно, после просмотра и опробования других предложений я все еще получал сообщение об ошибке: "Тип", предоставленный в качестве значения атрибута Service в директиве ServiceHost или предоставленный в элементе конфигурации system.serviceModel/serviceHostingEnvironment/serviceActivations не смог быть найденным.
Конечно, мы все получаем большой проект с большим количеством DLL. Оказалось, что некоторые из старых компонентов в моем решении были нацелены на.Net 4.5, а новые dll были собраны с 4.5.1. Когда 4.5 dll ссылались на 4.5.1 dll.... Не знаю, почему я была счастливой маленькой морской свинкой, которая первой в моей команде нашла это. Несмотря на то, что исправление было очевидным и достаточно простым, все библиотеки были предназначены для одной и той же среды выполнения.Net.
Просто хотелось бы, чтобы Visual Studio заметила, что библиотеки DLL в одном и том же решении должны предназначаться для одной и той же среды выполнения.Net и генерировать предупреждение / ошибку при сборке, особенно если у нас есть решение и ссылка на проект, а среды выполнения не совпадают...
Поскольку я не могу сейчас ответить на вопрос @jeromeyers, я хочу добавить, что это решение, которое я нашел для этой проблемы.
Кто-то скопировал и вставил файл svc и связанные с ним файлы контрактов и кодов в новый проект, но они не обновляли пространства имен и имена классов везде. Очень расстраивает отслеживание, как это началось с этой ошибки:
"имя было запущено с недопустимым символом. Ошибка при обработке ресурса 'file:///C:/...
<% @ServiceHost "
при попытке щелкнуть правой кнопкой мыши файл.svc и выполнить команду "Просмотр в браузере".
Несмотря на то, что это немного отличается от вопроса (не веб-IIS): я попал сюда через поиск, потому что я получал эту ошибку, пытаясь отладить мой сервис - если у вас есть несколько сервисов внутри одного решения, эта ошибка произойдет, если решение данный вопрос еще не создан, и, следовательно, DLL не создается при попытке доступа к нему. Так что, если кто-то там работает, убедитесь, что все решение построено локально!
Первый раз разместить приложение службы WCF в IIS? Многие решили свои проблемы так или иначе. Однако, если все ваше решение верное и ваша ошибка связана с размещением вашего приложения в IIS, убедитесь, что ваш физический путь в IIS при добавлении веб-сайта указывает на каталог "bin" вашего решения, как показано ниже на снимках экрана.
У меня была такая же проблема, когда я загрузил свой рабочий сервис localhost в новое место на хосте. Я создаю новый виртуальный каталог и публикую в нем свой сервис через Visual Studio(FTP). Задача решена.
Это случилось со мной так же, и решением было создать фейдер с именем "bin" и поместить в него dll. Затем обновите сайт на IIS и все
У меня тоже была эта проблема, и что для меня волшебство было перезапустить IIS. Это очень странная ошибка.
Пожалуйста, посмотрите на https://msdn.microsoft.com/en-us/library/ms733766(v=vs.100).aspx
Вам нужно сделать 2 вещи, чтобы иметь возможность разместить службу на IIS или даже на IIS_EXPRESS в Visual Studio.
1) Обновите Web.Config, чтобы включить ServiceActivations
менять:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
в
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">
<serviceActivations>
<add service="API.Service1" relativeAddress="Service1.svc"/>
</serviceActivations>
</serviceHostingEnvironment>
2) Вам нужно создать каталог с именем App_Code в корневом каталоге. Теперь вам нужно переместить Сервис (например: Service1.svc) из корневого каталога в каталог App_Code. Таким образом, у вас будет App_Code\Service1.svc
Если вы просматриваете Сервис http://localhost:63309/Service1.svc он должен работать.