問題タブ [winsxs]

マニフェストが依存していると言う実行可能ファイルを持っています

Windows 7 では、この実行可能ファイルは問題なく実行されます。Windows Server 2008 R2 では、この実行可能ファイルは実行に失敗し、次のメッセージが表示されます。

サイド バイ サイド構成が正しくないため、アプリケーションを開始できませんでした。詳細については、アプリケーション イベント ログを参照するか、コマンド ライン sxstrace.exe ツールを使用してください。

これは予想外でした。ランタイムの可用性に関しては、Windows 7 と Windows Server 2008 R2 は非常に似ているはずだと思いました。どちらのマシンもかなりきれいです。Windows 7 マシンは、何もない新規インストールです。Windows Server 2008 R2 マシンには、Windows Update からの一部の更新しかありません。

Windows 7 マシンの WinSxS ディレクトリを調べたところ、

Windows Server 2008 R2 マシンの WinSxS ディレクトリを調べたところ、

存在するランタイムは、マニフェストで指定されているものよりも新しいものですが、Windows Server 2008 R2 システムは新しいランタイムへのリダイレクトに失敗します。Windows Server 2008 R2 で sxstrace を実行すると、次のように表示されます。

Windows 7 で sxstrace を実行すると、次のようになります。

VS 2008 ランタイムと VS 2008 SP1 ランタイムをインストールする以外に、これを解決する方法はありますか? アセンブリの全体的な考え方は、システムが古いランタイムをオーバーライドして新しいランタイムに置き換えることができるようにすることだと思いました。

Microsoft Visual C++ 2005 を使用してアプリケーションを構築しています。ライブラリのメジャー アップデートの後、マニフェスト ファイルに次のエントリを取得しています。

しかし、結果の実行可能ファイルで Dependency Walker を使用してみると、リストに MSVC80D.DLL がまったく表示されず、少し驚きました。

また、リンカーを「詳細」モードに設定して、マニフェストに示されている依存関係がどこから来ているかを教えてくれるかどうかを確認しました。悲しいかな、そこにある情報は問題を明らかにしていません。

また、リンクしているすべてのライブラリを調べて、それらのいずれかがデバッグ CRT を使用しているかどうかを確認しました。私が知る限り、どれもそうではありません。

この問題の原因となっているライブラリを特定するにはどうすればよいですか? 実行可能ファイルをそのまま配布すると、おそらく自動生成されたマニフェストのこのエントリが原因で、サイド バイ サイド エラーが発生します。

提供できるすべての助けに感謝します...何が起こっているのかを理解しようとして数日後、私はこの問題に本当にイライラし始めています。

Visual Studio 2010 C / C ++ランタイムのリンクと展開ポリシーの変更について説明している公式ノート、kbの記事、またはその他のドキュメントはどこにありますか？

Visual Studio 2008（VC90ランタイムを使用）では、マニフェストがネイティブイメージに埋め込まれ、ランタイムライブラリがサイドバイサイドアセンブリ（WinSxS）として展開されました。これにより、VS 2008 SP1を使用してネイティブexeまたはライブラリを再構築するときに問題が発生し、埋め込みマニフェストにはC++ランタイムの更新バージョンが必要でした。

VS 2010およびMSVCR100ランタイムバージョンでは、ポリシーが完全に変更されたようです。

1. ファイルmsvcr100.dllおよびその他のC/C ++ランタイムライブラリは、SxSアセンブリとしてインストールされなくなりました。
2. VS2010でコンパイルする場合、実行時の「依存関係」エントリは埋め込みマニフェストに追加されません。つまり、実行時に任意のバージョンのmsvcr100.dllがロードされる可能性があります。
3. .NET 4がインストールされているマシンでは、一致するランタイムの名前はmsvcr100_clr0400.dllであり、ネイティブコードでは読み込まれませんが、msvcr100.dllに名前が変更されたコピーは正常に機能します。これは、C / C ++コードを使用するプロセスには、常に同じC /C++ランタイムの2つのバージョンがロードされることを意味すると思います。

これはポリシーの重要な変更のようであり、VS 2008でのSxSの展開とマニフェストの依存関係から遡ります。変更された内容を誰かがもっと明らかにし、これらの変更を説明するドキュメント、Readme、またはブログ投稿を指摘できますか？動機と関連する影響？

この方法の方が優れていると思います-強力なバージョンマニフェストとSxSの展開は悪夢でした-しかし、VS2010でのこれらの予期しない一見文書化されていない変更に驚いています。

ボーナスの質問： VS2010でC++ / CLIライブラリをコンパイルして、msvcr100.dllではなくmsvcr100_clr0400.dllにリンクするにはどうすればよいですか？この考え方は、C ++ / CLIアセンブリは、.NET 4によってインストールされたもの以外の依存関係なしで（静的リンクなしで）実行する必要があるということです。

次の方法で使用したい Delphi XE で作成しているコンポーネントがあります。

1. ユーザーが新しい空のプロジェクトを作成します。

2. ユーザーがコンポーネントをフォームにドロップします。

3. 私のコンポーネントのいくつかの特別なデザインタイム コードが実行されます。これにより、プロジェクト オプションが変更され、プロジェクト オプションの [ランタイム テーマを有効にする] チェックボックスがオフになります。これが可能かどうかさえわからないので、可能かどうか尋ねています。

#3 が不可能な場合は、このコンポーネントの「使いやすさ」の問題に対する別の解決策が必要です。私が抱えている問題は、ユーザーが [ランタイム テーマを有効にする] のチェックを外して静的にリンクされたマニフェスト ファイルを無効にしない場合、EXE にリンクされている静的に生成されたマニフェストが、EXE の外部に必要な外部マニフェスト ファイルを上書きするように見えることです。ディスク。また、実行時にこれらのマニフェストを変更する必要があるため、外部マニフェストが必要になります。もちろん、必要に応じて、これらのマニフェストを使用してランタイム テーマ機能を有効にすることもできます。2 つ目の質問は、外部マニフェストと内部マニフェストの優先度に関するものです。「ランタイム テーマを有効にする」をオンにすると、Delphi アプリにリンクされている内部マニフェスト リソースよりも、外部マニフェストが何らかの形で優先されることがありますか?

#3 以外の許容される解決策:

A. Delphi がマニフェストを生成しないようにします。B. 内部の .manifest ファイルが見つかった場合でも、何らかの方法で実行時に Windows に外部の .manifest ファイルを認識させ、優先順位を付ける。

C. 最も良くないソリューション。実行時に、コンポーネントの CoCreateInstance が失敗した後、リソースを列挙し、外部マニフェストが存在し、混乱していることを報告し、コンポーネントを使用する開発者に、コンポーネントが吐き出すランタイム エラー メッセージを読み取って、無効にするように指示することができます。ランタイムテーマのチェックボックスをオンにして、アプリを再構築します。マニフェストの抽出と読み取りは、Delphi に簡単に変換できる C++ コードを使用して、別の stackoverflow question hereで既に説明されています。

更新受け入れられた回答は私が尋ねたこととまったく同じですが、ハックと見なされ、アクティベーションコンテキストに関するデビッドの回答ははるかに正気であり、推奨されるアプローチです。

Update2組み込みのマニフェストは、プロジェクト設定を介して、リンクするマニフェストを明示的に指定することにより、通常、Delphi の新しいバージョン（XE5 以降）でオーバーライドされます。

私はVS2008を持っていました。VS2010にアップグレードし、VS2008をアンインストールしました。

自分のマシンで実行するテストがありますが、ビルドラボのマシンにロードできません。デバッグを行った後、テスト実行可能ファイルがまだmsvcr90d.dll（VC ++ 2008デバッグランタイムライブラリ）に依存していることに気付きました。VS 2008をアンインストールしましたが、そのランタイムDLLがサイドバイサイドキャッシュ（％windir％/ winsxs）にまだ存在するため、テストは私のマシンで機能します。ビルドラボマシンにはDLLがないため、そこにロードされません。

VS 2008をアンインストールすると、すべてのランタイムDLLがサイドバイサイドキャッシュから削除されるべきではありませんか？

これらの古いDLLをサイドバイサイドキャッシュから手動で削除する方法はありますか？まだ古い依存関係がある可能性のある他の場所を簡単に検出できるようにしたいと思います。

私の問題を過度に単純化するために、私はそれを短くしようとします：

Unityのプロバージョンを使用していて、2つのDLLがあります。

1. .NET 3.5アセンブリ（COMクライアントとして機能）
2. .NET 4.0アセンブリ（COMを介して公開されたインターフェイスを使用）

3.5はCOMを使用して4.0で動作します。Windowsアプリで3.5アセンブリを使用すると、正常に動作し、Type.GetTypeFromCLSID（）またはType.GetTypeFromProgID（）（SxStraceで確認済み）を介してSxSを使用して4.0 dllをロードし、その機能を正常に使用できます。（Windowsアプリは、マニフェストを介して4.0 DLLに依存していると述べていますが、COM DLLを登録していません。）

Unityで.NET4.0DLLを使用しようとしています。Unityが使用しているMonoの現在のフレーバーは3.5までしかサポートしていないため、明らかに直接使用することはできません。そのため、仲介者として3.5アセンブリを作成しました。3.5アセンブリを1つで問題なく使用できますが、前述のTypeメソッドのいずれかがNotImplementedException（s）をスローします。これは、Unity（またはMono）でサポートされていないため、損失。

何か案は？

Windows XP では、ローカル アプリケーション ディレクトリにmsvcp90.dll、msvcr90.dll、およびで実行される .exe があります。Visual C++ 2008 SP1 Redistributable Packageによってインストールされた、Microsoft.VC90.CRT.manifestこれらの .dll のポリシー ファイルも にあります。このポリシー ファイルを削除し、代わりにローカル ディレクトリにあるアプリ構成ファイルを使用したいと考えています。ポリシー ファイルは次のとおりです。C:\WINDOWS\WinSxS\Policies

私の設定ファイルは次のとおりです。

ポリシー ファイルの代わりに構成ファイルを使用すると、Dependency Walker がサイド バイ サイド エラーを報告します - 何が問題なのですか? また、設定ファイルの名前<application>.exe.configは 、またはMicrosoft.VC90.CRT.config?

(明確にするために、ポリシー ファイルを使用してもエラーは表示されません。ただし、ここのクライアントは再配布可能パッケージをインストールすることはできません。

MSDNのドキュメントには、アプリ構成ファイルは同じアセンブリ (アプリケーションごとの構成)の異なるバージョンを使用するようにアプリケーションをリダイレクトでき、必要に応じて既存のポリシー (発行者構成) ファイルをオーバーライドできると記載されています。したがって、ローカルのアプリ構成ファイルを使用できるはずであり、上記のファイルの何かが欠落しているか間違っていると思います。)

未登録の tlb ファイルを使用したい。WinSxSを使用して実行できることがわかりました。

私の質問は、tlb ファイルからマニフェスト ファイルを作成する方法です。Mt.exe ユーティリティでは、tlb オプションを使用する場合、dll オプションを指定する必要があります。

誰でも私を助けてくれませんか

私がc++プログラム（B3DTest.exeなど）を作成するときは、サードパーティのdll（B3DViews.dllなど）に依存します（ベンダーは小さな会社です）。私が書いたプログラムは、dll内の1つの関数をテストするだけで非常に簡単です。プログラムを起動すると（必要なヘッダーファイル、.libファイルと.dllファイルがリンクされています）。私は以下の問題に遭遇します。

メイン関数に入る前にプログラムが終了することがわかりました。vs2008IDEの出力は

プログラムとdllを別のターゲットコンピューターに配置すると、正常に動作します。ですから、私のコンピューターに何か問題があるに違いないと思います。イベントログを検索したところ、以下に3つのイベントが表示されています

インターネットを検索して、誰かがインストールすることで同様の問題を修正していることを確認し 、2つのファイルをダウンロードしてインストールしましたMicrosoft Visual C++ 2005 Redistributable Package。Microsoft Visual C++ 2005 SP1 Redistributable Package (x86).
しかし、それはうまくいきませんでした！インターネット上の別の解決策は、3つのdllとMicrosoft.VC80.MFCフォルダー（4つのdllも含む）を含むMicrosoft.VC80.CRTフォルダーのファイルを配置し、最後に対応するマニフェストファイルをB3DTest.exe（私のプログラム）のディレクトリに配置することです。 。しかし、それでも機能しませんでした！しかし、以下のようevent logに1つしかない場所で何かが変わりました。event error

誰かが私のコンピューターのVC80.CRTとVC80.MFCのバージョンがB3DViews.dll（ベンダーによって配布されている）のバージョン番号と一致しなかった可能性があると私に言いました。次にB3DViews.dll、emacs.exeを使用してを開き、dllに添付されているマニフェストを検索します。それは以下に言います：

バージョン番号は私を混乱させました。どうすれば8.0.50727.6195よい8.0.50608.0のでしょうか。バージョン番号は1つである必要があります（上記のように2つではありません）。Microsoft.VC80.CRTdllとMicrosoft.VC80.MFCdll、および対応するマニフェストファイルを見つけました（すべてのバージョン番号は8.0.50727.6195C：\ Windows \ WinSxSにあり、B3DTest.exe（私のプログラム）と同じディレクトリに配置します） 。それも機能しませんでした。問題を理解するために。私はDependency Walker for Win32 (x86)自分のプログラムのプロファイルを作成するためにを使用しましたB3DTest.exe。

それは私を夢中にさせます。私はそれを理解したくありません。どんな助けでもありがたいです！
これ（http://www.codeguru.com/forum/showthread.php?t=408061）が問題の解決に役立つ場合があります。しかし、私はそれを読んでそれを理解することはできません。私のシステムはwindowsxpsp3で、VS2008を使用しています。VS2005をインストールしませんでした。

いくつかの VC++ DLL に問題があり、.NET/C# プロジェクトに含める必要があります。1 つの VC++ DLL は C++/CLI DLL で、.NET プロジェクトからパブリック インターフェイスとして使用します。他の DLL はネイティブ C++ で記述されています。VC++ DLL のソースにはアクセスできません。使用するしかありません。

.NET テスト プロジェクトを作成し、C++/CLI DLL を参照しました。問題ありません。コンパイラは幸運です。1 つだけ問題があります。.NET プログラムの EXE を起動すると、VC++ コア DLL が見つからないため、C++ DLL に関するエラーが発生します。sxstrace は次のように表示します (短縮):

今、私はばかではなく、いくつかのことを試しました。何が起こっているのかをより深く理解するために、WinSxS について多くのことを読みました。今、私はそれが私にとってうんざりしているポイントにいます。プログラムを実行したいシステムには、現在のバージョン 8.0.50727.762 (SP1) の VC++ Redistributable パッケージがインストールされています。このアセンブリのすべてのバージョンを現在のバージョン 8.0.50727.762 にリダイレクトする winsxs の Microsoft.VC80.CRT 用のポリシー ファイルがあることを知っています (これがhttp://blogs.msdn.com/b/nikoladの問題の解決策です)。 /archive/2007/03/29/a-solution-to-two-references-to-different-versions-of-crt-mfc-atl-in-one-application-manifest-file.aspx）。しかし、上記のエラーが示すように、このポリシー ファイルは機能していないように見えるか、考慮されていません。システムは、アセンブリの 8.0.50727.6195 バージョンを見つけたいだけです。

これが最初の質問です。ここでの問題は何ですか? これを理解した後、最初の問題を解決できました...