2

ケース: WSDL 定義で使用される一般的なタイプ (Header、ApplicationError) を定義する一連の xsd ファイルがあります。各 Web サービスは、サービス固有のタイプの次に、これらの共有タイプの 1 つ以上をインポートします。

サービスのプロキシを生成するとき、サービス プロキシごとにこれらの共有型のコピーを取得し続けるので、これらを共有ライブラリに配置し、/reference を使用してこれらの型を含めることにします。これを機能させることができませんでした。

まず、プロキシを生成し、すべての *.xsd を含めると正常に動作し、コントラクトが生成されます。次に、xsd ごとに svcutil を /dconly パラメーターとともに使用しても機能しません。/XmlSerializer と /DataContractSerializer の両方。/importXmlType (または xsd.exe) のみが機能します。

次に、それらをクラス プロジェクトに配置し、生成されたコードを追加し、これをコンパイルして /reference パラメーターに使用すると、これらの型に対して生成されたコードが引き続き取得されます。

プロキシ用に生成されたクラスを使用しても、svcutil によって認識されません。

誰でもこのパターンの経験があり、おそらくこれらと同じ問題に遭遇したことがありますか?

XmlSerializer と DataContractSerializer の両方のエラー メッセージ svcutil /dconly /ser:XmlSerializer ApplicatieFout-v0200-b03.xsd

エラー: 名前空間 'http://schemas.customer.nl/ApplicatieFout-v0200' のタイプ 'ApplicatieFout' はインポートできません。要素 'FoutCode' のフォームは修飾する必要があります。型をデータ コントラクト型にマップできるようにスキーマを変更するか、ImportXmlType を使用するか、別のシリアライザーを使用します。

/dataContractOnly オプションを使用してデータ コントラクトの種類をインポートしていて、このエラー メッセージが表示される場合は、代わりに xsd.exe を使用することを検討してください。xsd.exe によって生成された型は、サービス コントラクトに XmlSerializerFormatAttribute 属性を適用した後、Windows Communication Foundation で使用できます。または、 /importXmlTypes オプションを使用してこれらの型を XML 型としてインポートし、サービス コントラクトの DataContractFormatAttribute 属性で使用することを検討してください。

4

1 に答える 1

1

私たちのサポート活動では、パターンを呼び出すのに十分な、あなたのようなリクエストをかなり頻繁に目にします。実際の XSD と WSDL を見ないと、(誰にとっても) 製品のバグに遭遇したのか、それとも他の何かに遭遇したのかを判断するのは困難です。

しかし、私が長年にわたって学んだことは、一般に、XSD とコードのバインディングを処理するツールは常に限られているということです。これらの制限を回避するための解決策は、XSD コンテンツと、WSDL がそのコンテンツをどのように使用する必要があるかを慎重に計画することから始めることです。WSDL と XSD を生成するプロセスを制御すると、より簡単になります。他のものを「継承」または「採用」するときは、独自のリファクタリングを適用します。

.NET では、あなたのケースに対する私の解決策は、コンポーネント化されたオーサリングに対する WSDL の仕様サポートに基づいたちょっとしたトリックを使用することです。と の 2 つのサービスの WSDL があるとしAbcますXyz。次のように「ラッパー」WSDL を作成します。

<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
    targetNamespace="http://services.paschidev.com/wrapper/usecase_a/1/" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
  <wsdl:import namespace="http://services.paschidev.com/service_abc/1/" location="AbcService.wsdl" />
  <wsdl:import namespace="http://services.paschidev.com/service_xyz/1/" location="XyzService.wsdl" />
  <wsdl:types />
</wsdl:definitions>

これをユーティリティにフィードします (Visual Studio 2010 の [サービス参照の追加] コマンドでこれを正常にテストしました)。これで完了です。

細かい点... これらすべてが高い成功率で機能するためには、結合するすべての WSDL が次の規則に従う必要があります。共通の XSD は共通のソースから取得する必要があります。

サービスが同じものをAbc必要{urn:paschidev-com:xsd:common:1}somethingとする場合、aは両方の WSDL で同じソース URI から取得する必要があります。Xyz{urn:paschidev-com:xsd:common:1}something

テストは私にとってかなり単純です。私はQTAssistantの (私はそれに関連付けられています) Extract XSDsコマンドを使用して、ラッパーWSDL をポイントします。プロンプトが表示されたら、XSR プロジェクトを作成させます。生成された XSD から作成されたコレクションが正常にコンパイルされる場合、重複する XSD 定義がないことを意味します。コンパイルで「既に定義されている」エラーが発生した場合、レポートには、どの XSD コンポーネントが重複しているか、つまり、2 つ以上の異なるソース Uris から来ているかが示されます。各コンポーネントをリファクタリングして、1 つのソース URI を保持します。その後、再試行してください。

場合によっては、XSD を正しく取得しても、svcutil または xsd が停止することがあります。それが発生した場合、それはラッパーとは関係のないものです。このラッパーがなくても明らかになります。つまり、リファクタリングが発生する前に、個々の WSDL が単独で適切に機能することを確認することを常にお勧めします。

于 2012-05-27T13:36:30.837 に答える