問題タブ [assembly-resolution]

Prism または MEF フレームワークを使用して xap モジュールを動的にロードできることを知っています。ただし、これらのフレームワークは使用したくありません。代わりに、xap ファイルを手動でロードします。そこで、次のクラスを作成しました（インターネットから適応）：

上記のコードは問題なく動作します。次の方法で任意の xap をロードできます。

さて、Sales.xap プロジェクトに InvoiceView という UserControl があるので、このクラスをインスタンス化したいと思います。現在のプロジェクト (Main.xap) では、Sales.xap プロジェクトへの参照を追加しましたが、手動で読み込むため、"Copy Local = False" を設定しました。しかし、実行すると、次のコードは TypeLoadException をスローします。

コードが InvoiceView クラスを見つけられないようです。しかし、XapLoader の initXap() メソッドが正常に実行されることを確認しました。では、なぜコードは InvoiceView クラスを見つけられないのでしょうか? 誰かがこの問題で私を助けることができますか?

MsBuildタスクを作成しました：MyTask。私のソリューションには、タスクプロジェクトとその他のプロジェクトがあります。MyTaskは、3番目のアセンブリ（たとえば（dep1およびdep2））を参照するプロジェクト（たとえばProjA）を参照します。

プロジェクトはすべてうまくビルドされ、1つのディレクトリに出力があります（コンパイル）。このディレクトリには、必要なすべてのdllがあります：MyTask.dll、ProjA.dll、dep1.dll、dep2.dllなど。

私のMsBuildファイルには、カスタムタスクアセンブリが含まれています。

次に、MyTaskアセンブリのタスクを呼び出します。呼び出しは適切に実行されますが、MsBuildはdep1アセンブリとdep2アセンブリが見つからないことについて文句を言います（同じディレクトリにありますが）：

エラー：ファイルまたはアセンブリ'dep1、Version = 2.0.0.0、Culture = neutral、PublicKey Token=9109c11469ae1bc7'またはその依存関係の1つを読み込めませんでした。システムは、指定されたファイルを見つけることができません。

dep1.dllとdep2.dllをc：\ windows \ microsoft .net \ framework \ v4.0 \にコピーすることでこの問題を解決できますが、他のプロジェクトをビルドするときに問題が発生するため、これは行いたくありません（ t dep1.dllとdep2.dllを出力ディレクトリにコピーします...）。

誰かが同じ問題、またはより良い解決策を持っていますか？

編集

これがFusionLogViewerの出力です

そして、すべてのdllがあるディレクトリにMsBuild.exeをコピーすると、正常に機能します...
MsBuildは、ProjA.dllが見つかったとしても、Compilディレクトリでdep1.dllとdep2.dllを検索しないようです。 。

編集

私のバインディングがどのように行われるかについて：MyTaskは次の方法でProjAプロジェクトを参照します：

ProjAは2つの依存関係を次のように参照します

現在、一部のソフトウェアのアドインを開発中です。アプリケーションは母国語で書かれていますが、.NET で開発することにしました。.NET で外部インターフェイスを直接作成する際にいくつかの問題があったため、C++/CLI でブリッジ DLL を作成することにしました。これにより、基本的な初期化が行われ、マネージ アセンブリが読み込まれ、そこからユーザー コントロールが作成されます。

アドイン .ini ファイルでは、C++/CLI DLL が名前で参照されるため、アプリケーションはそこからロードします。ただし、.NET DLL は C++/CLI DLL から (マネージ参照として) 参照されるだけなので、エクスポートされた型を使用できます。ただし、このセットアップでは、.NET DLL のロード中にアプリケーションがクラッシュします。

イベントをサブスクライブするだけで、C++/CLI DLL と同じディレクトリから .NET アセンブリをロードできることがすぐにわかったAppDomain.AssemblyResolveので、問題自体は解決されました。

実際の問題は、.NET DLL が参照しているアセンブリと同じディレクトリにあるにもかかわらず、ローダーが .NET DLL を見つけられないのはなぜですか? アセンブリをロードすると、現在の作業ディレクトリだけでなく、最初に同じディレクトリが検索されると常に思っていました。作業ディレクトリを変更すると、実行可能ファイルがアセンブリを見つけるのはなぜですか? それとも、(純粋なマネージド アプリケーションではなく) C++/CLI アセンブリを読み込むことによって CLR が呼び出された場合、状況は異なりますか?

VS 2008 への参照を追加すると、v1.1.0.0 であるはずのバージョンが v1.0.0.0 と表示されます。私が見る限り、間違ったバージョンを追加する理由はまったくありません。

両方のプロジェクトはゼロから作成されており、追加しようとしているアセンブリを参照する参照は他にありません。Windows でファイルを見ると、正しいバージョンがありますが、どういうわけか VS は間違ったものを選択します (ターゲット パスは正しいです)。 ）。

私が指しているバージョンをVSに選択させる方法を知っている人はいますか?

以前にこの質問をしましたが、問題を解決する答えはありませんでした...

私は間違いなく正しいファイルを選んでいます。

私の新しいプロジェクト (windows-C#-vs2008) では、おそらくネットワーク サーバーから、実行可能ファイルを自律的に更新できるようにしたいと考えています。 CurrentDomain_AssemblyResolve() メソッド

実行可能ファイルからロードする前に、分離ストレージ内のライブラリの存在を最初にチェックするようにします。しかし、メインの exe で何かを変更したい場合はどうすればよいでしょうか。[ローダー プロジェクト (コンソール ap) を作成しようとしましたが、そこからメイン プログラム (dll として変更された出力) が呼び出されますが、今回は参照 dll が新しいローダーの bin フォルダーの下に生成されているため、アセンブリ解決イベントがトリガーされません。コンパイル中のプロジェクト] どんな助けでも大歓迎です..

csharptest.net が提供するEXE ファイルにサテライト アセンブリを埋め込む方法のコードを使用して、カスタム アセンブリ リゾルバーを作成し、リソースにアセンブリを埋め込みました。

で使用されているアセンブリを正常に解決できますが、どういうわけか AppDomain.CurrentDomain.AssemblyResolve は「AppName.resources」と呼ばれるアセンブリ、具体的には「MyProgram.resources、Version = 0.15.3992.31638、Culture = en-US、PublicKeyToken = null」を要求します。解決方法がわからない？

リソースからのカスタム アセンブリの読み込みを無効にして (すべてのアセンブリ dll をプログラム ディレクトリに配置)、AppDomain.CurrentDomain.AssemblyResolve を有効にしようとしましたが、まだ要求されていました。

私はこれについて少し混乱しています。これについて私を助けてくれれば、大いに感謝します。

これが興味のある人のための私のコードです。

複数の実行可能ファイルを含むフォルダーがあります。現在、アセンブリバインディングリダイレクトは各executable.exe.configファイルで構成されています。これを一度だけ構成し、そのフォルダー内のすべての実行可能ファイルがこれを自動的に取得する方法はありますか？これはコンピューター全体に適用されるため、machine.configは避けたいと思います。

コンパイル時に静的に参照されるアセンブリを、実行時に使用する別のアセンブリと交換できるのは、どのような条件下ですか? 例えば：

アプリの組み立て:

• 参照共通アセンブリ
• ServiceProviderFactoryサービス アセンブリの参照

共通アセンブリ:

• 定義するIServiceProvider

サービス アセンブリ:

• ( s のServiceProviderFactoryファクトリ) を提供します。IServiceProvider
• 参照共通アセンブリ

上記を考慮して、インストール時にサービス アセンブリを交換できるようにしたいと考えていますが、新しいサービス アセンブリがどのような条件下で引き続き読み込まれるかはわかりません。

私は、次のことが成り立たなければならないと考えています。

1. 同じアセンブリ名、
2. 弱い名前のアセンブリ、または厳密な名前のアセンブリ内の同じバージョン番号、および
3. ServiceProviderFactory署名は一定のままです。

注：リフレクションを使用してサービスアセンブリを検索して、固定された署名が存在IServiceProviderするものに依存するよりも実装を検索する方が良いようServiceProviderFactoryですが、上記に対する回答にはまだ興味があります。

こんにちは、Win7 64x と Visual Studio 2010 を使用しています。任意の CPU を対象とするライブラリ/フレームワークを作成しました。次に、そのフレームワークを使用する新しい WinForms プロジェクトを作成し、ウィザードの既定値をそのままにしました。つまり、私は何も変えていません。フレームワークを参照すると、VS はアセンブリを見つけることができません。プロジェクトのプロパティに移動すると、すべての CPU がターゲットになっています (予想どおり、必要に応じて変更できます)。しかし、Configuration Manager にアクセスすると、そのプロジェクトで使用できる唯一の選択肢は x86 です。そして、それが問題だと思います。Any CPU を新しいターゲットとして追加しようとしましたが、できませんでした。

誰かが私を助けることができますか？:)

前もって感謝します！

Assembly.LoadFromは ApplicationBase と PrivateBinPath を使用しているというのが私の印象です。また、Assembly.LoadFile はそうではないという印象もあります。

なぜ LoadFile を使いたがるのでしょうか? つまり、私の理解が正しければ、なぜ ApplicationBase と PrivateBinPath を使用したくないのでしょうか?

LoadFile を使用する既存のコードを使用していますが、なぜそうするのかわかりません。LoadFile は明らかに、同じディレクトリから依存関係をロードしません。LoadFrom メソッドは依存関係をロードします (ドキュメントから:ロードからのコンテキスト...パス情報がコンテキストによって維持されているため、そのパスの依存関係を見つけてロードすることができます。 ) LoadFile を使用して変換したいと思います。 、LoadFrom を使用します。

LoadFile を LoadFrom に置き換えた場合、どちらかと言えば何が壊れる可能性がありますか?

良心的であっても、プロジェクトのスケジュールによっては交換できない場合があります。LoadFile を LoadFrom に置き換えることができない場合、LoadFile で読み込まれたアセンブリに依存関係を読み込むよう説得する方法はありますか? LoadFile でロードされたアセンブリがその依存関係もロードできるようにする、使用できるパッケージ化のトリック (組み込みアセンブリ、ILMerge、AssemblyResolve イベントなど) はありますか?