問題タブ [fusion]

Windows サービス インストーラーが「エラー 1001。MyService.exe アセンブリでインストーラーの種類を取得できません」というメッセージが表示される場合。そのため、MyServiceInstaller をロードできません。Fusion のログに、Data.dll アセンブリを見つけようとして失敗したことが示されています。

問題は、サービス インストーラー オブジェクトを作成するために Data.dll を読み込む必要がないということです。それらの型を含むメソッドが呼び出される直前まで、型の読み込みがトリガーされなかったと思いました。一部の MyServiceInstaller メソッドは Data.dll から型を参照しますが、ctor は参照しません。

これは、MyService.exe をロードする、または MyServiceInstaller をプローブするという行為が、Data.dll のロードを呼び出すかのようです。

私が理解しているように、フュージョン ログでは、私が知る必要があることを教えてくれません。その時点では遅すぎます。そもそも Data.dll の読み込みをトリガーした MyServer.exe の読み込みまたは MyServiceInstaller のプローブについて知る必要があります。

Data.dll を MyService.exe の隣に配置できないというビジネス要件があります。そして確かに、それはこの問題を解決します。通常の実行時に Data.dll をロードするカスタム AssemblyResolve イベントがあります。

WebサイトをインストールしてIIS仮想ディレクトリを作成する小さなインストーラーアプリを作成したいと思います。このアプリは、Windows XP / Server 2003（IIS 6）およびVista / 2008（IIS 7）で実行する必要があります。

問題は次のとおりです。IIS6の場合はWMI/MetabaseAPIを呼び出してvirtdirを作成し、IIS 7の場合ははるかに優れたAPIであるMicrosoft.Web.Administrationがありますが、そのアセンブリはIIS7システムでのみ使用できます。

素朴なアプローチ：

いいですね。しかし、Microsoft.Web.Administration DLLをロードしようとしているときに、これが古いシステムでクラッシュしないようにするにはどうすればよいですか？または、アセンブリを最初に使用したときに、アセンブリがロードされたばかりですか？アセンブリを呼び出しているメソッドが最初に使用されるのはいつですか？

おそらく、CLR / .NET仕様によってある程度の決定論が保証されていなければ、テストは役に立ちません。

このトピックに関するあなたの経験、ヒント、または解決策を聞くのを本当に楽しみにしています。これまでのところ、Web上でリモートで使用できるものは見つかりませんでした。

私の.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アセンブリへの参照と同じ種類のロードエラーが発生するためです。

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

パートナーの 1 人が、アプリケーションからアクセスする必要があるアセンブリを提供してくれました。残念ながら、これは厳密な名前ではないため、GAC にインストールすることはできません。また、実行可能ファイルと同じ場所に配置することはできません。

これに対する解決策はありますか？

編集: これはテスト用の一時的な解決策であり、RC に移行すると、厳密な名前のアセンブリが作成されます。

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

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

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

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

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

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

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

他の.netアセンブリに依存するアプリケーションがあります。アプリケーションを起動すると、アセンブリまたはその依存関係の1つを読み込めないというエラーが表示されます。

アセンブリをGACまたはアプリケーションのディレクトリに配置したくありません。アセンブリをロードしようとするときに、指定されたパスを調べるように.netに指示する方法（app.config？）はありますか？単一のアセンブリにアセンブリバインディングを使用できると思いますが、「検索パス」にパスを追加するためのワイルドカードソリューションを探しています

簡単な質問（SharePoint 2010に登場しますが、実際には関係ありません）。

どうやって：

...実際のタイプ（LdapMembershipProvider）がMicrosoft.Office.Server.UserProfilesアセンブリでのみ検出され、Microsoft.Office.Serverアセンブリでは検出されない場合に解決しますか？

どちらもGACに登録されています。

完全修飾タイプが指定されている場合でも、Fusionは他のアセンブリをプローブしますか？

.NETフュージョンロガー（FUSLOGVW.exe）で、画面の右下にある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 が呼び出された場合、状況は異なりますか?

v2.0 ランタイムにリンクされたアセンブリをインポートする .Net アセンブリがあります。私が抱えている問題は、アセンブリでいくつかのテストを実行しようとすると、Fusion が依存アセンブリの間違ったバージョンをロードしようとすることです。

アセンブリ マニフェストを確認すると、その理由がわかりました。間違ったバージョンのFSharp.Coreがリンクされています。私のビルド ファイルではFSharp.Core, Version=4.0.0.0明示的に作成していますがFSharpPowerPack、v2.0.0.0 にリンクしているように見えます。

マニフェストは次のとおりです。

FSharpPowerPack他の .Net アセンブリ (mscorlib、System、System.Core) の v2.0 および v3.5 を含めることにより、含まれてエイリアスが付けられているように見えることに注意してください。なぜこれが起こるのですか？これは の間違ったバージョンをロードするという問題に関連していFSharp.Coreますか?

編集:明確にするために、私のアセンブリは C# v4.0 コンパイラによって生成されています。