2

プラグイン用のPIPインストーラーを構築しています。プラグインは、1つのDLL内の1つのモジュールで構成されており、それを呼び出すことができますMyCoolPlugin.dll（実際、このDLLは複数のマージされたDLLで構成されています）。さらに、プラグインにはサードパーティのDLLへの依存関係がいくつかあります（例Infragistics2.Win.UltraWinChart.v10.3.dll）。

プラグインは正常にインストールされますが、プラグインに埋め込まれているプロセスには、UltraWinChartに応じたUIがあります。このプロセスのGUIを作成すると、Infragistics2.Win.UltraWinChart.v10.3.dllこのファイルがと同じディレクトリにある場合でも、プラグインはロードできないという例外をスローしますMyCoolPlugin.dll。「このプロセスには定義された説明またはユーザーインターフェイスがありません」-ダイアログが表示されます。

プラグインで定義されInfragistics2.Win.UltraWinChart.v10.3.dllているディレクトリにコピーすると、正常に動作します。見た目は正しいですが、依存関係への参照はありません。マニフェストには、プラグインディレクトリ内のファイルごとに1つのエントリが含まれています。probingPathpetrel.exe.configplugin.xml<File>Infragistics2.Win.UltraWinChart.v10.3.dll

依存関係が正しく読み込まれないのはなぜですか？

編集：

私は私たちが見ている問題の回避策を考え出しました。プラグインの初期化（Initialize()関数）で依存関係を（ファイル名で）手動でプリロードすることにより、すべての依存関係がプリロードされていることを確認できます。ただし、このソリューションが安定しているかどうかはわかりません（起動時にクラッシュすることがあります）。私が使用しているコードは次のとおりです。

Assembly me = Assembly.GetExecutingAssembly();
FileInfo file = new FileInfo(me.Location);
foreach (FileInfo assembly in file.Directory.GetFiles("*.dll"))
{
    try
    {
        Assembly.LoadFile(assembly.FullName);
    }
    catch (Exception e)
    {
        CoreLogger.Error(string.Format("Failed to load assembly {0}.", assembly.FullName), e);
    }
}

プラグイン.NETアセンブリの依存関係（モジュールの依存関係ではなく、外部の依存関係）が確実に読み込まれるようにする方法についての詳細はありますか？AppDomain.CurrentDomain.AssemblyResolve-eventを使用してロード障害をインターセプトしていますか？この回答は、他のすべてが失敗したときに、このイベントを使用して、実行中のアセンブリと同じフォルダーからアセンブリをロードする方法を示しています。正しいアプローチは、代わりに呼び出し元のアセンブリを使用することだと思います（実行中のアセンブリは、おそらくイベントハンドラーが定義されているアセンブリになるため）。この回避策のテストはまだ成功していません。

これがインフラジスティックスの問題ではないことを確認するために、他のアセンブリでテストしたことに注意してください。

編集2： 前に述べたように、プラグインDLLは、いくつかのアセンブリで構成されるマージされたDLLです。私はこのアプローチを使用して直接の依存関係を判断しましたが、Infragisticsはその1つではないようです。これは関連性がありますか？

4

3 に答える 3

1

AppDomain.CurrentDomain.AssemblyResolveイベントを使用することを選択した場合は、非常に注意が必要です。この場合、アプリケーションのパフォーマンスが大幅に低下する可能性があります。どの難読化ツールを使用していますか。おそらく、最善の方法は、難読化が.NETのReferenceAssemblies呼び出しに影響を与える理由を確認することです。おそらくそれは意図的に設計されたものです。この場合、アセンブリのその部分の難読化を無効にすることができます。

于 2011-07-05T14:52:59.320 に答える
0

これは奇妙な問題です。FMODライブラリを使用して音楽を再生するプラグインで同様のセットアップをテストしました。fmod dllは、デプロイリストで参照され、PIPのマニフェストファイルに表示され、プラグインインストールディレクトリ（プラグインマネージャーによって定義されたパスの下）にインストールされます。プラグインは実行時に機能します。たぶん、ペトレルが使用しているインフラジスティックライブラリとの競合がありますか？

于 2011-06-29T12:39:24.550 に答える
0

この問題は、私たちの議会の難読化に関連していると思います。アセンブリを難読化しない場合（したがって、すべてのアセンブリを1つの大きなアセンブリにマージしない場合）、すべてが正常に機能します。これは、Petrelがプラグインアセンブリをロードし、参照アセンブリをチェックし、依存関係を再帰的にロードしているためだと思います。すべてのアセンブリが参照アセンブリとしてリストされているわけではないため、この場合は機能しません。

この回避策は、マージされたアセンブリに参照アセンブリ（Infragistics）を含めることです。これはうまくいくようです。ただし、これが常に受け入れられるとは限らないと思います（たとえば、LGPLライセンスライブラリの場合）。

もう1つの、おそらくより良いアプローチは、-eventをリッスンして、AppDomain.CurrentDomain.AssemblyResolveアセンブリのロードエラーをインターセプトすることです。

于 2011-06-30T09:40:27.303 に答える