問題タブ [side-by-side]

LoadLibraryパスなしで呼び出した場合(たとえばLoadLibrary("whatever.dll")、Windows は通常、EXE の検索に使用するのと同じ標準検索アルゴリズムに従います。

私の質問は次のとおりです。アプリケーション マニフェストで、システム DLL の特定のバージョン、たとえば comctl32.dll 6.0 が指定されているとします。その場合、LoadLibrary("comctl32.dll")すぐに正しいサイド バイ サイド フォルダーに移動しますか、それともなんらかの検索を実行しますか?

私たちの処理ソフトウェアでは、外部アセンブリのあるバージョンから新しいバージョンに移行しています。アセンブリが実行する全体的なタスクは同じですが、API は根本的に異なり、下位互換性は維持されていません。API は、一致する新しい API または古い API で実行されている外部ステーションからデータを抽出する役割を果たします (後方互換性もありません)。外部アセンブリまたは外部ステーションのソフトウェアを制御することはできません。外部アセンブリは強力に署名されておらず、アセンブリ内のモジュールは両方のバージョンで同じ名前になっています。

処理ソフトウェアの 2 つのバージョンを維持する代わりに、それを動的に進化させ、接続する外部ステーションに応じて、外部アセンブリの古いバージョンまたは新しいバージョンのいずれかを使用するようにします。外部ステーションが新しいバージョンをサポートしているかどうかを判断できるため、「バージョン」の選択は多かれ少なかれ明確になる可能性があります。

したがって、2 つのバージョンの外部アセンブリ ComLib.dll がセットアップされます。同じアセンブリ/プロジェクトから 2 つのバージョンを参照できますか?また、タイプなどを決定するときに 2 つのアセンブリをどのように区別できますか?

上記が単一のアセンブリ/プロジェクト内から実行できないと仮定すると、外部アセンブリの各バージョンに 1 つずつ、バージョン固有の「アダプター」アセンブリを実装できます (これには十分なインターフェイスと抽象化が既に用意されていると思います)。実行時のタイプ/バージョンの混乱 (アセンブリの解決/読み込みなど) を避けるために、注意すべき注意事項や特定の設定はありますか? このセットアップの .NET ランタイムには十分な「サイド バイ サイド」サポートがありますか?

更新: 物事をより面白くするために、この質問にさらにひねりが加えられています。外部アセンブリが追加のアセンブリを読み込み、外部構成ファイルを使用しているようです。異なるバージョンには異なる構成ファイルと異なる追加アセンブリが必要なため、各バージョンは、バージョンに一致する追加アセンブリを何らかの方法でロードする必要があります。

私たちが望むのは、各バージョンのアセンブリを、構成ファイルと追加のアセンブリを含む別のフォルダーに「ルート」でロードすることです。これは、標準のアセンブリ リゾルバー/ローダーでも可能ですか?それとも、「ルート」フォルダーを強制するために、何らかの魔法をかけてアセンブリを手動で (別の AppDomains で?) ロードする必要がありますか?

C# のアプリケーションで使用する必要がある C++ で記述された DLL があります。Vista x86 では問題なく動作しますが、x64 ではロードに失敗します。そこで、DLL の x64 バージョンをビルドし、OS が x86 か x64 かを検出し、適切な DLL への適切な相互運用呼び出しを使用します。これは Vista x86 では問題なく動作しますが、Vista x64 では DLL をロードしようとすると「サイド バイ サイド」エラーが発生します。ロードに失敗する正確な理由と、これを修正するために何ができるでしょうか? (さらに情報が必要な場合はお知らせください。この問題のトラブルシューティングに関連する情報がわかりません。)

MSVC 2K5、SP1 (バージョン 762 msvcrt80) を使用してコンパイルされたアプリがあります。

誰かが同じマシン .Net3.0SP1 にインストールするまでは、すべて問題ありません。それとともに、msvcrt80 バージョン 1433 がインストールされ、ポリシーが自動的にアップグレードされます。

現在、いたるところでランダムなクラッシュが発生し、顧客は不満を抱いています。

マニフェスト ファイルを調整して特定のバージョンを強制的に使用できることは理解していますが、自動生成された詳細をコピーして手動で変更するという本当に醜い方法しか見つけられませんでした。これは、修正するアプリが多数ある場合に特に不快です

代わりに、winSxS ディレクトリの愚かな「アップグレード」ポリシーを取り除くことはできますか? 特定のバージョンのみをコンパイルし、マニフェストを自動的に生成するオプション/フラグはありますか?

いくつかの C++ プロジェクトでブーストを使用しています。最近、アップグレード (1.33.1 から 1.36、すぐに 1.37 へ) を行いました。それ以来、デバッグビルドを実行できなくなりました。

他のプロジェクトの問題が残っていないことを確認するために、boost.thread のみを含む最小限のテスト プロジェクトを作成し、それを使用して 1 つのメソッドを開始しました。リリース ビルドは開始できますが、デバッグ ビルドは開始できませんが、必要なすべてのライブラリが見つかったことがDependency Walkerによって示されます (これは、必要な MS Debug CRT が SxS ディレクトリにあることも意味します)。

起動時に取得するのは次のとおりです。

Die Anwendung konnte nicht richtig initialisiert werden (0xc0150002)。Klicken Sie auf "OK", um die Anwendung zu Beenden.

つまり、「アプリの初期化に失敗しました」というだけです。インターネット調査では、主にMS Office のインストールに関する問題が発生しており、WinXP の修復を推奨しています。

それで、修復セットアップ（debug-dllの問題について話しているので役に立たないと思います）のほかに、何かアイデアはありますか？

ああ、忘れる前に: 完全に同じソース コードは、ビルド マシンでエラーを発生させません (つまり、DLL を登録することができ、実行されることを意味します)。明らかにインストールの問題ですが、DLLがそこにあり、dependency-walker がそれを見つけたので、他に何を忘れたのでしょうか?

(編集) さて、私はまだ問題を解決していませんが、deemok のおかげで一歩前進しました。誤解を減らすために、以下にいくつかの説明をします。

• 開発者マシンでプログラムを実行できない
• インストールされた VS2005 で作業しています(これは VC++8 プロジェクトです)
• BoostProのブーストセットアップを使用し、可能なすべてのビルドバージョンをコンパイルし、それらが存在することを再確認しました (そうしないと、ビルド中に既にリンカーエラーが発生していました)。
• そして、私が考えることができる include/lib/bin 構成の隅々を再確認しました-ブーストはウィンドウで自動リンクを使用するため、特別な命名規則を使用して、ビルドまたは起動が失敗し、はるかにわかりやすいエラーメッセージ。
• boost.thread は DLL プロジェクトの動的リンクを必要とするため、静的リンクは使用できません(ここで混乱する可能性がありますが、この問題は私のマシンでのみ発生するように思われるため、これを混乱させたくありません。ブースト担当者には、そもそもそのチェックインをそこに配置する理由がありました)
• 私が書いたように、依存関係ウォーカーに確認したところ、すべて問題ないとのことです。

現在、boost-dll にエラーがあるようです (マニフェストが正しくない可能性があります)。それを確認します。

WinExecいくつかのコマンド ライン パラメーターを使用して別の実行可能ファイルを起動するために、1 回の呼び出しで C++ プロジェクトをコンパイルしたいと考えています。Microsoft のサイド バイ サイド DLL を必要とせずに動作する実行可能ファイルを生成するために、プロジェクトで指定する設定がわかりません。これをターゲット システムにインストールする必要はありません。ヒントはありますか？

この症状は、アプリケーションの起動に失敗し、次のイベントがアプリケーション ログに書き込まれることです (フランス語から自由に翻訳されたものです)。

更新: 使用が悪い習慣であることは知っていWinExecますが、それは魔法のように機能し、Microsoft は API の将来のリリースでそれを削除することはできないのではないでしょうか?

COM サーバー DLL とクライアント アプリケーションが Windows XP で登録なしで動作するために必要なマニフェストを作成しました。私はすべての種類の組み合わせ (登録の有無にかかわらず) をテストしましたが、すべての場合において、クライアント アプリケーションは、マニフェストが存在する場合はライブラリのサイド バイ サイド バージョンを参照し、存在しない場合は登録されたバージョンを参照します (または COM エラー登録がない場合）。私は自分の Windows XP 開発マシンでテストし、ファイル (DLL、クライアント EXE、およびそれぞれに 1 つのマニフェスト) を同僚に渡しました。同僚も自分の Windows XP マシンですべてを正常に実行しました。マニフェストは、埋め込みリソースではなく、外部 XML ファイルです。ここまでは順調ですね。

ただし、ファイルを Windows Server 2003 マシンにコピーすると、機能しません。サイレント エラーが発生しますが、アプリケーション イベント ログにアプリケーション エラーが記録されます (以下を参照)。DLL の登録を解除してマニフェストを削除すると、同様のエラーが発生します (コマンド プロンプトではサイレントになりますが、イベント ログにはアプリケーション エラーが記録されます)。明らかに、登録を見つけるのに問題があります。社内でアクセスできるすべての Windows Server 2003 マシンでこれを再現しました。side-by-side/registration-free COM に関する Microsoft のドキュメントによると、Windows XP 以降、および Windows Server 2003 以降で動作するはずです。

明確にするために、同じクライアントは、同じ Windows Server 2003 マシン上で、同じ COM DLL の登録済み (つまり、regsvr32 を使用) バージョンに対して、登録不要の COM に使用しようとしている同じログイン資格情報の下で完全に実行されます。つまり、登録不要の COM の問題を装った本質的な問題はありません。このクライアントとサーバーは、サーバーがレジストリにグローバルに登録されている場合に正常に動作します。

さらに調査する方法について何か考えがある人はいますか? 私は Windows Server の専門家ではありませんが、このサポートを有効にするために変更する必要があるポリシー設定はありますか? 必要な変更を見つけることができれば、技術サポート/インフラストラクチャの担当者はおそらくそれを行うことはありませんが、彼らが忙殺されているため、問題の調査についても頼ることはできません.

それが問題になる場合（そうすべきではないと思いますが、あなたは決して知りません）、DLL は Delphi 2007 で作成され、クライアントは Visual C++ で作成されます。

昇格が必要なアプリケーション マニフェストを .NET 2.0 EXE に追加しようとしています。私は単純なEXEに対してそれを行い、問題なく機能しましたが、このより複雑なEXEでは機能しません.

私のEXEには、構成ファイルと、ソリューション内の他のDLLの多くの依存関係があります。

Activation context generation failed for "C:\MyCompany.MyProduct.WinUI.exe".Error in manifest or policy file "C:\MyCompany.MyProduct.WinUI.exe.Config" on line 1. Invalid Xml syntax.EXE を起動すると、" "という SideBySide エラーが発生します。

私の設定ファイルはマニフェストファイルと何の関係がありますか? これが私のマニフェストです：

Windows Server 2008 用の製品の .msi パッケージの構成を更新中です。インストールの主なコンポーネントは、Windows サービスとして実行されるアプリケーションです。また、サービスで使用するレジストリ エントリをセットアップするためにインストール中に実行される構成アプリケーションもあります。

サービスと構成アプリケーションは、マージ モジュールとして .msi に含まれている Microsoft C/C++ ランタイムと MFC に依存しています。C/C++ ランタイムと MFC のアセンブリは、InstallFinalize 中にコミットされます。これにより、Windows インストーラーによって提供されるメカニズムを使用したサービスの開始が妨げられているようです (これは正しいですか?)。 InstallFinalize の前に実行される場合は、少なくとも構成アプリケーション。

私たちが採用したアプローチは、InstallFinalize の後に "commit" カスタム アクションとして構成アプリケーションを実行し、このアプリケーションでサービスを開始させることです。これには、昇格された特権でアプリケーションを実行する必要があります (これには、trustInfo セクションを含むマニフェストを使用します)。さらに、このアプリケーションを偽装なしで実行するように .msi を構成する必要があります (そうしないと、特権の昇格が混乱します)。

これは受け入れられるアプローチですか？これはどの程度将来性があるのでしょうか? 注意すべき落とし穴はありますか?

これは他の人が遭遇した問題のようです:

http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg12666.html

このような問題に対処するための公式 (または非公式) の方法はありますか?

これの補足として、インストール プロセス中にカスタム アクションとして実行されるアプリケーションが起動時にフォーカスされるようにする方法はありますか? この方法で開始されたアプリケーションは、常にインストーラーの背後にポップアップ表示され、インストーラーがフォーカスを維持するように見えますが、これは特にユーザー フレンドリーな効果ではありません。

どうもありがとう、

ブルース。

EXE COM アプリケーションであり、依存する COM dll である COM コンポーネントをアクティブにする方法はありますか? この COM コンポーネントを .NET アプリケーション (VS 2005/VS 2008) からアクティブ化したい。

呼び出しのパスは C# アプリケーションです --> プロセス外の exe を呼び出します (これは COM を介して行われます)。その後、このプロセス外でいくつかの COM dll が呼び出されます。