私たちはサードパーティのライブラリといくつかの内部パッケージを使用するWPFプロジェクトを持っています。 wpfのプログラムはそれ自身の上で正常に動作し、アセンブリは正しく解決され、コードはうまく機能します。
このプログラムでは、さまざまなソースからデータをロードする方法を提供しています。前述したように、それ自身で呼び出されると、すべてうまくいきますが、コントローラを用意してCOM interopとして登録することによって行われる別のアプリケーションからプログラムを呼び出すと、アセンブリ参照の問題が発生します。アセンブリ参照の問題がcomオブジェクトと組み合わされています
[Guid("93BC7929-8A5F-43EA-AEAB-38B5034758E5")]
[ComVisible(true)]
public class ConnectionController : ControllerBase
{
public override void Run()
{
var viewModel = new MainWindowViewModel();
var view = new MainWindow {DataContext = viewModel};
view.Show();
}
}
のWPFプログラムの開発は、スタンドアロンアプリケーションとして提供されるため、我々は、WPFライブラリの例somekindため、assemblysの多くを参照していない別のプロジェクトにコントローラを移動しました。
コントローラ自体はもはやロジックを保持しません。通常、comオブジェクトによって提供される何らかのデータを渡しますが、それは、別のプロジェクトでMainWindowViewModelをインスタンス化しようとすることだけです。コントローラと同じ解決策にあるプロジェクトは正しく解決されますが、サードパーティのものは解決されません。
コントローラによってwpf programmを呼び出すと、サードパーティのライブラリを参照するプロジェクトは参照をもう解決できず、例外がスローされます。
このような問題を解決する正しい方法は何ですか？サードパーティのDLLをGACに登録する必要がありますか？あるいは、私たちが調整しなければならない何らかの財産ですか？私たちはそれの周りに頭を上げることはできません。参照に関するすべての情報とその解決方法は高く評価されます。
「異なるアプリケーション」が問題です。 CLRは引き続き通常の方法でアセンブリを探します。最初はGAC、次にEXEファイルのディレクトリです。そのEXEが管理されたアプリケーションではない場合でも。あなたがそれを登録したときに/ codebaseを使用した場合、[ComVisible]タイプを持つDLLのみが自動的に検出されます。 GACはそれを解決し、DLLを他のアプリのインストールディレクトリにコピーすることで解決します。技術的には、AppDomain.AssemblyResolveを動作させることができるかもしれませんが、クライアントコードが常に最初に作成しなければならないGodクラスがあることが重要です。 –
@Hans Passant非常に感謝します。その情報は私たちの問題を解決し、そのトピックについてのより深い洞察をもたらしました。あなたのコメントを答えとしてコピー/ペーストできますか？私は答えたように印を付けたいと思っています – yRadwan
あなた自身のポストであなたが使ったアプローチを共有するだけで、私はあなたがすることを決めることはできません。投稿を回答としてマークしてください。 –