1

大規模なasp.net 4アプリケーションで非常に奇妙な問題が発生しています。IIS は、シャドウ コピーの場所からではなく、dll の元の場所である bin ディレクトリからモジュールをロードすることがあります。

IIS モジュールの読み込みがどのように機能するか、またこれが正常な動作なのかバグなのかを知っている人はいますか?

これが私たちに引き起こしている問題

  • 開発中。それぞれの dll は bin フォルダーにロックされます。つまり、msbuild はビルド時にそれを置き換えることができません。
  • これにより、nhibernate queryovers で TypeMismatchException が発生する、特に厄介な (そして見つけるのが難しい) 問題 (ハックで回避しています) が発生しています。

ノート

  • Win7 および WinServer2008R2、IIS 7.5、MVC3、MVC4、WebForms、WebApi を使用する複数のプロジェクトで実行される ASP.NET 4 アプリケーション
  • VS デバッガーをアタッチし、ロードされたモジュールを検査することによって得られるモジュール情報
  • IISRESET を実行して一時 asp.net ファイル フォルダーをクリアし、アプリケーションをスプールすると、dll がすべてシャドウ コピーの場所にコピーされ、そこから読み込まれます。次にIISRESETを再度実行してアプリケーションをスプールすると、モジュールはシャドウコピーの場所ではなくビンの場所からロードされます
  • これは、エントリ ポイントが常にシャドウ コピーの場所から読み込まれる Web プロジェクトのプロジェクトの依存関係にのみ影響します。IE Proj.Webはシャドウ コピーの場所から読み込まれ、そのProj.BusinessLogic & Proj.DataAccessのプロジェクト依存関係はbin フォルダーから読み込まれ、外部の依存関係 (automapper、glimpse など) はシャドウ コピーの場所から読み込まれます。
  • コード、web.config、または IIS 構成 (既定の設定) のいずれにおいても、アプリ プールまたはアプリ ドメインの構成をオーバーライドすることはありません。
  • モジュールの読み込みまたはアプリの起動が詳細に記録されている場所が見つかりません。
4

1 に答える 1

1

数週間前にこの問題の根本原因を発見し、今投稿して、似たようなことで苦しんでいる人を助けることを願っています.

私たちの開発者の何人かからしばらくの間、私たちは、これが nhibernate 構成の dll をスキャンしていた方法による自傷行為であることを発見しました。

コードから dll を明示的にロードしていたとき、Assemblyヘルパー メソッドを誤用していました。を使用する代わりに、 を使用しAssembly.LoadFrom(assemblyPath)ていましAssembly.LoadFile(assemblyPath)た。これらの方法には多くの違いがあります。ここで関連するのはLoadFile()、指定されたファイルをロードするのに対しLoadFrom()、一時、キャッシュ、GAC などの他の場所からアセンブリを見つけるためのロジックを適用することです。違いの詳細については、この質問を参照してください。

とにかく、この 1 行のコードを変更しただけで、すべての問題が解消されました。

于 2015-01-19T07:03:33.453 に答える