.msi ファイル自体を (おそらくカスタム アクション経由で) インストールできますか?
https://stackoverflow.com/questions/88078
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
インストールプロセス中に、含まれているファイル/コンポーネントとともにそれ自体を 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 インストーラーのアンインストール プロセス (プログラムの追加と削除など) による削除は許可されません。保存する必要があります。
明らかに (当然のことだと思いますが、私は間違っていますか?) MSI をメディア/CAB (鶏が先か卵が先かというシナリオ) にファイルとして含めることはできないため、インストール前にカスタム アクションを介して行う必要があると思います。プロセスでは、元の MSI を MSI DB のメディア/CAB に追加し、ファイル テーブルに適切なエントリをオンザフライで追加します。これは可能ですか?可能であればどのようにすればよいですか?
コンテンツ ファイルがアプリと一緒にのみ配布されるコンテンツ配布モデルを考えてみましょう。コンテンツは、実行時にエンド ユーザーによってアプリを介して作成され、アプリとコンテンツの両方を含む配布可能な EXE にパッケージ化されます。
MyApp のインストーラーは MSI のままである必要がありますが、Bootstrapper EXE によって実行できます。インストールされた MyApp.exe は、MyApp.msi と EXE の両方にアクセスできる必要があります。実行時に、MSI によってインストールされるベース (空の) MyAppBootstrapper.exe と、エンドユーザー。EXE のリソース MSI は、ランタイム パッケージ化を行うアプリのインストールに使用されるものと同じである必要があります。
WIX は MyApp と一緒にインストールすることはできません。
実行時/パッケージ化時にネットワーク依存関係が存在することはできません (つまり、Web サービス経由でパッケージ化を行うことはできません - ローカルで行う必要があります)。
私はカスタム アクション (マネージドおよびアンマネージド、DTF などによる) に精通しています (そして使用しています)。
解決
次のように、非圧縮メディアを wxs に追加します。
<Media Id='2'/>
次に、次のような File 要素を含むコンポーネントを作成します。
<File Source='/path/to/myinstaller.msi' Compressed='no' DiskId='2' />
これにより、インストーラーは、インストール メディア上の、インストールされている msi と同じフォルダーにある「myinstaller.msi」というファイルを検索します。上記のソース パスはダミー ファイルを指す必要があります。これは Wix を和らげるためにのみ存在します。
編集:次のサンプル test.wxs は、それが機能することを示しています。test.msi ファイルを生成し、それ自体を c:\program files est にインストールします。wix を緩和するには、ダミーの test.msi ファイルを text.wxs と同じフォルダーに置く必要があることに注意してください。
<?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>
他のヒント
1 つの .MSI パッケージがその「内部」から別の .MSI パッケージを起動することを、 ネストされたインストール, 、そしてそれは 悪いジュジュ (規則 20 を参照)。Windows インストーラーには、現在のインストールを管理するために使用するグローバル データがあり、同時に複数のインストールを適切に処理できません。同じ理由で、あるインストールを開始し、最初のインストールの進行中に別のインストールを開始しようとすると、通常、「別のインストールが進行中です。完了するまでお待ちください」という内容のポップアップが表示されます。
通常、ブートストラップと呼ばれるプログラム（それ自体はインストールパッケージではないと思います）を使用できますが、 含まれています リソースとしてのインストール パッケージ (.MSI や .EXE など) (圧縮されている場合があります)。ブートストラップ プログラムのアクションは、通常はファイルにリソースを抽出/展開することです。 %TEMP% ディレクトリに移動し、抽出した .EXE を起動するか、抽出した .MSI 上で MSIEXEC を実行します。ブートストラップには複数のリソースを含めることができ、メイン パッケージの前に前提条件をインストールする必要がある場合は、それらを 1 つずつ抽出してインストールできます。または、複数のパッケージを個別のファイルとして配布し、ブートストラップで配布メディアから 1 つずつ直接実行/インストールすることも、ターゲット マシンにコピーしてそこから一連のインストールを実行することもできます。
WiX 自体はインストールされません。これは、.MSI パッケージを構築できるツールです。WiX プロジェクトのウィッシュリストには汎用ブートストラップ プログラムが含まれていますが、まだ実装されていません。他にも利用可能なブートストラップがあります。 これです.
カスタム アクションは必要ありません。実際、ブートストラップ自体は Windows インストーラー インストール パッケージではないため、「カスタム アクション」には意味がありません。また、マネージド/アンマネージド/DTF について理解できるほど CA に精通している場合は、可能な限りカスタム アクションを回避するのに十分な知識があることになります。（ニヤリ）
ブートストラップにとって、MSI ファイルを一時フォルダーではなく、事前に定義された場所に抽出する方がはるかに簡単だと思います。たとえば、C:\Documents and Settings\All Users\Application Data\My Company\My Product Install Cache に保存します。インストールが完了すると、ブートストラップは MSI ファイルをそこに残したままにします。ある段階でユーザーが製品を再インストールすることにした場合、Windows インストーラーはソース MSI ファイルを見つけることができます。
また、このファイルへのパスを追加します ファイル削除テーブル アンインストール時に削除されるようにします。使用できます RemoveFile 要素 そのためにWiXで。
したがって、理解できれば、アプリにコンテンツ ファイルを含む変換 (MST) を作成させ、それをベース MSI に適用させることになると思います。まだ理解できたのか自信がありませんが。:)
MSI キャッシュ パスを既知の場所に設定します。
その後、実行時に MSI を「編集」する必要がある場合は、VBScript などを使用します。
しかし、それでも私は「なぜ?!」と尋ねます。
複数の MSI ファイルを展開する方法にも取り組んでいます。MSI ファイルをバンドルして一度に 1 つずつ実行する bootstrapper.exe プログラムがあります。これでほとんどの場合の問題が解決します。
解決しないケースは、インストールの GPO (グローバル ポリシー オブジェクト) 配布です。GPO では、インストールを実行するために dot-msi ファイルが必要です。
これを行うために、問題をほぼ解決した（ただし完全ではない）私がやったことは次のとおりです。dot-msi ファイルをインストーラーのファイル テーブルに置き、ブートストラップをバイナリ テーブルに置き、InstallExecuteSequence の InstallFinalize の後に挿入されたカスタム アクションから実行します。もちろん、トップレベルの MSI は _MSIExecute ミューテックスを保持しているため、ブートストラップは他の MSI を実行できません。
少し先に進むのはかなり簡単でした。ブートストラップがトップレベルのインストーラーに制御を戻して続行するようにしました。次に、最上位のインストールが完了するのを待機する WaitForSingleObject 呼び出しを追加しました。これにより、ブートストラップは引き続きインストールを完了できます。
私の問題は、GPO のインストールが起動時に行われ、サブインストーラーが完了して GPO がマシンを再起動する前にトップレベルのインストールが完了することです。
トップレベルのインストールは、後でインストールが実際に失敗する可能性がある場合にも成功ステータスを返します。
ブートストラップが完了するまでトップレベルのインストールが完了しないようにブロックする方法をまだ探しています。
