Идентичные типы в отдельных веб-сервисах - PullRequest
Новая
       22

Идентичные типы в отдельных веб-сервисах

4 голосов
/ 06 февраля 2009

У меня похожая проблема, как у этого вопроса . У меня есть несколько веб-сервисов, которые я использую с WCF, и все они имеют общие типы. Сами сервисы написаны на Java, и я не имею к ним доступа. Общие типы имеют одинаковые подписи, но svcutil.exe выдает эту ошибку при запуске: 

Error: There was a validation error on a schema generated during export:
    Source:
    Line: 8 Column: 3
   Validation Error: The complexType 'http://MyServer.MyService:CommonType' has already been declared.

С CommonType, имеющим одинаковую подпись в обеих используемых веб-службах. Вот как я звоню svcutil: 

svcutil.exe /o:GeneratedServices.cs /n:*,MyNamespace.Generated http://MyServer.MyService1?WSDL http://MyServer.MyService2?WSDL

Я знаю, что wsdl.exe имеет флаг /mergeTypes, который работает для этих служб, но есть некоторые опции на svcutil.exe, которые я действительно хотел бы использовать. У меня был кто-то, кто продемонстрировал, что это возможно для меня, однако бэкэнд также использовал .NET и WCF, и у меня не получилось с бэкэндом Java, который я использую.

Ответы [ 3 ]

5 голосов
/ 01 апреля 2009

Первый - они точно одинаковы? В частности, пространства имен SOAP должны совпадать (в дополнение ко всему остальному). Если они этого не делают, то это разные (несовместимые) типы; вам придется использовать 2 разные ссылки (в разных пространствах имен C #, чтобы избежать конфликтов) и перемещать данные между двумя типами.

Если типы одинаковы и все еще не работают, возможно, вы можете использовать ключ / r с svcutil для получения типов из существующей сборки. Попробуйте использовать его один раз, чтобы получить первые типы (только из одного из URL-адресов) - затем скомпилируйте этот код в сборку. Используйте svcutil для конечной точки second с флагом / r, идентифицирующим сборку, сгенерированную вами несколько минут назад.

Примечание; связанной темой является написание partial class для одного или нескольких типов - например, для предоставления методов / операторов преобразования для самих типов. Это может сделать вещи проще. Например, вы можете написать неявный (или явный) оператор статического преобразования между двумя похожими типами в разных пространствах имен.

0 голосов
/ 02 апреля 2009

Поскольку он существует в обеих службах, вы получаете два объявления после запуска svcutil для обеих служб. Я не думаю, что svcutil.exe достаточно умен, чтобы понять, что один и тот же тип существует в обеих веб-службах.

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

0 голосов
/ 01 апреля 2009

ОТВЕТ, РАСШИРЕННЫЙ ПРЕДОСТЕРЕЖЕНИЯМИ (и контекстом): И не забывайте, svcutil.exe - это всего лишь инструмент. Вы можете изменить или расширить сгенерированный код - нет запрета на него. Хотя, конечно, есть недостатки в настройке сгенерированного кода, и вы должны делать это только с широко открытыми глазами.

В прежние времена, когда я собирал разнородные клиенты и серверы вместе через веб-службы, я регулярно прибегал к изменению сгенерированного WSDL, изменяя код, сгенерированный из WSDL (я написал множество сценариев sed для замены пространств имен при подключении AXIS и .NET ) и другие индивидуально подобранные подходы. Некоторые из веб-сервисов, которые были самыми длинными, все еще требуют этого. Одним из примеров является MS Office Research Service, которая вообще не отправляет WSDL ...

Другой подход, который может работать, а может и не работать, - расширять сгенерированный код .NET с помощью частичных классов. Это отличный способ настроить пространства имен XML, добавить дополнительные элементы (например, строку версии?) И внести другие изменения. И когда вы заново сгенерируете код, ваши расширения не будут перезаписаны.

РЕДАКТИРОВАТЬ: Судя по downvote, некоторые люди думают, что это слишком рискованно !!! Я полностью понимаю.

...