次のことを考慮してください。BizTalkプロジェクトがあり、その内部にメッセージのxsdスキーマを配置しました。 これらのスキーマは名前空間 "A"にあります。私は別のWebサービスを持っている、それは名前空間 "A"と一緒にdatacontractを使用する。 したがって、Biztalkである最初のプロジェクトにサービス参照を追加すると、VSは2番目のプロジェクトにあるdatacontractsのスキーマを生成します。 したがって、同じ名前空間とルート要素を持つ2つのスキーマがあります。BizTalkメッセージとWCFサービスの間のxsdsのネームクラッシュを回避する方法dataacontracts
OK私は今あなたの問題を見ることができると思います。私の質問は、なぜあなたは最初の場所で名前の衝突を持っていますか？生成されたスキーマがサービスの実行中のインスタンスから生成された場合、独自のスキーマをコーディングする必要はなく、生成されたスキーマを使用することができます。
これは別の方法でも理解できます。開発したスキーマは、異なる目的のためのものですが、生成されたスキーマと同じルートノード名と名前空間を共有しているだけです。この場合は、ターゲット名前空間および/またはルートノード名を変更して、生成されていないスキーマをリファクタリングする必要があります。
BizTalk Serverのメッセージ間でターゲットの名前空間を決して再利用しないことをお勧めします。実際には、ソリューションをビルドするときに、コンパイラは警告を出します。
これは可能ですか？
真実を伝えるために私はすでに使用しているサービスのdatacontractsの名前空間を変更し、問題を修正しました。しかし、私はまだa）BizTalkで動作するメッセージタイプを定義し、b）WCFサービスで使用するためにそのメッセージのdatacontractsを定義するための最良の方法が何であるかを知りたい。 –
WCFサービスでdatacontractsを生成するときに、ビッツトークの側面について考えるべきではありません。 Biztalkは、あなたのサービスと通信するために必要なすべてのビズトークメッセージを生成します。多分私はあなたの質問のポイントを完全に見逃していますか？ –
あなたは気にしませんが、私はあなたの投稿に名前を変更しました。もしあなたが私に反対するなら、私はそれを元に戻します。 –