問題タブ [assembly-resolution]

これの重複がある場合、私はそれを支持しますが、誰かが私のためにそれを見つけるまで....

TestDriven.NET を使用すると、.NET から次の出力を継続的に取得していましたAssembly.Load。

WRN: アセンブリ バインディングのログがオフになっています。

アセンブリ バインド エラーのログ記録を有効にするには、レジストリ値 >[HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) を 1 に設定します。

注: アセンブリ バインドの失敗ログに関連するパフォーマンスの低下があります。

この機能をオフにするには、レジストリ値 [HKLM\Software\Microsoft\Fusion!EnableLog] を削除します。

そのため、fuslogvw をロードしました。x64 システムを使用しているため、同じ x64 バージョンを試してみましたが、何度再試行してもログを表示できませんでした。レジストリの設定を確認したところ、すべてが正しく設定されているように見えましたがEnableLog、再実行しても満足できませんでした。

FWIW: Windows 7 64 ビット、Compact Framework v3.5、FxCop v1.36 (fxcopcmd.exe を実行)

FxCop 1.36 を正しく実行するのに問題があります。http://www.dotneti18n.com/Downloads.aspxのグローバリゼーション ルールを使用して、コンパクトなフレームワーク アプリケーションを分析しています。

私が分析している .exe には、サード パーティのコントロール スイートへの参照があります: resco.outlookcontrols.cf.dll。fxcop がアプリを実行して分析すると、このアセンブリが見つからないと言って爆発します。アプリを実行するために必要なすべてのアセンブリが、分析対象のフォルダーと同じフォルダーにあることを確認し、再確認し、さらに 30 回確認しました (resco dll を含む)。

Fusion ログ ビューアーを使用すると、次の情報を取得できます。

これが私を本当に苛立たせている部分です：fxcopのドキュメント（ここhttp://msdn.microsoft.com/en-us/library/bb429449%28VS.80%29.aspx）は、参照されているすべてのアセンブリを分析されたアセンブリと同じフォルダー、または /directory: コマンド ライン オプションによって参照されるフォルダーから。

文書化された約束を守っていません。ファイルは分析中のフォルダーと同じフォルダーに存在し、/directory: コマンド ライン オプションとしてフォルダーを渡そうとしました。.fxcop ファイルに AssemblyReferenceDirectories 要素を設定しました。それでも、融合ログによると、検索される場所は、探査のための「通常の」場所だけです。

fyi - fxcopcmd.exe.config の「プローブ」設定を更新しようとしました - 分析中のアセンブリのフォルダーが fxcop ツールのルート フォルダーの下にないため、動作しません。そのため、警告が表示されます。調べられません。

他の誰かがこの問題を抱えていますか？誰かが解決策を持っていますか？

ありがとう

別のアプリケーションでプラグインとして使用されるネイティブ C++ DLL があります。この DLL にはマニフェストが埋め込まれており、アプリケーション外部のフォルダーにあるプライベート アセンブリに依存しています。DLL が見つからないプライベート アセンブリに依存しているため、アプリケーションはプラグイン DLL のロードに失敗します (このアセンブリは、アプリケーション ディレクトリにも winsxs フォルダーにもありませんが、場所がによって制御されていないプラグイン ディレクトリにあります)。アプリケーション）。問題は、システムが自分の特定のディレクトリにあるプライベート アセンブリを見つけられるようにするにはどうすればよいかということです。類推として、 setDllDirectory() に相当するものが必要ですが、アセンブリ用です。または、システムが私のプライベートアセンブリを見つける別の方法。

制約:

私の DLL はプラグインであるため、アプリケーションのディレクトリとサブディレクトリには何もインストールできません。また、アプリケーションの動作を変更することもできません。
winsxs でアセンブリを共有することは避けたいと思います。
また、バージョンの競合を避けるために、単純な DLL (LoadLibrary でロードできる) ではなく、アセンブリを使用する必要があります。

ありがとう。

属性の構成（myapp.exe.config）ファイルで指定されたサブフォルダーからほとんどのdllをロードするアプリケーションがあります

私の質問は次のとおりです。dllがプローブパスで指定された同じサブディレクトリ「subdir」にある場合、ファイル名のみを使用して実行時にdll（mydll.dllなど）をロードできますか？

試しAssembly.LoadFile("mydll.dll")ましたが、「subdir」では検索されません。

Webサービス参照を使用するC＃ライブラリファイルがあります。Microsoft SOAPタイプライブラリv3.0を参照し、Visual Studio 2008を使用しています。セットアッププロジェクトを作成すると、mssoap30.dllとmsxml4.dllの依存関係が自動的に決定されておらず、セットアップ手順が異なるというエラーが表示されます。失敗します。

これについての理由と方法は何ですか？

.NET (または Visual Studio) ビルドは、参照されたアセンブリを bin/debug または bin/release ディレクトリにコピーするかどうかをどのように決定しますか? (これは .exe コンソール プログラムです。)

私のマシンでは、参照されたアセンブリが GAC にありました。同僚が私のビン/リリースを自分のマシンにコピーしましたが、参照されているアセンブリがビン/リリースにない (そして GAC にない) ため、実行されませんでした。

ありがとう、

ニール・ウォルターズ

私の.NET実行可能ファイルabc.exeはいくつかのアセンブリを参照しています。それらの1つはと呼ばれxyz.core.exeます。のようなパスを持つ共有名で指定されたネットワークの場所から起動しているときに、動作させるのに問題があります\\localhost\xyz\abc.exe。Z:これは、に名前が付けられたネットワークドライブ文字をマウントし、\\localhost\xyzを起動した場合に正常に機能しますZ:\abc.exe。

xyz.core.exe共有からアセンブリをロードしようとすると、.NETが混乱するようです。System.IO.FileNotFoundException次のフュージョンログ情報で例外をスローします。

Process Monitorを使用して別の角度からこれを見ると、次のパスを使用してローカルドライブにアクセスしようとする試みがいくつか見られます。

ローダーがネットワーク共有からのロードの意図を誤解し、代わり\\localhostに使用するためにドロップしたかのように。C:この問題はセキュリティ設定に関連していないようで（マシンでCASPOLをいじったことはありません）、実行可能ファイルを共有から開始できる.NET3.5SP1を使用しています。

また、同等のマップされたネットワークドライブ文字を使用してプログラムを起動すると、これがセキュリティの問題ではないことを確認できます。

この問題は、EXEアセンブリへの参照であるという事実とは関係ありません。これは、プレーンDLLアセンブリへの参照と同じ種類のロードエラーが発生するためです。

この読み込みの問題の原因は何でしょうか？他の誰かがそのような状況に遭遇しましたか？

MMCベースのアプリケーションのスナップインであるc++コードがいくつかあります。このスナップインは、COMラッパー（AssemblyA）を介して.net2.0dllを使用します。AssemblyAは、MMCセッションを起動するアプリと同じディレクトリにあります。AssemblyAは、他の.net dll（OtherAssemblies）を使用しますが、これは、私の制御が及ばない理由により、AssemblyAと同じディレクトリに存在することはできません。また、一部のコンポーネントを（AssemblyBから）動的にロードできるようにし、3番目のディレクトリでこれらを検索します。AssemblyBの動的コンポーネントは、AssemblyAの基本クラスを拡張するため、AssemblyAを参照します。

私の問題は、動的コンポーネントを読み込もうとすると、AssemblyAへの依存関係を解決できず、AssemblyResolveハンドラーが起動されることです（これは解決に使用していましたOtherAssemblies）。ハンドラーでクエリを実行Assembly.GetExecutingAssembly ()するとAssemblyResolve、アセンブリは解決しようとしているアセンブリです。

.NETランタイムが最初にロードされたアセンブリで依存関係を検索し、次にロードしているアセンブリのローカルで、次にappディレクトリで依存関係を検索することを期待していたので、この動作は少し奇妙に思えます。これらの最初と3番目には、ロードしようとしているアセンブリが含まれている必要があります。

AssemblyResolveメソッドを変更して、他の場所の依存関係を検索し、現在のアプリディレクトリのように機能するようにしましたが、手助けができれば、これは本当にやりたくありません。

この動作は予想されますか？それはMMCアプリであるためですか、それともC ++から呼び出されるCOMから起動されるためですか？私は劣等生ですか？

厳密な名前のないアセンブリにはさまざまなバージョンがあり、app.exe.config でそれらへのバインディング リダイレクト/プローブ パスはありません。たとえば、MyDll (1.0.0.0_null_neutral) と MyDll (2.0.0.0_null_neutral) です。app.exe に対して、これらのアセンブリは LAC\MyDll_1.0.0.0_null_neutral および LAC\MyDll_2.0.0.0_null_neutral に保存されます。

私の理解では、MyDll アセンブリは厳密な名前が付いていないため、.NET ランタイムは MyDll の異なるバージョンを区別しません。したがって、MyDll 1.0.0.0 が既にメモリにロードされていて、MyDll 2.0.0.0 に対してビルドされたコードが実行された場合、.NET ランタイムは MyDll 2.0.0.0 をロードしません。

しかし、VS2008 でプロセスにアタッチしてモジュール ウィンドウを表示すると、MyDll 1.0.0.0 と MyDll 2.0.0.0 の両方が LAC フォルダーから読み込まれていることに気付きました。

私の理解にはどこかギャップがあるようです。誰かがそれを指摘できますか？

編集: これまでの応答に感謝します。はい、私はそのビットをスキップしました。実行可能ファイルは AssemblyResolve イベントをリッスンし、LAC を調べて処理します。

アセンブリに厳密な名前が付いていない限り、そのバージョンは無視されるというMSDNのドキュメントを見たことがあります。掘り出せるか見てみます。

アプリケーションの負荷に関する問題のデバッグに役立つヒント/提案/洞察を探しています。ファイルまたはアセンブリを読み込めませんでした...

この問題が発生しているソリューション/プロジェクトは、Visual Studio 2008 の作業コピーから Visual Studio 2010 リリース候補への変換です。変換プロセスは成功したようで、すべてのソリューション プロジェクトがFramework 4に設定されています。

例外はサードパーティのコンポーネント (グラフィックス処理ライブラリ) にありますが、問題のある DLL を使用している他のユーザーに役立つ可能性があります。

ファイルまたはアセンブリ 'Aurigma.GraphicsMill.DLL' またはその依存関係の 1 つを読み込めませんでした。は有効な Win32 アプリケーションではありません。(HRESULT からの例外: 0x800700C1)

この例外で紛らわしいのは、追加のテキスト: is not a valid Win32 application です。

完全な例外スタック トレースはPasteBinにありますが、この問題についてこれ以上の光を当てているようには見えません...

私がこれまでに試したことは成功していません:

1. Visual Studio 2010 RC のシンプルなクリーン、リビルド、再起動の組み合わせ。
2. 問題の DLL を削除して再度追加します。
3. 問題の DLL で「ローカルにコピー」を true と false に切り替えます。
4. 「成功したビルド」の後、問題の DLL が bin\debug フォルダーに表示されることを確認します。
5. 問題の DLL への不要な参照をチェックしています (何も見つかりません)。
6. 問題の DLL に関連付けられたライセンス ファイルは、それと同じディレクトリにあります。

また、アプリケーションの読み込み時にデバッガーのブレークポイントにヒットすることもありませんでした。