Общие типы WCF не используются повторно

Ответ 1

Ссылка на общую сборку перед добавлением служебной ссылки не работает

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

Удаление и повторное добавление ссылки на службу (или ссылка на общую сборку) не помогло

и вам не нужно будет этого делать, но я бы тоже попробовал.

Для того, чтобы "повторное использование" работало, оба проекта (клиент и служба) должны использовать одну и ту же версию сборки. Вы ссылаетесь на проект, и это хорошо. Я встречал это раньше, когда ссылаюсь на сборку напрямую из-за разных версий.

Вот еще несколько вещей, чтобы попробовать

• Откройте "Configuration Manager" для своего решения - убедитесь, что общая сборка настроена на сборку.
• Убедитесь, что вы используете ссылку на проект как для клиента, так и для службы - использование последней сборки на клиенте не поможет, если служба использует более старую версию.
• Удалите ссылку на проект и создайте, и ожидайте, что сборка завершится неудачей - если она не сработает, вы должны ссылаться на что-то еще.
• Вручную проверьте, что последняя сборная сборка включена в сборку как в службе, так и в клиенте - проверьте папку bin, проверьте дату сборки/дату сборки.

Если все остальное не удается, лучший способ заставить один и тот же объект с обеих сторон - полностью удалить прокси-сервер "service reference" и использовать метод ChannelFactory. См. Упрощенное объяснение того, как сделать вызов службы WCF без добавления справки по сервису и VS2010. Преимущества добавления ссылки на службу по прямой ClientBase < gt;;. Это мой предпочтительный шаблон WCF, поскольку он устраняет необходимость "Обновить ссылку службы..." и удаляет все созданные сгенерированные прокси-коды.

Ответ 2

Я просто провел целый день, пытаясь выяснить, почему типы в моей общей DLL не использовались повторно, когда я добавил ссылку на службу в VS2013. Оказывается, у службы было несколько проблем, связанных с сериализацией. У меня было несколько перечислений, у которых не было атрибута EnumMember. То, как я решил свои проблемы, - это выполнить следующие шаги:

• Комментирование всех операций (методы, украшенные атрибутом OperationContract) в моем ServiceContract, который не возвращал атомные типы.
• Затем обновить ссылку на службу в моем проекте клиента. Я понял, что проблема была решена, когда в моем клиентском проекте я смог напечатать "[MyServiceReferenceName]". и мои типы не отображались в пространстве имен [MyServiceReferenceName]. Я проверил это, открыв созданные XSD файлы в браузере XML Schema, чтобы быть уверенным.
• Один за другим раскомментировать метод, который был прокомментирован на шаге 1. Затем обновите свою ссылку на службу каждый раз, чтобы узнать, сохраняются или не сохраняются типы.
• После того, как вы найдите метод, который вызывает ссылку на службу, чтобы не использовать типы, перейдите к каждому классу для типов, которые вводятся или выводятся в метод. Убедитесь, что все классы, которые вы хотите сериализовать, украшены атрибутом [DataContract]. Убедитесь, что все поля и свойства украшены атрибутом [DataMember]. Кроме того, убедитесь, что перечисления украшены [DataContract] и что каждое значение перечисления украшено [EnumMember].

Я надеюсь, что это поможет другим, кто переживает этот разочаровывающий процесс, и эта проблема не обязательно связана с общей dll. Моя проблема не была проблемой при использовании Add или Update Service Reference. Проблема заключалась в том, что мои объекты (модели) не были украшены соответствующими атрибутами, чтобы уведомить DataContractSerializer о сериализации этих типов. Похоже, что если какая-либо часть сериализации не удалась, добавление Service Reference добавляет все типы.

Ответ 3

Это немного длинный снимок, но одна из возможностей заключается в том, что старая версия общей DLL находится в GAC.

Он пытается использовать общую dll, находит DLL с отсутствующими типами, а затем возвращается к созданию типов.

Ответ 4

OBJECTCEPTION!

Недавно у меня была такая же проблема, когда я работаю. Нам потребовалось четыре часа, чтобы выследить проблему, но в итоге мы обнаружили, что перечисление на объект в той же DLL, что и объект, который он отказывал копировать, имеет то же имя, что и другое перечисление, которое используется в службе, поэтому оно отказался повторно использовать любые типы из этой DLL.

Предложение (решение?): Убедитесь, что в DLL нет объектов, объектов на этом объекте или... и т.д. которые имеют то же имя, что и одно из ваших услуг.