9

インストール プロセスで、含まれているファイル/コンポーネントと共にそれ自体を TargetDir に展開する MSI を構築したいと考えています。

そのため、MyApp.msi のファイル テーブルには、MyApp.exe と MyAppBootstrapperEmpty.exe (リソースなし) が含まれています。

ユーザーは MyAppBootstrapperPackaged.exe を起動します (MyApp.msi をリソースとして含み、インターネットのどこかから、または電子メールなどから取得します)。MyAppBootStrapperPackaged.exe は、MyApp.msi を一時フォルダーに抽出し、msiexec.exe を介して実行します。

msiexec.exe プロセスが完了したら、MyApp.msi、MyBootstrapperEmpty.exe (および %ProgramFiles%\MyApp フォルダー内の MyApp.exe が必要です。これにより、MyApp.exe は実行時に MyApp.msi に確実にアクセスできるようになります (以下を作成するため)。言及されたパッケージ内容)。

MyAppBootstrapper*.exe は、MyApp.msi を %ProgramFiles%\MyApp フォルダーにコピーしようとする可能性がありますが、そのためには昇格が必要であり、Windows インストーラーのアンインストール プロセス ([プログラムの追加と削除] などから) による削除は許可されません。保存する必要があります。

明らかに（明らかだと思います-間違っていますか？）メディア/ CAB（鶏と卵のシナリオ）にファイルとしてMSIを含めることはできないため、インストール前にカスタムアクションを介して実行する必要があると思います元の MSI を MSI DB のメディア/CAB に追加し、その場でファイル テーブルに適切なエントリを追加します。これを行うことができますか？

コンテンツ ファイルがアプリと一緒にのみ配布されるコンテンツ配布モデルを考えてみてください。コンテンツは、実行時にアプリを介してエンド ユーザーによって生成され、アプリとコンテンツの両方を含む配布可能な EXE にパッケージ化されます。

MyApp のインストーラーは MSI のままである必要がありますが、Bootstrapper EXE によって実行される場合があります。インストールされた MyApp.exe は、MyApp.msi と EXE の両方にアクセスできる必要があります。EXE は、MSI によってインストールされる基本 (空の) MyAppBootstrapper.exe からアプリによって実行時に「アセンブル」されます。エンドユーザー。EXE のリソース MSI は、ランタイム パッケージを実行するアプリのインストールに使用されたものと同じである必要があります。

WIX は MyApp と一緒にインストールする必要はありません。

実行時/パッケージング時にネットワークに依存することはありません (つまり、Web サービスを介してパッケージ化を行うことはできません。ローカルで行う必要があります)。

私はカスタム アクション (マネージドおよびアンマネージド、DTF 経由など) に精通しています (そして使用しています)。

4

6 に答える 6

9

次のように、圧縮されていないメディアを wxs に追加します。

<Media Id='2'/>

次に、次のような File 要素を持つコンポーネントを作成します。

<File Source='/path/to/myinstaller.msi' Compressed='no' DiskId='2' />

これにより、インストーラーは、インストール メディアの "myinstaller.msi" というファイルを、インストールされている msi と同じフォルダーで検索します。上記のソース パスはダミー ファイルを指している必要があります。

編集: 次のサンプル test.wxs は、それが機能することを示しています。それ自体を c:\program files\test にインストールする test.msi ファイルを生成します。wix をなだめるには、text.wxs と同じフォルダーにダミーの test.msi ファイルを配置する必要があることに注意してください。

<?xml version='1.0' encoding='utf-8'?>
<Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'>
   <Product
         Name='ProductName'
         Id='*'
         Language='1033'
         Version='0.0.1'
         Manufacturer='ManufacturerName' >
      <Package
            Keywords='Installer'
            Description='Installer which installs itself'
            Manufacturer='ManufactererName'
            InstallerVersion='100'
            Languages='1033'
            Compressed='yes'
            SummaryCodepage='1252'/>

      <Media Id='1' Cabinet='test.cab' EmbedCab='yes'/> 
      <Media Id='2' /> 

      <Directory Id='TARGETDIR' Name="SourceDir">
         <Directory Id='ProgramFilesFolder'>
            <Directory Id='TestFolder' Name='Test' >
               <Component Id="InstallMyself">
                  <File Source="./test.msi" Compressed="no" DiskId="2" />
               </Component>
            </Directory>
         </Directory>
      </Directory>

      <Feature
            Id='Complete'
            Display='expand'
            Level='1'
            Title='Copy msi file to program files folder'
            Description='Test'>

         <ComponentRef Id="InstallMyself" />
      </Feature>

   </Product>
</Wix>
于 2009-02-18T00:52:54.280 に答える
2

ある.MSIパッケージに「内」から別の.MSIパッケージを起動させることは、ネストされたインストールと呼ばれ、それは悪いjujuです（ルール20を参照）。Windowsインストーラーには、現在のインストールを管理するために使用するグローバルデータがいくつかあり、同時に複数のインストールを適切に処理することはできません。同じ理由で、あるインストールを開始してから、最初のインストールの進行中に別のインストールを開始しようとすると、通常、「別のインストールが進行中です。完了するまでお待ちください」というポップアップが表示されます。

通常はブートストラッパー（これが参照していると思います）と呼ばれるプログラムを作成できます。このプログラム自体はインストールパッケージではありませんが、リソースとしてインストールパッケージ（.MSIや.EXEなど）が含まれています。おそらく圧縮されています。ブートストラッパープログラムのアクションは、リソースをファイル（通常は%TEMP%ディレクトリ内）に抽出/展開してから、抽出された.EXEを起動するか、抽出された.MSIでMSIEXECを実行することです。メインパッケージの前に前提条件をインストールする必要がある場合、ブートストラッパーには複数のリソースを含めることができ、それらを1つずつ抽出してインストールします。または、複数のパッケージを個別のファイルとして出荷し、ブートストラッパーに配布メディアから直接実行/インストールさせるか、ターゲットマシンにコピーして、そこから一連のインストールを実行するか、または...

WiX自体はインストールされません。これは、.MSIパッケージを構築するためのツールです。WiXプロジェクトのウィッシュリストには一般的なブートストラッパープログラムがありますが、まだ実装されていません。利用可能な他のブートストラッパーがあります、例えばこれ。

カスタムアクションは必要ありません。実際、ブートストラッパー自体はWindowsインストーラーのインストールパッケージではないため、「カスタムアクション」には意味がありません。また、CAに精通していて、マネージド/アンマネージド/ DTFについて知っている場合は、できる限りカスタムアクションを回避するのに十分な知識があります。（ニヤリ）

于 2008-09-18T04:42:54.443 に答える
2

ブートストラッパーは、一時フォルダーではなく、事前定義された場所にMSIファイルを抽出する方がはるかに簡単だと思います。たとえば、C：\ Documents and Settings \ All Users \ Application Data \ My Company \ My ProductInstallCacheに移動します。インストールが完了すると、bootstrapperはMSIファイルをそこに置いたままにします。ある段階でユーザーが製品を再インストールすることを決定した場合、WindowsインストーラーはソースMSIファイルを見つけることができます。

また、このファイルへのパスをRemoveFileテーブルに追加して、アンインストール時に削除されるようにします。そのためにWiXでRemoveFile要素を使用できます。

于 2008-09-19T23:01:07.607 に答える
1

したがって、理解できれば、アプリにコンテンツファイルを含む変換（MST）を作成させ、それをベースMSIに適用させると思います。しかし、私はまだ理解しているとは確信していません。:)

于 2008-09-17T22:31:22.447 に答える
0

MSI キャッシュ パスを既知の場所に設定します。

次に、実行時にMSIを「編集」する必要がある場合は、VBScriptなどを使用します。

しかし、それでも、私はなぜ!?!と尋ねます。

于 2008-11-18T23:18:37.673 に答える
0

また、複数の MSI ファイルを展開する方法にも取り組んでいます。MSI ファイルをバンドルして一度に 1 つずつ実行する bootstrapper.exe プログラムがあります。これは、ほとんどの場合、私の問題を解決します。

解決しないケースは、インストールの GPO (Global Policy Object) 配布です。GPO では、インストールを実行するために dot-msi ファイルが必要です。

これを行うには、問題をほぼ解決するために私がしたことを次に示します（ただし、完全ではありません）。dot-msi ファイルをインストーラーのファイル テーブルに配置し、ブートストラップをバイナリ テーブルに配置して、InstallExecuteSequence の InstallFinalize の後に挿入されたカスタム アクションから実行します。もちろん、最上位の MSI が _MSIExecute ミューテックスを保持しているため、ブートストラップは他の MSI を実行できません。

少し先に進むのはかなり簡単でした。ブートストラッパーがコントロールを最上位のインストーラーに戻して続行するようにしました。そして、WaitForSingleObject 呼び出しを追加して、トップ レベルのインストールが完了するまで待機し、ブートストラッパーは引き続きインストールを完了できます。

私の問題は、起動時に GPO のインストールが行われ、サブ インストーラーが完了する前にトップ レベルのインストールが完了し、GPO がマシンを再起動することです。

インストールが後で実際に失敗する可能性がある場合、トップレベルのインストールも成功ステータスを返します。

ブートストラップが完了するまで、最上位のインストールが完了するのをブロックする方法をまだ探しています。

于 2009-05-08T15:43:54.613 に答える