WCF и общая справочная библиотека между клиентом и сервисом
Visual Studio и SvcUtil могут использоваться для генерации прокси-кода для интеграции со службой. В VS 2010 и более ранних версиях были проблемы, если вы хотели поддерживать многоуровневую библиотеку ссылок общих типов. Это заставило несколько обходных путей решить проблему эквивалентности типов контрактов данных и невозможности правильно использовать локальные типы.
Ссылка URL на проблему: Генерация клиентского кода WCF - проблема с "Повторное использование типов из ссылочных сборок"
Я использую Visual Studio 2012, ASP.NET 4.5, код C#
Мой вопрос: "Исправлено ли повторное использование типов в сборках в VS 2012?" Сейчас я портирую какой-то код, но также обеспокоен тем, что эта ошибка может привести к ошибкам. Я могу запустить контрольные примеры, но было бы быстрее, если бы у кого-то уже был ответ. По моему опыту, если вы не можете найти ответ в Интернете (погуглили его и продолжаете получать 2011 год - проблема все еще существует), что это исправление может отсутствовать.
Моя цель: позволить моей будущей команде разработчиков повторно использовать одну и ту же библиотеку типов на всех корпоративных уровнях и уровнях приложений.Net [Презентация (веб-сайт, уровень мобильных приложений - на стороне сервера,...), домен (службы, уровень бизнес-логики, доступ к данным) Слой)]. Я хотел бы обеспечить некоторую однородность и повторное использование кода. Код будет максимально "слабо связанным" на каждом уровне, но типы будут обеспечиваться через эталонную сборку. Точно так же я хочу, чтобы код поддерживал внешнюю интеграцию для третьих сторон в будущем. Таким образом, мне необходимо создать все прокси-типы из декорированных типов DataContractAttribute для внешних служб и поддерживать ссылочные типы для моих приложений на стороне сервера.
Собираюсь ли я столкнуться с трясинами здесь? Проблема в ссылке выше была решена? Пожалуйста, порекомендуйте.
2 ответа
Ошибка, о которой вы сообщаете как существующая в параметре " Повторное использование типов из ссылочных сборок", возникает потому, что при повторном использовании вызовов VS svcutil.exe изнутри с флагом /r.
Тем не менее, svcutil.exe использует DataContractSerializer чтобы помочь сгенерировать код, и, к сожалению, он имеет довольно строгий набор правил, когда дело доходит до разбора ваших сервисных контрактов.
Поэтому, если вы не обслуживаете XSD, придерживайтесь этого набора правил, svcutil.exe переключится на использование XmlSerializer, который не поддерживает флаг /r (или повторное использование). Следовательно, вы не сможете повторно использовать типы.
Если вы можете ссылаться на фактические типы контрактов на обслуживание (через двоичную ссылку), это гораздо лучшее решение, так как вы можете отказаться от ссылок на сервисы вместе. Вы также можете использовать WSCF.blue для генерации контрактов на обслуживание, так как он имеет собственный настраиваемый сериализатор и поддерживает повторное использование типов.
В моей ситуации и WebService, и WebApp ссылались на одну и ту же сборку, содержащую сущности домена. Естественно, каждая сущность была украшена DataContractAttribute, но при создании ServiceReference в WebApp с использованием конечной точки, предоставляемой WebService, Reuse Type in Referenced Assemblies было, по-видимому, проигнорировано VS2012, что привело к дополнительным копиям типов в локальной сборке. Затем (после нескольких часов проб и ошибок) я добавил параметр Namespace в ServiceContractAttribute моего интерфейса в WebService. После добавления обработанная ссылка ServiceReference начала ссылаться на мой shared Типы DataContract по желанию.
[ServiceContract(Namespace="http://www.example.com/Demo.WebService/")]
public interface IConfigurationService { ..methods here.. }