Веб-сервис.Net Consuming: Идентичные типы в двух различных сервисах
Таким образом, наши соображения были правильными, это действительно ошибка.
Я публикую ответ для справки.
Здесь выпуск , который вы открыли.
blockquote>Это было закрыто авторами как дубликат этого одного .
Это точно подтверждает, что это ошибка.
Как я уже сказал в своем комментарии, я могу подтвердить, что на физическом устройстве с API уровня 19 все работает нормально.
5 ответов
То, что закончило тем, что работало на меня, должно было предоставить svcutil.exe все адреса WSDL, от которых я должен был сгенерировать код. SVCUTIL посмотрит на все типы от каждого сервиса и определит автоматически, которые распространены и должны быть снова использованы.
Тип, что Вы хотите быть совместно использованными, должен также иметь общее пространство имен, и то пространство имен должно быть вызвано на каждом из веб-сервисов, которые хотят совместно использовать тот тип.
инструмент WSDL имеет параметр.
/sharetypes
Turns on type sharing feature. This feature creates one code file with
a single type definition for identical types shared between different
services (namespace, name and wire signature must be identical).
Reference the services with http:// URLs as command-line parameters
or create a discomap document for local files.
Можно поместить пользовательский тип в общий общий блок что и сервисы и клиентские ссылки проекта. Затем в конфигурации для обоих сервисных клиентов, можно выбрать опцию многократного использования типов в блоках, на которые ссылаются. Тем путем Вы используете тип inthe блок, а не отдельно сгенерированный класс.
Это - общая ситуация при потреблении веб-сервисов с различными конечными точками от того же поставщика.
Можно использовать "wsdl.exe/sharetypes" инструмент командной строки для создания общего прокси-класса, который посмотрит на все конечные точки, которые Вы обеспечиваете и выводите, какие классы могут быть 'совместно использованы'.
В Вашем примере пока Ваш пользовательский объект идентичен в обоих сервисах, он будет взят и включал в Ваш новый общий прокси-класс.
Вероятно, имеет смысл добавлять этот общий шаг поколения прокси-класса как событие сборки в Вашем проекте таким образом, это всегда актуально.
Если вы работаете с локальными файлами, вы можете сделать следующее:
wsdl.exe /sharetypes file://c:\path\to\file.wsdl file://c:\path\to\otherFile.wsdl /namespace:<your namespace> /output:(any switches etc...)
Переключатель sharetypes требует, чтобы вы указали URL-адреса службам, и не работает, если вы просто указываете wsdl на файлы.