マージ モジュールの参照がファイル システムと同期しなくなるという問題に定期的に直面しています。2 つのビルドの間で、一部のディレクトリの内容が変更されます。一部のファイルが削除され、一部の新しいファイルが表示されます。マージ モジュールがファイル システムと同期するように、これらの参照を自動的に更新する方法はありますか?

必要なのは、マージモジュール（.msm）からディスクにファイルを抽出できるコマンドラインツールだけです。言い換えると、MSIで可能なのと同じ「管理インストール」機能が必要です。

msiexec / a myProduct.msi TARGETDIR = "C：\ myInstallation" / qn

上記はmsiでのみ機能します（私が知る限り）。したがって、マージモジュールで同じ効果を得るには、msidb.exeとorca.exeを試しています。orcaのドキュメントには次のように記載されています。

多くのマージモジュールオプションは、コマンドラインから指定できます。

マージモジュールからのファイルの抽出

Orcaは、マージモジュールに含まれるファイルを抽出するための3つの異なる方法をサポートしています。Orcaは、個々のCABファイルを抽出し、ファイルをモジュールツリーに抽出し、ターゲットデータベースにマージされた後、ファイルをソースイメージに抽出できます...

ファイルの抽出

マージモジュールから個々のファイルを抽出するには、

... -x ...コマンドラインのオプション。ここで、は新しいディレクトリツリーへの目的のパスです。

指定されたパスは、抽出されたファイルのルートパスとして使用されます。すべてのファイルは、モジュールに埋め込まれたCABファイルから抽出され、指定されたパスに配置されます。抽出されたファイルのディレクトリレイアウトは、マージモジュールのディレクトリツリーに基づいています。

それは私が必要なもののように聞こえます。しかし、私が試してみると、orcaは（指定したmsmに関する情報を含む）エディターを開くだけで、何もしません。私はさまざまなコマンドラインを試しましたが、通常は次のようになります。

orca -x theDirectory theModule.msm

空のフォルダとして「theDirectory」を使用します。私が言ったように-それは何もしませんでした。

次に、msidbを試しました。ここで、いくつかの試行は次のようになります。

msidb -d theModule.msm-w{ストレージ}

msidb -d theModule.msm -x MergeModule.CABinet

最初のケースでは、{storage}に何を入れるべきかわかりません。2番目のケースでは、リテラル文字列「MergeModule.CABinet」が必要であることがわかります（これは予約済みの名前です）。ただし、抽出されたキャビネットは、ファイル階層または「通常の」ファイル名を保持しません。だから私は自分の目的のためにそれを使うことができません。

誰かが私がコマンドラインオプションで間違っていることを説明できますか？これを行うことができる他のツールはありますか？

Visual Studio 展開プロジェクトで展開される Windows .net ソリューションがあります。私のexeは、x86またはx64ウィンドウで正常に動作するwin32アプリです。

ただし、x86 および x64 バージョンで利用可能なサード パーティ ベンダーのマージ モジュール (*.msm) を含めました。

これで、デプロイ プロジェクト全体をコピーして msm を変更するだけで済みますが、私は怠け者なので、インストーラーに両方の msm を含めて、クライアント マシンのプロセッサに適合するモジュールのみをインストールするのが最善の方法です。

Visual Deployment プロジェクトでこれを行う方法はありますか?
マージ モジュールには、含まれている exe / dll ファイルのような Condition プロパティがないようです。

Crystal Reports XI .dll (craxdrt.dll、crviewer.dll) をクライアント コンピュータに展開する必要があります。Craxdrt.dll には多くの依存関係があります。これを行う最も簡単な方法は、提供されているマージ モジュールを使用することであることがわかりました。常に ClikOnce の展開に依存していたので、これを行う方法を完全に失っています。

重要な場合: .exe は VB6 で記述されていますが、セットアップ プロジェクトを作成するための Visual Studio 2010 があります。

ありがとう！

1 つの .msi インストーラー パッケージに変換したい .msm マージ モジュール (Crystal Reports 用) がいくつかあります。Visual Studio セットアップ プロジェクトでこれを行うことはできますが、.Net をパッケージに含める必要が生じます。

• Visual Studio (2008/2010) に回避策はありますか?
• このタスクを実行できる無料のサードパーティ ユーティリティはありますか?

ファイル「MyFile.txt」を特定の場所にインストールするマージ モジュールがあり、そのマージ モジュールを使用したいとします。モジュールをマージします。

これを行うことは可能ですか？（ボーナスポイントについては、Wixを使用してこれを行うにはどうすればよいですか）

更新:大まかに言えばMyFile.txt、他のユーザーに提供するインストール可能なアイテムのパッケージ アップ コンポーネントの一部であり、これらのコンポーネントを独自のものと組み合わせてインストーラーを生成します。

MyFile.txt理想的な世界では、出力に新しいファイルを追加するだけで済みますが、これは、現在、最終インストーラーでアイテムを変更または置換する機能 (など) を備えている既存のシステムの置き換えです。マージ モジュールで同じことを行う能力は、移行パスが困難になります。

より良い解決策がある場合、パッケージ化されたコンポーネントはマージ モジュールである必要はありませんが、マージ モジュールは賢明な選択のように思われ、他のすべての点で、インストーラー ロジックの非常に優れた再利用可能なパッケージを提供します。

MSM ファイルを含めて Inno-Setup 内で実行できますか? そうでない場合、どうすればマージ モジュールを適切にインストールできますか? アプリケーションに SOAP3 をインストールする必要があり、少しガイダンスが必要です。MSM をカスタム MSI にラップしてから、Inno に MSI ファイルを実行させる必要がありますか? MSM 用のクリーンで愚かな MSI ファイルを作成するには、何を使用しますか? 事前に助けてくれてありがとう。

InstallShield 2010でゼロから作成されたInstallScriptプロジェクトがあります。これには、特に、MSMファイルをラップする3つのネイティブInstallShieldオブジェクトと4つのInstallShieldマージモジュールホルダーオブジェクトが含まれています。

プロジェクトを最初にテストしたときは、クリーンな環境に正常にインストールされましたが、新しいバージョンにアップグレードしようとすると、4つのマージモジュールホルダーオブジェクトのそれぞれで「エラー1706。製品XXXXの有効なソースが見つかりません」というメッセージが表示されました。 。

ネットで調べてみたところ、これはWindowsインストーラーのエラーであり、元のインストールメディアがなくなった後でも、MSIファイルがマシン上に存在している必要があるために発生します。これを確認するための推奨される方法は、[マージモジュールホルダーオブジェクト]プロパティダイアログの[msiパッケージをローカルにキャッシュする]チェックボックスをオンにすることです。

4つのマージモジュールすべてについてそのボックスにチェックマークを付けて再テストしましたが、問題は解決しませんでした。次に、これらのマージモジュールが実際にハードディスクのどこに配置されているかを調べました。プロパティダイアログには、実行時に{ProductGUID}<DISK1TARGET>に解決されると書かれています。テストマシンを見ると、4つのマージモジュールすべてが同じ場所に書き込んでいるように見え、それによって互いのMSIファイルが上書きされていました。C:\Program Files\InstallShield Installation Information\

これを回避するために、各マージモジュールを編集して、一意のパス<DISK1TARGET>\{Name}にキャッシュしました。コンパイルして再度テストしたところ、各マージモジュールが実際に一意のサブフォルダーに保存されていることがわかります。ただし、アップグレードしても、4つのエラー1706メッセージすべてが引き続き表示されます。

誰かアイデアはありますか？明らかな何かが欠けていると確信していますが、それはどこにも文書化されていないようです。:-)

アップデート：

InstallShieldフォーラムの多くの投稿によると、InstallShieldは、InstallScriptプロジェクトをビルドするたびに、埋め込まれたMSIごとに新しい製品GUIDを生成するようです。更新プロセス中に、InstallShieldエンジンはターゲットマシンにキャッシュされた各MSIファイルを新しいバージョンで上書きしますが、それらを実行する場合、Windowsインストーラーは「これは新しい製品です。古い製品のMSIはどこにあるので、それをアンインストールできますか？」、したがってエラー。

ビルドごとに組み込みMSIごとに製品GUIDを再生成しないようにInstallShieldに指示することはできますか？確かに、この動作は、マージモジュールをInstallScriptプロジェクトに埋め込むというアイデア全体を嘲笑しますか？:-(

マージモジュールとは何ですか？それらはどのように使用されますか？それらは.msmファイルだと聞きましたが、これまで見たことがありません（.msiしか見たことがありません）。

msiファイルを作成するときに使用されますか？それらは商用ソフトウェアと一緒に配布されていますか（おそらくmsiファイルと一緒に配布されていますか？）

それらのポイントは何ですか？開発されたソフトウェアと一緒にインストールする必要がある（したがって一緒に配布する）必要がある一般的なサードパーティまたはMicrosoftコンポーネントのインストーラーの実装を隠すためですか？

ありがとう！

個別のマージモジュールを備えたx86用のVisualC++2008ランタイムコンポーネントのインストールを含むWiXプロジェクトがあります。

残念ながら、MSIv4.5の.msmにはよく知られた問題があります。具体的には、.msmカスタムアクションSxSUninstallCAは、アンインストール時に完了するのに20分かかります。

つまり、簡単に言うと、新しいバージョンの製品から.msmを削除し、.exeファイルを使用してVC++コンポーネントをサイレントインストールすることにしました。

これだけ（そしてもちろんProductCode）を変更すると、インストーラーはマシンに既にインストールされている製品を検出せず、古いバージョンを最初にアンインストールせずに通常のインストールを実行します。

ここで何が起こっているのかについて何か考えはありますか？MSIはUpgradeCodeとProductCodeをチェックして、製品がシステムにすでにインストールされている別の製品のアップグレードであるかどうかを検出する必要がありますか？