問題タブ [shadow-copy]

大規模な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 構成 (既定の設定) のいずれにおいても、アプリ プールまたはアプリ ドメインの構成をオーバーライドすることはありません。
• モジュールの読み込みまたはアプリの起動が詳細に記録されている場所が見つかりません。

私たちの exe の多くは、B.dll を動的にロードします。B.dll は一時ファイルに自身のコピーを作成し、%TMP%\B-.dll をリロードします。このコードを使用して B-.dll を削除対象としてマークしようとしていますが、LoadLibrary 呼び出しが原因で、「アクセスが拒否されました」というエラーで失敗します。

ただし、ここ ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa363915(v=vs.85).aspx ) によると、これは可能である必要があります。

「DeleteFile 関数は、ファイルを閉じるときに削除するようにマークします。したがって、ファイルの最後のハンドルが閉じられるまで、ファイルの削除は行われません。」

WindowsサーバーOSで現在開いているファイルを閉じるときに削除するようにマークする方法についてのアイデアはありますか?

私はすでにTHISとTHISの質問を見ましたが、どちらも数年前のものであり、私の場合は別の解決策があるかもしれません:

THISに基づくプラグイン システムを備えた ASP.NET MVC 5 アプリケーションがあります。
したがって、私の~/binフォルダーはフレームワークによってシャドウコピーされ、上記のリンクで説明されているように、私のフォルダーはアプリケーションの初期化前に~/Plugins「手動シャドウコピー」を使用しています。 現在、次のケースがあるため、これはこれまでのところ問題なく機能していました。~/Plugins/ShadowCopy

AppDomainサンドボックス化されたコードを実行するために、別の制限を作成します。
アセンブリで定義された型を持つオブジェクトをこのドメインに渡すことができるようにするために、このドメインをApplicationBaseメイン ドメインのシャドウ コピー ディレクトリに設定します (そこからそれらをロードしない場合SerializationException、型/オブジェクトを 2 番目に渡すときにドメイン (この型を定義するアセンブリが別の場所から読み込まれるため)。

これで、「ベース アセンブリ」で定義された型をこの 2 番目のドメインに渡すことができます。
しかし、プラグインで定義されたタイプを使用したい場合、これは失敗します。これは、プラグイン アセンブリがデフォルトのシャドウ コピー ディレクトリではなく、「手動シャドウ コピー ディレクトリ」にあるためです。
また、このディレクトリもまったく別の場所にあるPrivateBinPathため、ベースパスの下にある必要があるため、追加できません。

現時点では、次の「回避策」を使用しています。

pre-init メソッドで。これにより、「手動シャドウ コピー ディレクトリ」がデフォルトのシャドウ コピー ディレクトリに追加され、プラグインもフレームワークによってシャドウ コピーされ、2 番目のプラグインはAppDomainそれらをロードでき、すべてが多かれ少なかれ機能しています。

しかし、SetShadowCopyPath廃止されたので、実際の質問
に行き着きました。廃止された方法を回避するためのより良い解決策を探しています。
私は次の解決策を考えましたが、それが可能かどうか/どのように可能かを知ることができませんでした:

1. プロパティを toおよびviaに設定AppDomainしてを作成するように IIS を構成します。AppDomainSetup.ShadowCopyDirectories~/bin~/Plugins/ShadowCopyweb.config
2. シャドウコピーディレクトリをegに移動し、~/bin/PluginsIISAppDomainにこのフォルダーのメインの変更をリサイクルしないように指示します（そうしないと、pre-initメソッドが毎回そこのファイルを変更するため、リクエストごとにアプリが再起動します）

別のアイデアは、「手動シャドウコピーディレクトリ」をデフォルトのシャドウコピーディレクトリの下に設定すること~/Plugins/ShadowCopyですC:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\69da84c5\cd056104\Plugins.

私は、この問題の解決策だけでなく、基本的な問題を解決するための別のアプローチにもオープンです。

同じプロジェクトに NUnit テストを含むコンソール アプリケーション プロジェクトがあります。

私はこの解決策を適用しようとしています。

実行時にソリューションは正常に機能しました。しかし、Resharper テスト ランナーまたは NUnit GUI ランナーでテストを実行すると、次GetExecutingAssembly().Locationのようなパスが返されましたd:\Temp\f4ctjcmr.ofr\nojeuppd.fmf\R2Nbs\assembly\dl3\9766f38e\b9496fb3_43cccf01\。
シャドウ コピーを無効にすると、両方のテスト ランナーの問題が修正されましたが、新しい問題が発生しました (NUnit Gui を閉じるまで、VS はプロジェクトをビルドできません)。シャドウコピーを無効にするよりも良い解決策はありますか?

更新: シャドウ コピーが有効になっている NUnit Gui で実行されているテストでEnvironment.GetCommandLineArgs()[0]返されます。C:\Program Files (x86)\NUnit 2.6.3\bin\

C ドライブのシャドウ コピーである 1 つのドライブ (L) にファイルを書き込む必要があります。以下のようにノーマルで試してみました。

しかし、それはエラーを出しています

System.IO.DirectoryNotFoundException: パス 'L:\DATA\ABC.DAT の一部が見つかりませんでした

具体的なアクセス方法があれば教えてください。

Assembly 1に次のコードがあります

mPluginDirectoryそして、私にあるAssembly2には次のコードがあります

アプリケーションを実行すると、Assembly2 がアプリケーション ドメインに読み込まれ、「Run」が出力されますが、ディレクトリmCachePathが空で、アプリケーションの実行中に Assembly2.dll を変更/削除できません。.net でシャドウを使用しないのはなぜですか使用するように言ったときのコピー機能。

私のニーズに合わせて、OpenCover と NUnit にいくつかの変更を加えています。

簡単に言うと、Nunit でシャドウ コピーが有効になっている場合でも、カバレッジ情報を取得したいと考えています。ただし、pdb ファイルが存在しない場合、OpenCover はアセンブリを追跡できません。NUnit でシャドウ コピーが有効になっている場合、テスト対象のアセンブリはシャドウ ディレクトリにコピーされ、OpenCover は対応する pdf ファイルを見つけることができません。

最初は、.Net ランタイムが pdb ファイルをシャドウ ディレクトリにコピーしていないだけだと思っていました。しかし、この問題をさらに調査したところ、ランタイムは pdb ファイルをコピーしますが、アセンブリがコピーされるのとは同時にではないことがわかりました。

私の理解では、ランタイムは最初にアセンブリをシャドウ ディレクトリにコピーします。そして、それらのアセンブリが読み込まれ、Opencover に通知されます。OpenCover は pdb ファイルがないことを検出したため、これらのアセンブリは無視されます。しばらくして、pdb ファイルがコピーされますが、OpenCover はこの事実に気付かなかったため、これらのアセンブリを追跡できませんでした。

私の質問は、.Net ランタイムが pdb ファイルをシャドウ ディレクトリにコピーする正確な時刻はいつですか? また、これらのシャドウ コピーされたアセンブリを追跡できるように、OpenCover を変更することは可能ですか?

私の C# コードでは、別のプロセスで使用されているファイルをコピーするために、シャドウ コピー メカニズムを使用できるようにしたいと考えています。

私は、ソリューションが Web、エンタープライズ ツール、またはコマンド ライン ツールに存在することを見てきました。しかし、単純なファイルのコピーを模倣するために、プログラムで実行できるでしょうか?

ロジックおよび UI レイヤーを含むいくつかの dll が参照されるメイン アプリケーション (Winforms) があります。winforms アプリケーションで自動更新を実行する方法について調査した結果、AppDomain と ShadowCopies 機能を使用した解決策を見つけました。別の実行可能ファイルが更新を探し、ファイルの交換を行います。

わかりましたが、今、次の状況になりました。

1. メイン アプリケーションを起動します (新しい AppDomain を介して読み込まれます)。
2. 参照されている dll ("ReferenceA") にあるフォームを開きます。この dll はコピーされ、コピーからインスタンス化されます。（偉大な！）
3. この時点で、システムは「ReferenceA」と「ReferenceB」の新しいバージョンの更新を受信し、ファイルの交換を行います。
4. 「ReferenceB」にある別のフォームを開きます。この dll はコピーからコピーされてインスタンス化されますが、この dll は、既にディレクトリにあるため、ShadowCopy によって更新されない "ReferenceA" も参照します。
5. 現在、システムは古いバージョンの「ReferenceA」とともに新しいバージョンの「ReferenceB」を実行しています。私のテストでは、「ReferenceA」に新しいメソッドを作成しましたが、明らかに「メソッドが見つかりません」というメッセージが表示されました。

これを解決する方法について何か提案はありますか?

Windows ボリューム シャドウ コピー SDK をインストールしようとしましたが、このリンクが表示されると、Windows 2003 および XP のみがサポートされます http://www.microsoft.com/en-us/download/details.aspx?id=23490

何が起こるかを確認するためにインストールを強制しようとしましたが、msvc 2010 で開発しました。

それは私にたくさんのエラーを与えます

vshadow SDK が wi​​n8 でサポートされていないということですか? それとも中止ですか？または私はそれをインストールするのが間違っていますか？