Проблема хостинга WCF IIS

Question

Я использую VSTS2008 + C# + .Net 3.5 для разработки службы WCF, размещенной в IIS 7.0/6.0. Я учусь по следующей ссылке MSDN,

http://msdn.microsoft.com/en-us/library/ms733766.aspx

Мой вопрос, предположим, что я реализую службы WCF внутри библиотеки классов и скомпилированы в какой-то конкретной DLL сборки. В файле svc службы, кажется, нет способа указать сборку, в примере MSDN указано только полное имя класса (включая пространство имен). Итак, как среда выполнения WCF обнаружила сборку, которая содержит фактическую реализацию сборки DLL на стороне сервера? Даже если я поместил сборку в подпапку bin виртуального каталога, и если в подкаталоге bin есть много DLL, как среда выполнения WCF знает, какая DLL содержит фактическую реализацию для конкретной службы WCF?

Answer 1

Marc прав относительно размещения имени сборки после пространства имен с запятой, чтобы отделить его: я могу подтвердить, что он работал для моей собственной службы WCF, когда я это сделал. Расширение «dll» не требуется.

Так звучит, как и ваша ошибка 404.3 происходит из-за чего-то другого. Я уверен, что раньше у меня был этот, хотя я не могу воспроизвести его, когда я пытаюсь сейчас. Но у меня есть ощущение, что это связано с разрешениями на папку в IIS - возможно, проверьте, не приведет ли проблема к расширению разрешений. Я думаю, что соответствующие пользователи будут IIS_IUSRS на вашей собственной машине, а может быть, и другие процессы, такие как NETWORK SERVICE (хотя я мог ошибаться в этом).

Другая вещь, которая приходит на ум, - это шифрование; Я обнаружил, что когда мои веб-папки были зашифрованы (со стандартным шифрованием Vista), они не могли быть правильно обработаны IIS и выдавали бы такие ошибки. Поэтому, если у вас есть шифрование этих файлов/папок, попробуйте отключить его.

Answer 2

(не работает - Я оставил это здесь просто для наглядности, так другой чтобы пользователи могли видеть то, что не работает)

Я должен проверить, но я абсолютно уверен, что следует обычный шаблон - так что вы могли бы также написать "Some.Namespace.Service, Some.Assembly.dll" (или если это не удается, попробуйте его с .dll с конца).

Я, кажется, помню, что здесь есть одно незначительное изменение ... обычно среда выполнения будет уважать [assembly:TypeForwardedTo(...)], но я не думаю, что WCF обрабатывает это, но в противном случае строки стандартного типа/dll должны работать.