0

私は、ASP.Net アプリケーション、2 つの異なる Win32 サービス、およびその他の sysadmin 関連アプリケーションで構成されるアプリケーションのビルド プロセスを維持しています。

デバッグと展開の両方で使用される次の構成で終わりたいと思います。

libraires/    -- Contains shared assemblies used by all other apps.
web/          -- ASP.Net site
service1/     -- Win32 service 1 (seen under the service control manager)
service2/     -- Win32 service 2 
adminstuff/   -- Sysadmin / support stuff used for troubleshooting

問題は、app.config 内の privatePath をプローブするアセンブリが、アプリケーション ルート外の相対ディレクトリをサポートしていないことです。つまり: ../libraries は使用できません。とてもイライラします...

アセンブリに厳密な名前を付ける場合、絶対パスをサポートしているように見える codeBase 構成要素を使用できますが、各アセンブリを個別に指定する必要があります。

また、AppDomain.AssemblyResolve イベントにフックしようとしましたが、Main() でイベント ハンドラーを登録する前に、.Net Fusion から FileNotFoundException を取得しています。

アセンブリを GAC に登録するという考えは好きではありません。アプリケーションのデプロイ / アップグレードに手間がかかりすぎます。

必要な各アセンブリのパスを指定せずにこれを行う別の方法はありますか?

4

2 に答える 2

2

あなたのアプローチは、最悪の種類の DLL 地獄を呼び出します。「ライブラリ」アセンブリを更新すると、テストされていないすべてのアプリが破損する可能性があり、古いバージョンのアセンブリを使用して修復する方法はありません。そのため、CLR はこのシナリオをサポートしていません。

通常の回避策をすべてリストしました。1 つを除いて: 各アプリに独自のコピーを提供します。

于 2010-03-26T18:59:20.480 に答える
0

過去に AppDomain.AssemblyResolve アプローチを使用しましたが、非常にうまく機能しました。FileNotFound 例外の原因となっているアセンブリを特定して、アプリケーションの初期化を再編成して、ロードされたときにロードされないようにすることをお勧めします。

于 2010-03-26T18:57:54.483 に答える