Проблема с типом сервиса в директиве ServiceHost в wcf-сервисе

Ответ 1

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

У меня возникла эта проблема, когда я вручную изменил пространство имен в файле MyService.svc.cs и не изменил имя службы в соответствующем файле MyService.svc - оказалось, что это должно быть Service = "namespace.classname".

Ответ 2

Попробуйте использовать имя типа сборки, подходящее для сборки.

Это [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 действительно развернута

Ответ 3

У меня была такая же проблема только при публикации моей службы, но она работала локально.

Оказалось, что служба ссылалась на DLL, которая не была развернута. Это супер специальный случай, потому что это была системная dll (System.Web.Helpers), и, таким образом, проект даже не ссылался на него, и, таким образом, для параметра "Копировать локальное" не было установлено значение true.

Ответ 4

По умолчанию IIS ожидает увидеть файл svc в виртуальном каталоге и двоичные файлы внутри папки bin (как комментирует marc_s).

Однако конфигурация сборки по умолчанию для проектов библиотеки WCF заключается в создании внутри папки bin/Debug (или bin/Release). Вы можете изменить выходной путь на "bin/" на вкладке "Свойства проекта".

Изменение этой ошибки для меня сегодня.

Ответ 5

Наконец, моя проблема решена.

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

Теперь я могу просмотреть файл .svc для службы, и мой клиент будет использовать эту услугу.

Я не понимаю, почему эта проблема возникла! Я немного смущен!

Ответ 6

У меня возникла такая же проблема после того, как я развернул рабочую службу в новое место (новый сайт) в IIS. В inetmgr под деревом веб-сайта по умолчанию я не щелкнул правой кнопкой мыши новый сайт и выбрал Convert to Application - все работает сейчас!

Ответ 7

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

Я обнаружил, что указал приложение IIS на моей машине разработки на фактический каталог проекта, в котором находятся папки web.config, MyService.svc и bin, необходимые для Сервисного приложения WCF, это просто не сработает, и это была ошибка. Это несмотря на четырехкратную проверку каждой настройки и обеспечение того, чтобы все было эквивалентно другим простым рабочим WCF-приложениям.

В конечном итоге я решил проблему, опубликовав ее в другом каталоге, а не в зависимости от файлов проекта и самой директории.

Возможно, это потому, что файлы были открыты в Visual Studio, поскольку я пытался запустить приложение WCF через IIS? Я не знаю, но Visual Studio предоставил localhost: 59871/... работал. Я не знаю, использует ли этот экземпляр файлы проекта или временную опубликованную версию.

Ответ 8

Проверьте, правильно ли пространство имен и класс, записанные в "Сервис" из "SeviceHost", должны быть Service="namespace.classname".

Ответ 9

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

Кто-то скопировал и вложил файл svc и связанные с ним файлы контрактов и кодов в новый проект, но они не обновляли пространства имен и имена классов во всем мире. Очень неприятно отслеживать это, когда оно начиналось с этой ошибки:

"было запущено с недопустимым символом. Файл ресурса обработки ошибок:///C:/...

<% @ServiceHost "

при попытке щелкнуть правой кнопкой мыши на файле .svc и сделать "Просмотр в браузере".

Ответ 10

Несмотря на то, что это немного отличается от вопроса (а не веб-iis): я попал сюда через поиск, потому что получаю эту ошибку при попытке отладки моей службы - если у вас есть несколько сервисов внутри одного решения, эта ошибка возникнет если данное решение еще не построено, и, следовательно, DLL не создается при попытке получить к нему доступ. Поэтому любому, кто там, убедитесь, что локально работает, что все решение построено!

Ответ 11

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

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

Ответ 12

Странно, посмотрев и попробовав другие предложения, я все еще получал ошибку: Тип ', предоставленный в качестве значения атрибута Service в директиве ServiceHost или предоставленный в элементе конфигурации system.serviceModel/serviceHostingEnvironment/serviceActivations, не может быть найден.

Конечно, у нас есть большой проект с большим количеством DLL. Оказалось, что некоторые из старых компонентов в моем решении были нацелены на .Net 4.5, а новые dll - на 4.5.1. Когда 4.5 dll ссылались на dll 4.5.1.... Не уверен, почему я был счастливым маленьким морским свинок, который первым в моей команде нашел это. Хотя исправление было очевидным и достаточно простым, просто все DLL-серверы нацелились на ту же среду .NET.

Просто хочу, чтобы Visual Studio заметила, что DLL файлы в одном и том же решении должны нацелиться на одну и ту же среду .NET и генерировать предупреждение/ошибку при создании, особенно если у нас есть решение и ссылка на проект, а время выполнения не соответствует...

Ответ 13

Другая причина для этой проблемы часто возникает, когда служба wcf перемещается из одного каталога в другой, а файл svc не обновляется... самым простым решением является двойная проверка вашего файла .svc и убедитесь, что определение службы правильно определено.

Ответ 14

У меня была такая же проблема, когда я загрузил свою рабочую службу localhost в новое место на хосте. Я создаю новый виртуальный каталог и публикую свою службу с помощью Visual Studio (FTP). Проблема решена.

Ответ 15

Мне тоже было так же, и решение создало поддельный "bin" и поместило в него dll. Затем обновите сайт на IIS и все

Ответ 16

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

Ответ 17

Первый раз, когда принимал приложение службы WCF, в IIS? Многие решали свои проблемы так или иначе. Однако, если все ваше решение правильное и ваша ошибка связана с размещением вашего приложения в IIS, тогда убедитесь, что ваш физический путь в IIS при добавлении вашего сайта указывается на каталог "bin" вашего решения, как показано ниже в снимках экрана.

Ответ 18

Посмотрите https://msdn.microsoft.com/en-us/library/ms733766(v=vs.100).aspx

Вам нужно сделать 2 вещи, чтобы иметь возможность размещать службу в IIS, или даже на Visual Studio, итерации IIS_EXPRESS.

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 он должен работать.