Silverlightで別のWCFプロジェクトを使用する
質問
WCFを使用するSilverlightアプリケーションで作業しています。 SilverlightプロジェクトをホストするASP.Netアプリケーションとは別のWCFプロジェクトが必要です。ソリューションを整理し、デバッグと展開中に他の人が経験した落とし穴をリストする方法に関するガイダンスを探しています。
特に私の質問は
-
WCFサービスに使用するプロジェクトの種類(WCFプロジェクト、自己ホスト型WCFサービスを備えたASP.NETプロジェクト、その他)
-
F5キーを押したときに、SilverlightプロジェクトとWCFサービスの両方をデバッグできるようにするには、何が必要ですか?デバッグするためだけにクロスドメインポリシーが必要ですか?
これを行う理由に関する背景情報:
レガシーWebアプリケーションがあり、それを徐々にSilverlightアプリケーションに変換しています。大規模なWebアプリケーションであるため、一部の機能は他の機能より先にSilverlightに変換されます。
レガシーWebアプリケーションには、使用されなくなった多くのコードが含まれています。使用されなくなったコードの多くは、サードパートアセンブリを参照しています。これが、古いWebアプリケーションを削除する理由です。したがって、明らかに、将来のバージョンで保持されるWCFサービスをホストしたくありません。これが、WCFプロジェクトを個別にしたい理由です。
解決
まったく同じことをしています。
- 将来のホスト方法を変更する必要がある場合に備えて、WCFプロジェクトを使用しています。 (つまり、IISを使用しなくなった)
2.a。 silverlightプロジェクトとwcfプロジェクトでソリューションを作成できます。 silverlightプロジェクトには、ソリューションのwcfサービスへのサービス参照があります。これにより、F5を使用してデバッグできます。ただし、展開する場合は、app.configサービスのURIを変更して、運用場所を参照する必要があります。
2.b。完全修飾ドメイン名がwcfサービスとsilverlightアプリで異なる場合にのみ、クロスドメインポリシーファイルが必要になります。私たちのものはたまたま違うものです。ポリシーファイルを使用するタイミングに関する優れた記事を次に示します。 Clicky
がんばって!
他のヒント
展開の準備ができたときに、サービスをアプリとは異なるマシンでホストする場合は、最初にサービスを展開する必要があることを忘れないでください。次に、サービス参照を再構成し、展開する前に最終的にSilverlightを再コンパイルします。それ以外の場合、Silverlightアプリは、展開先ではなくローカルマシンでサービスを探します。