7

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

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

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

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

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

#pragma warning disable 0618
        AppDomain.CurrentDomain.SetShadowCopyPath(String.Join(";", 
           HostingEnvironment.MapPath("~/bin"), 
           HostingEnvironment.MapPath("~/Plugins/ShadowCopy")));
#pragma warning restore 0618

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.

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

4

0 に答える 0