多くの不満の末、私は両方の web.config ファイル (クライアントとサーバー上、この場合はどちらも Web アプリ) で、次のセクションを変更する必要があることを突き止めました。
クライアント:
<client>
<endpoint
address="http://mysite.com:port/services/someservice.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISomeService"
contract="MyServices.ISomeService"
name="BasicHttpBinding_ISomeService" />
</client>
</system.serviceModel>
サーバ
<system.serviceModel>
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://mysite.com:port/services"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
<behaviors>
<serviceBehaviors>
<behavior name="MyServices.SomeServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MyServices.SomeServiceBehavior"
name="MyServices.SomeService">
<endpoint address="http://mysite.com:port/services/someservice.svc"
name="endpoint.SomeService"
binding="basicHttpBinding"
bindingConfiguration=""
contract="MyServices.ISomeService"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
ここで注意すべきことは、関連する 3 つのセクション (クライアント エンドポイント アドレス、サーバー baseAddressPrefixFilter 値、およびサーバー エンドポイント アドレス) のすべてのホスト アドレスが一致する必要があることです。
これらが一致する限り、これらを変更することでサーバーを切り替えることができます。サーバーが実行されているマシンに基づいてこれを設定する方法を引き続き希望しますが、これは今のところ機能します。
WCF インプレッション 話題
: 永続オブジェクト。クライアント プロキシ オブジェクト (サービス参照を追加するときに作成される) は、サーバー上のサービスへの永続的な接続を維持します。クライアント プロキシによって参照されるサービス インスタンスは、呼び出し間でその状態を維持します。これにより、メソッド シグネチャが簡素化され、クライアント プロキシ オブジェクトとサービス全体が、特定のアプリケーションにとってより便利になります。パラメータ オブジェクト タイプは、共通ライブラリで宣言されている場合、クライアントとサーバー間で共有できます。つまり、非プリミティブ データ構造をやり取りするために 2 つの非常に類似したクラスまたはラッパー クラスを作成する必要はありません。
問題はありません: 構成は非常に面倒な作業であり、文書化も不十分であり、あまりにも複雑です。サービスがその場所を認識する必要があるテスト/開発/ステージング/本番環境構成でこれを機能させるのはイライラします。セキュリティ上の懸念はさておき、サービスがそのドメイン URL を認識できるようにすること (たとえば、サービスが実行されているものへの相対パスではなく) に大きな利点があるとは確信していません。
とは言うものの、これまでの利点が頭痛の種を上回っているので、私は WCF の道をたどり続けています。