1

同じ Windows 2003 開発サーバーでホストされている Web アプリケーションと WCF サービスがあります。それぞれに、drs.displayscreen.web および drs.displayscreen.service ホスト ヘッダーにそれぞれ応答する独自の IIS Web サイト ノードがあります。hosts ファイルには、127.0.0.1 を指す両方のヘッダーのエントリが含まれています。Web サイトには、drs.displayscreen.service へのサービス参照があります。

アプリケーション プールが「ネットワーク サービス」アカウントを使用する場合、両方のアプリケーションは完全に機能します。

サービスの内部で COM 処理を実行する必要があるため、カスタマイズされた ID でアプリケーションを実行したいと考えています。両方のサイトが新しいアプリケーション プールで実行されます。

この目的のために作成された新しい Windows アカウントを使用するようにアプリケーション プール ID を変更すると、次の (内部) 例外が発生します: [EndpointNotFoundException: Could not connect to http://drs.displayscreen.service/Handler.svc . TCP エラー コード 10060: 接続先が一定時間後に適切に応答しなかったために接続試行が失敗したか、接続されたホストが 192.168.98.2:8080 に応答しなかったために確立された接続が失敗しました。]

192.168.98.2:8080 は、使用されなくなった DNS サーバーのアドレスです。ソリューションのどこにも参照されていません。ipconfig からはまったく参照されません。

新しいアカウントが IIS_WPG のメンバーであることを確認し、 aspnet_regiis -ga を実行しました。また、ホスト ファイルを読み取るための明示的なアクセス許可をアカウントに付与しました。

アプリケーションがホスト ファイル エントリではなく、機能していない DNS サーバーを使用して一時 URL (drs.displayscreen.service) を解決しようとするのはなぜですか? ネットワーク サービス アカウントで実行している場合、この問題は発生しないため、何らかの権限が必要です。ヘルプ！！

4

1 に答える 1

1

その答えには、.Net フレームワークのバグが関係しているようです。SocketCache.GetSocket の MS .Net 実装が無効なソケットをキャッシュする可能性があるという事実と、明示的な don't-use-proxies 構成設定の形での回避策/ハックを示唆する別のブログ投稿を見つけました。 .

この問題が発生した環境では実際にプロキシ サーバーを使用していませんが、don't-use-proxyes 設定が有効な場合、SocketCache.GetSocket がオーバーライドされるか、動作が異なるようです。不思議なことに、設定を削除すると問題が再発するため、有効な IP/ホスト名が検出され、正常に使用されたときに SocketCache が修復されないことは明らかです。上記の最初の投稿の著者によると、このバグは Mono には存在しません。:)

于 2009-02-19T12:37:22.753 に答える