0

サイトをさまざまな環境に何度も正常に展開してきましたが、RIA サービスのセットアップに関連していると思われる問題が発生しました。Windows Server 2008、64 ビット マシンに展開しています。

基本的に、WCF RIA サービス エンドポイントを呼び出すことができず、常にサーバーから 404 が返されます。「生の」svc エンドポイントにヒットして、標準の自動生成ページを受け取ることができますが、メソッドを呼び出そうとするたびに 404 を受け取ります。

明確にするために、次の URL は標準の自動生成されたサービス ページを返します。

http://localhost/ClientBin/Our-Namespace-DomainService.svc

次の URL は単純に 404 を返しますが、

http://localhost/ClientBin/Our-Namespace-DomainService.svc/binary/GetSchemaVersions

stackoverflow で多くの検索を行いましたが、役に立ちませんでした。IIS を完全に再インストールするという基本的な作業を行いました。aspnet_regiis が呼び出されていることを確認し、svc mimetype が正しく登録されていることを確認し (これは、返された「生の」ページによって明らかになるはずです)、WCF アクティベーション登録を行い、SERVER=TRUE でサーバーに RIAServices をインストールしようとしました (私たちはbin はデフォルトで RIA のものをデプロイします)。サイトには、正常に動作する「純粋な」WCF である追加のサービス エンドポイントもあります (これも *.svc URL を使用)。ログにエラー メッセージは表示されず、Fiddler と IIS のログには 404 が返されたことが示されています。前述のように、最近、これを同様の環境 (同じ OS、64 ビットなど) と思われるものにデプロイしました。

現在、上記のやや奇妙な URL 構文 (ファイルの後にパス セグメントがある) が IIS パイプラインによって正しく解釈されていないと考えていますが、何が起こっているのかを理解する手がかりを探しています。

コードが適切に実行されない方法/理由を理解するための経験、洞察、または方法は大歓迎です。

4

1 に答える 1

2

私たちは最終的にこれを自分たちで理解し、将来の参考のためにここに答えをすぐに追加しました.

私たちの問題は、IIS 内のハンドラー マッピングの順序付きリストで、ExtensionlessUrlHandler が SVC ハンドラーの前に順序付けられていたことです。ExtensionlessUrlHandler の前に SVC ハンドラーを移動すると、再び機能するようになりました。

この順序がどういうわけか異なるようになった理由を現在調査中ですが、それは別の話です

于 2013-05-01T12:09:33.140 に答える