問題タブ [merge-module]

Web配置プロジェクトを使用してインストールされたASP.NETアプリケーションがあります。VisualFoxProマージモジュールをインストーラーに追加したいと思います。これを行う方法の例、またはWeb配置プロジェクトにマージモジュールをインストールする方法の例はありますか？

WiXに移行することは私のフォールバックになりますが、Web配置プロジェクトが効果的に機能しているので、可能であれば、WiXを使い続けたいと思います。

アプリケーションはC＃を使用して開発されています。

次の問題の解決策を見つけようとしています。

私は、単一のプログラム (マスター) に依存する多数のプログラム (それらをスレーブと呼びましょう) を持っています。スレーブごとにインストーラーを配布する必要があります。このインストーラーはマスターをインストールする必要があります。

両方の部分をバージョン管理できるようにしたいので、複数の msi がブートストラッパーで連鎖された正しいソリューションのように見えます。

問題は、スレーブ インストーラーが既にインストールされているマスターと同じバージョンをインストールすると、.msi が修復/削除モードで実行されることです。

これはユーザーの観点からは容認できず、混乱を招くだけです。

msi を実行する前に、現在インストールされているファイルのバージョンを確認する方法はありますか?

現在、WIX の setupbld.exe をブートストラップとして使用しています。

他のソリューションは大歓迎です（バージョニングが役に立たないため、マージモジュールも試しましたが成功しませんでした）

私はかなり長い間、自分の仕事のすべてのインストールをWiseforWindowsインストーラーからWiXに転送するために働いてきました。明らかな手順（転送するインストールの数とそのサイズを指定）から開始し、Dark.exe（WiXツールキット）を使用して逆コンパイルしました。私は、暗闇からの出力を適切なプロジェクトにクリーンアップして、MSIにコンパイルできる汎用プログラムを作成してきました。しばらくの間私の@$$を蹴っていた問題は、マージモジュールです。さまざまなインストールで最大20のMicrosoftMSMがあり、darkはこれらをそのように認識しないため、代わりにすべてのコンテンツを一覧表示します。このガベージコードを消去して適切なMergeタグに置き換えることができるように、すべてが整っています。したがって、問題。マージモジュールには、それらが配置される場所に韻や理由はありません。メインフォルダを探すためのロジックは見つかりません。唯一の本当の共通点は、ディレクトリ、コンポーネント、ファイル、およびレジストリタグがすべてGUIDで終わるIDを持っていることです。任意のアイデアをいただければ幸いです。マージモジュールのリストを検索し、ファイル、コンポーネント、およびディレクトリのリストを取得するためのフレームワークがすでに用意されています。何を探すべきかわからないので、1つまたは2つのモジュールに特化しているわけではありませんが、理論的にはすべてのMICROSOFTモジュールです（他社が他の形式を使用している可能性があることは知っていますが、それはミュートの問題です）。再度、感謝します！マージモジュールのリストを検索し、ファイル、コンポーネント、およびディレクトリのリストを取得するためのフレームワークがすでに用意されています。何を探すべきかわからないので、1つまたは2つのモジュールに特化しているわけではありませんが、理論的にはすべてのMICROSOFTモジュールです（他社が他の形式を使用している可能性があることは知っていますが、それはミュートの問題です）。再度、感謝します！マージモジュールのリストを検索し、ファイル、コンポーネント、およびディレクトリのリストを取得するためのフレームワークがすでに用意されています。何を探すべきかわからないので、1つまたは2つのモジュールに特化しているわけではありませんが、理論的にはすべてのMICROSOFTモジュールです（他社が他の形式を使用している可能性があることは知っていますが、それはミュートの問題です）。再度、感謝します！

マージモジュールのパッケージGUIDを変更する必要があるのはいつですか？

Wix3では、製品とは異なり、マージモジュールに対してパッケージGUIDを明示的に指定する必要があります。私のマージモジュールは、隔週で作成されるMSIで使用されます。これらの隔週のMSIは、別々のインストール（バージョン1、2、3など）と同じマシン上で共存する必要があります。隔週のMSIビルドごとにマージモジュールのパッケージGUIDを変更する必要がありますか？ ？

atl.dll がマシンに登録されていないため、アプリケーションと共に配布している COM dll が登録に失敗するという問題が発生しています。

簡単な修正は、dll で regsvr32 を実行することですが、それよりも少しクリーンなものが必要です。

私は展開の経験があまりなく、atl.dll がマシンに登録されているかどうかを判断できる方法があり、そうでない場合はコードから登録できるかどうか疑問に思っていました。

私は現在、msi インストーラー用の C# カスタム アクションを持っているので、そこにロジックを追加してタスクを実行できる可能性があります。

前もって感謝します。

これは一般的なニーズであるに違いありませんが、ウェブ上でそれへの参照はほとんど見つかりません...

サーバーに 1 つ、Web ヘッドに 1 つ、開発者のマシンに 1 つ、合計 3 つのコンポーネント セットを持つ製品があります。3 つのセットはすべて 1 台のマシンにインストールでき、問題なく共存できます。

昨日のように、各コンポーネントは別の場所にインストールされ、正常に動作していましたが、一部のファイル、gac 化されたアセンブリ、およびレジストリ設定を共有する必要があるため、これは一時的なものでした。今、共有コンポーネントからマージ モジュールを作成しました。この新しいマージ モジュール シナリオは、理想的な条件下でのインストール中に正常に機能し、単一の msi のメジャー アップグレードをすべて把握しました。

問題は、msi のインストール中に、インストール中の msi 内のマージ モジュールのバージョンが、既にインストールされている (別の msi の) バージョンよりも低い場合です。新しいバージョンが古いバージョンで上書きされます。さらに、3 つの msis のいずれかのアンインストール ルーチンの際に、他のインストールされたコンポーネントによってまだ使用されているにもかかわらず、共有されたものが削除されます。

ほとんどの場合、この動作が発生する理由は理解できますが、共有コンポーネント用に別のインストーラーを用意せずにこれらのコンポーネントを共有できるようにインストーラーを構成する方法がわかりません。また、1 つの大きなインストーラーも必要ありません。これではうまくスケーリングできません。

私が望むのは、3 つのインストーラーに、ビルド時に利用可能なマージ モジュール内のコンポーネントの最新バージョンが含まれていることです。インストール時に、共有コンポーネントの新しいバージョンがインストールされている場合は、それらを上書きしないでください。アンインストール (およびアップグレード) 時に、追跡する必要がある参照カウントによって、共有アイテムを削除する必要があるかどうかが決まります。

何か足りない場合のために、マージ ファイルの重要な部分を以下に示します。マージ モジュールのバージョン番号 ("wxy" の y) はビルドごとに増分され、パッケージ ID は固定されたままで、各コンポーネントはShared="yes"(ただし、私もこれなしで試しました）。

さまざまなバージョン番号をレジストリに保存し始めましたが、レジストリのバージョン番号が存在しないかそれ以下の場合にのみ、マージ モジュール機能を条件付きでインストールできるのではないかと考えました。しかし、ドキュメンテーションにあるように、条件付き引数は wxyz を適切に評価できません。ドキュメントでは AppSearch が提案されていますが、AppSearch RegistrySearch は存在を確認することしかできず、バージョン番号の比較もできません。どうやら FileSearch は可能ですが、アセンブリ ファイルのバージョン番号はビルドごとにインクリメントされません。

また、MergeModules には多くの問題があることを読みましたが、おそらくこれらの問題が原因である可能性がありますが、wixlibs もこれらの問題に対する解決策を提供していないようです。

では、マージモジュールのバージョン管理を行う正しい方法は何ですか??? Amazon で「merge module versioning」という TOC エントリがある本を見つけましたが、その本は絶版になっています。:-P

Visual Studio 2008 のプロジェクトを CRT の静的リンクから動的リンクに変換しようとしています。これは簡単で、問題なく CRT MSM とポリシー MSM を Wix ファイルに追加しました。

出力された MSI には満足していませんが、予想よりもはるかに大きくなっています。Orca で MSI を見ると、必要な CRT DLL のコピーが 3 つ表示されます。条件を見ると、セットの 1 つが XP 以前のインストールに使用されています。システム要件は XP 以降なので、元の MSM に触れずにこのコンポーネントを削除するにはどうすればよいですか? これは自動ビルドで行う必要があるため、Orca は可能な解決策ではありません。さらに、Orca で試してみたところ、ファイルとコンポーネントの行を削除した後もファイルサイズは同じままでした。

多少関連していますが、残っているコンポーネントに永続的な属性を設定するにはどうすればよいですか?

UI から入力を取得し、カスタム アクションを介して出力に渡す Visual Studio 2008 内の完全に機能するセットアップ プロジェクトがあります。これは完全に機能します。

ここで、UI はまだセットアップ プロジェクト内にあるが、出力はマージ モジュール内にあるように、これを変更する必要があります。

現在のカスタム アクション データは、UI ダイアログの編集ボックスからの EditHostUrl を使用して、次のようになります。

この値をマージ モジュールに渡し、そこからカスタム アクション データの入力としてプロジェクト出力に使用する必要がありますが、これを達成する方法に関するドキュメントはないようです。

明確にするために、Wix/InstallShield などは現在オプションではありません。また、マージ モジュール内に UI を埋め込まない方がよいでしょう (分離の理由と、Visual Studio ではそのままではサポートされていないため)。

CRT と MFC の両方のマージ モジュールを使用してインストールする VS2008 で ActiveX コントロール インストーラーを構築しています。コントロールが Windows 7 に登録しようとすると失敗します。

Dependency Walker は、コントロールを登録しようとすると、mfc90u.dll、msvcr90.dll、および msvcp90.dll の依存関係が見つからないと言い、インストールに失敗します。マージモジュールはこれを処理することになっていますか? 私の出力 OCX は vsdrpCOMSelfReg オプションで登録されています。私が他のフォーラムで読んでいることから、これは最善の方法ではないかもしれません。この時点で何を試すべきですか?

インストールは Windows XP で問題なく動作します。

2010 年 4 月 8 日更新:

vsdrpCOM に変更すると、インストールは成功しますが (驚くことではありません)、その後 msvcr90.dll が見つかりません。これは CRT のマージ モジュール (microsoft_vc90_crt_x86.msm) によって処理されると思いましたか? Windows XP では、Dependency Walker は、予想どおり SxS フォルダーではなく、Windows/System32 でそれを見つけます。Windows 7 では、まったく検出されません。msvcr90.dll を自分で Windows/System32 に入れる必要がありますか? それはそうではないようです。

2010 年 4 月 20 日更新:

msvcp90.dll と mfc90u.dll はどちらも msvcr90.dll に暗黙的/転送された依存関係を持ち、それらは依存ウォーカー。ただし、コントロールは正常に登録され、それらのライブラリのロードを実行します。これは無視できるものですか？

製品に対応するデバッグ インストーラーを使用してデバッグ ビルドを作成しようとしています。私は Wix を初めて使用するので、ここに含まれる素朴な表現をお許しください。私のプロジェクトのデバッグ DLL は、VS2008 と VS2008SP1 デバッグ ランタイムの両方に依存しています。これらのランタイムをインストーラーにバンドルするために、wix でマージ モジュール機能を作成しました。

インストーラーのデバッグ ビルドを行っている場合は、次のようにその機能を含めます。

唯一の問題は、私のインストーラーには、デバッグ ランタイムにも依存するカスタム アクションも含まれていることです。

では、カスタム アクションもデバッグ ランタイムにアクセスできるように、デバッグ ランタイムをパッケージ化するにはどうすればよいでしょうか。