WCF не в состоянии генерировать прокси клиента

Question

У меня странная проблема, которую я просто не могу диагностировать, и кажется, что это проблема PEBCAC, но я потратил немало времени, пытаясь ее решить.Я создал службу WCF, которую я размещаю через службу Windows.Некоторое время этот сервис работал нормально, и у меня есть формы Windows и веб-интерфейс.Сервис изначально разрабатывался на XP, но я недавно перешел на Windows 7. Когда я мигрировал, я обнаружил, что безопасность Windows для сервиса помешала мне использовать мое приложение WinForms на Windows 7, но на XP он работал нормально, общаясь сслужба на Windows Server 2008 R2, Windows 7 и XP.Чтобы упростить работу во время разработки, я полностью отключил защиту, и мое приложение WinForms снова работает на windows7.

Затем я внес некоторые другие изменения в службу WCF, добавив методы, изменив контракты данных и т. Д.изменения конечной точки должны были отключить безопасность на wshttp.Неожиданно при обновлении ссылки на службу для веб-приложения клиентский прокси больше не создается, а генерируются файлы wsdl и xsd.Я пробовал многочисленные комбинации старых и новых сервисов на XP и Win7, в результате чего:

1. Старый сервис прекрасно работает при обновлении ссылки, работает ли он на XP или Win7 и работает ли в ИнтернетеКод приложения установлен на XP или Win7.
2. Новая служба не создает прокси-сервер, независимо от того, запущен ли он на XP или Win7, а также на том, работает ли код веб-приложения на XP или Win7.Я не получаю ошибок при обновлении справочника услуг, однако файлы configuration.svcinfo и configuration91.svcinfo не содержат описаний поведения, привязок или конечных точек.Остальные файлы выглядят нормально.
3. Я могу использовать svcutil для получения метаданных и генерации прокси-кода с использованием новой версии службы.
4. Когда ссылка на службуобновлено, я получаю два элемента, являющихся частью контракта данных, которые отображаются в обозревателе объектов, но только один из них является правильным.Я не получаю ни клиента, ни других объектов контракта данных.
5. Самое главное, что приложение windows form работает отлично с новой службой, включая обновление ссылки и вызов методов службы.Да?

Я посмотрел определения служб, поведения и конечных точек в новой службе, и они совпадают со старой.Ничего в Интернете, что я не мог найти ссылки на такую ​​ошибку.Я понимаю, что, должно быть, я что-то не так делаю в новом коде, но поскольку он отлично работает с приложением WinForms, я затрудняюсь объяснить разницу.

Любая помощь будет принята с благодарностью.Возможно, я смогу сохранить часть своих волос;)

-Edit-

Прочитав ответ, я провел еще несколько исследований и попробовал еще несколько вещей:

Я посмотрел на файлы xsd и т. Д. Для службы без обеспечения безопасности, а также после восстановления вещей в том виде, в каком они были в терминах перечислений верхнего уровня с атрибутом DataContract (не имеют ни одного из них), а также восстановленияценности безопасности к тому, что они были.В обоих случаях я не вижу ничего плохого, за исключением того, что файлы называются по-разному: старая ссылка на службу использует файлы xsd с числовыми суффиксами в диапазоне от 2 до 5, тогда как в последней используется 1–4 (не вижу, что это должновлияет на вещи, так как указатели в svcmap кажутся правильными).Это усложняет анализ, но я подробно рассмотрел каждый файл, и данные кажутся правильными, просто помещаются в разные файлы.

Файл wsdl после восстановления безопасности до старых значений идентичен, за исключением IP-адреса хоста и имени компьютера, как и ожидалось.Но все же configuration.svcinfo и configuration91.svcinfo не имеют определенных конечных точек, поведения или привязок.Также, как ни странно, из двух контрактов данных, которые действительно определены, один имеет только нового члена: его члены данных не присутствуют.Это контракт данных, который ссылается на класс, помеченный как Serializable, но не указанный в атрибуте DataContract.Единственное, что изменилось, это то, что я добавил в класс один новый строковый член.Еще более странным является то, что в файлах xsd существует правильное определение класса контракта данных.

Я очень запутался.

Answer 1

Да, возможно, у вас есть ссылка на сборку контрактов из вашего приложения, и когда вы генерируете свой прокси с помощью «Добавить ссылку на сервис ...», вы повторно используете типы в ссылочных сборках, и именно поэтому ваши контрактные объекты не генерироваться. Чтобы исправить это, когда вы добавляете ссылку на сервис, я рекомендую вам нажать кнопку «Дополнительно», а затем снять флажок «Повторное использование типов в ссылочных сборках» или просто удалить ссылку сборки контрактов из вашего приложения.

Я надеюсь, что это сработает для вас!

Answer 2

Что ж, после долгих размышлений я в конце концов понял это.Проблема была вызвана тем, что я использовал ту же сборку в веб-приложении, что и в службе (я использовал другую часть сборки в веб-приложении).Это привело к тому, что класс, который является частью контракта на данные, и который я изменил, чтобы использование службы отличалось в скомпилированной сборке веб-приложения от публикации службы.Это, в свою очередь, привело к сбою ссылки на службу для создания клиентского прокси.Без клиентского прокси-кода мой код веб-приложения показывал ошибки, поэтому я никогда не пытался скомпилировать решение.Простой ответ состоял в том, чтобы построить только общую сборку в веб-приложении (которая работает), а затем ссылка на службу сгенерировала прокси правильно.Представьте, как я был озадачен тем, что единственный член данных класса был очевидной причиной проблемы, но его имя, тип данных, позиция в коде и т. Д. Не оказали влияния на проблему!В любом случае, вероятно, плохой дизайн для повторного использования этой сборки - вероятно, лучше использовать эту информацию из самой службы.В заключение, причина того, что приложение winform работало, заключалась в том, что я также использую ту же сборку в приложении winform, и она всегда поддерживалась в актуальном состоянии, когда я компилировал приложение, поэтому изменения никогда не конфликтовали.Надеюсь, это поможет кому-то в будущем.Как примечание для Microsoft - любая информация об ошибке в этом конфликте очень помогла бы в устранении неполадок, хотя я допускаю, что это, вероятно, не обычный сценарий.

Answer 3

Это длинный выстрел, но что происходит, когда вы сравниваете сгенерированные xsds?Различия, которые вы ожидаете, или есть какие-то странные изменения в них, которые не имеют смысла?Я спрашиваю, потому что мы обнаружили, что некоторые изменения контракта, которые включают перечисления на верхнем уровне операции, заставляют wsdl.exe вести себя по-другому.Казалось, что он использует XmlSerializer вместо DataContractSerializer, у которого было много побочных эффектов, таких как изменение типов со списков на массивы.Однако я не помню, была ли проблема с генерацией клиентского кода.