MSI ファイルは、組み込み機能としてサイレント インストールをサポートするように特別に設計されています。いつでも GUI をスキップできます。ただし、一部の MSI ファイルには設計上の欠陥があり、サイレント モードではインストールが不完全になります。これは重大な設計エラーです。この問題については、次の場所で説明されています。
短いバージョン: Electron Builder から msi ファイルをパラメーター化する方法
- PUBLIC PROPERTIES と変換を使用して、MSI パッケージのインストールをカスタマイズします。
MSI インストールの構成
MSI のサイレント インストールに関しては、msiexec.exe コマンド ラインから、または変換と呼ばれるものを元の MSI ファイルに適用することによって、セットアップを構成する必要があります。これらのオプションは両方とも、以下の別のセクションで説明されています。
MSI ファイルが適切に設計されている場合、msiexec.exe コマンド ラインから、または変換ファイルを使用して元の MSI を変更することにより、PUBLIC PROPERTIES (常に大文字) を設定できます。これらの操作について以下に説明します。パブリック プロパティは、MSI ファイルの "プロパティ テーブル" で見つけるのが最も簡単です。任意の MSI ツールを使用して *.msi ファイルを開き、プロパティ テーブルに移動します。変換を生成して MSI ファイルを表示 (および編集) するために使用できる無料の MSI ツールもいくつかあります。2 つ (またはそれ以上) の MSI ファイルの内容を比較するにはどうすればよいですか? (一番下にリンクします)。
適切に設計された MSI セットアップは、これらのパブリック プロパティを介して完全に構成可能です。不適切に設計された MSI ファイルはそうではありません。不適切に設計された MSI ファイルは、変換ファイルを使用して微調整することをお勧めします (これにより、インストール時に適用される MSI ファイル全体に大幅な変更を加えることができます)。パブリック プロパティを設定すると、セットアップ作成者によって設計されたように、パブリック プロパティによって構成可能なものだけを変更できます。変換は、MSI ファイル全体のほとんどすべてを変更できます。
一般に、すべての企業のサイレント展開は、トランスフォームを使用して、企業標準の「MSI ファイルを整形」して行われます。これは、企業の展開に非常に効果的なツールであり、広く使用されています。
安全に保管するためのいくつかのリンク:
MSIの「特徴」
MSI は直感に反することが多く、内部ではやや複雑です。ただし、MSIファイルを単純化しすぎると、1つ以上の「機能」が含まれます。これらの機能は、まとめて「アプリケーションのビット」を構成します。機能は、ソフトウェア全体のインストールの原子単位である「コンポーネント」で構成されますが、これは非常に技術的な詳細です。この回答は、MSI のユーザーに公開された部分に関するものです。
スクリーン ショット:実際の MSI パッケージで機能がどのように見えるか (スクリーン ショット)。
通常、対話的にセットアップを実行すると、これらの機能のリストを見つけることができ、カスタマイズ インストール ダイアログに移動できます (常に表示されるとは限りません)。ここに表示される機能は、アプリケーションの「ユーザーが構成可能な」部分であり、除外または包含を選択できます (一部は必須です)。上記のように、有能なツールで MSI を開くことによって、これらの機能を見つけることもできます (以下のセクション 2 のリンクも参照できます)。
典型的な機能は次のとおりです: CoreまたはProgram、Dictionaries、Samples、Plug-Ins、Spell Checker、SDK & Developer Tools (開発ツール用) など...一部の機能は必須です (インストールする必要があります) - 上記の例はCoreとProgramです、その他はオプションであり、アプリケーションの起動には必要ありません (上記の開発ツール機能など)。アプリケーションに機能を「オンデマンド」でインストールさせることができます。たとえば、ユーザーがスペル チェックを開始したときにスペル チェッカーをインストールすることができます。
私の経験では、ほとんどのユーザーはアプリケーション全体をインストールすることを望んでいます。多くのユーザーは、Windows インストーラーが予期せずポップアップし、スペル チェッカー コンポーネントのインストールを開始すると、非常にイライラします。率直に非常に理解できます。ただし、特にシステム管理者がネットワークで機能を利用したくない場合は、ほとんど使用されない少数のユーザーのみが関心を持つモジュラー コンポーネントをオプション コンポーネントにすることができます。これは確かに開発者ツールの場合です。これらは通常のユーザーが利用できるべきではありません。彼らは、人々が自分の足を撃つために必要なすべてのロープである傾向があります.
前述のように、MSI インストールをカスタマイズするには、通常、 (1) msiexec.exe カスタム コマンド ラインを使用する方法、または (2)変換ファイルを使用する方法の 2 つがあります。
1: msiexec.exe コマンド ライン:
インストール中にどの機能をインストールするかを制御する最も簡単で軽量な方法は、msiexec.exe
コマンド ラインを使用して機能の選択を指定することです。機能の構成に使用される一連のプロパティがあります。ただし、ほとんどの場合、次のように指定するだけで十分ADDLOCAL
です。
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" /qn
上記のコマンド ラインは、" Program " および " Dictionaries " 機能をローカルにインストールする必要があることを指定します (機能名は大文字と小文字が区別されます! )。通常はこれで十分ですが、同様の方法で REMOVE プロパティを使用して削除する機能を指定することもできます。ADDLOCAL=ALL
MSI のすべての機能をローカル ディスクにインストールする特別なスイッチがあります (これをオーバーライドする追加のロジックが MSI にない場合)。MSDN の ADDLOCAL プロパティ。
パブリック プロパティで定義する非常に一般的なものは、アプリケーションのライセンス キーです。次のコマンド ラインは、" Program " および " Dictionaries " 機能をインストールし、シリアル キー "1234-1234" を適用するように指定します。
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
上記の説明で暗示されているように、各セットアップのカスタマイズ可能なプロパティのリストは常に異なります。ほとんどのプロパティは MSI ファイルのプロパティ テーブルに一覧表示されていますが、プロパティ テーブルに定義されていない一部のプロパティを設定できる場合もあります。ほとんどの場合、これはセットアップ GUI からのみ設定されるプロパティに関連しています (ほとんどの場合、セットアップの設計エラーを示します)。すべてのプロパティは、適切に作成されたパッケージのプロパティ テーブルで定義する必要があります。
ベンダーのダウンロード ページでドキュメントを探し、サイレント インストールまたは大規模な展開に関するドキュメントについてサポートを依頼してください。標準的な回答テンプレートがあれば、すぐに回答できます。展開を管理している企業は、常にこれを提供できます。私の見解では、理想的な方法は、さまざまな展開設定を説明する 1 ページの PDF です。率直に言って、彼らがこれを提供できない場合は、彼らにいくらかの熱を与えてください;-)。
2: 変換:
MSI ファイルは基本的に、COM 構造化ストレージ ファイル(ファイル内のファイル システム) にラップされた SQL データベースです。変換ファイルは、Orca (SDK リンク)、Installshield、または賢い、Advanced Installer など(さまざまなツールの説明へのリンク)。これらのトランスフォームは、MSI のほぼすべての設定またはデータベース フィールドをカスタマイズまたはオーバーライドできます。これには、インストールされている「アプリケーションの一部」(機能) も含まれます。トランスフォームを作成したら、msiexec.exe コマンド ラインでそのアプリケーションを MSI に指定します。
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
Windows インストーラーは、インストールの開始前に MSI とトランスフォームをマージします。これは、MSI のインストール方法を完全に制御したい大規模な組織で使用されるアプローチです。MSDN の TRANSFORMS プロパティ。
前述のように、これはMSI のすべての設定を変更できるオプションです。不適切に設計された MSI ファイルに大幅な修正を適用して、信頼性の高い展開を可能にすることができます。これは「アプリケーション パッケージャー」によって行われます。彼らの仕事は、すべてのセットアップを企業標準内で機能するように調整することです。彼らは、最も知識の豊富な MSI スペシャリストの 1 人である可能性があります。彼らは、MSI ファイルに多くの奇妙なものを見ています。
多くのツールを使用して変換を作成できます。ここでは、MSI ファイルを比較するというより技術的なコンテキスト内で、そのようなツールについて説明します。下部にある無料ツールのリストに直接ジャンプしてください: 2 つ (またはそれ以上) の MSI ファイルの内容を比較するにはどうすればよいですか?
アンチパターンと Windows インストーラーの企業メリット:
Windows インストーラーには多くの設計上の癖があり、開発者にとっては特に厄介な場合があります。確かに、アンチパターンに近い問題がいくつかあります。
潜在的なアンチパターン
- 困難な複数インスタンスのインストール
- 特にサービスのインストールでは、比較的一般的な要件
- 直感に反するファイル上書きルール( symantec )
- 特にバージョン管理されていないファイルの奇妙なルール
- すべてのファイルを強制的に上書きする非常識な機能 ( REINSTALLMODE = amus)
- システム全体で共有ファイルをダウングレードできます
- 古いパッケージが新しいパッケージの後にインストールされ、一部の共有ファイルのみがダウングレードされる可能性があるため、バージョン資産の一貫性が失われる可能性があります。
- バージョン管理されていないファイル (およびレジストリ設定) の設定をダウングレードまたはワイプアウトできます
- 同じバージョンの使用中のファイルを不必要に置き換えようとするため、要求された再起動の数が大幅に増加する可能性があります。
- 非常に具体的な問題がさらにいくつかあります。いつの日か、それらすべてを書き上げます
- アップグレード後にレジストリ内の
ユーザー データが予期せずリセットされる
- これは非常に問題です。これを経験した場合、それはあなたではなく、テクノロジーです
- 多くの場合、サービス資格情報のログインとシリアル キーで見られます
- この問題を回避するためのテクニック
- セットアップからHKCUレジストリキーを書き込むのを避け、代わりにアプリケーションから書き込んでください。あなたのセットアップはそれらに干渉することはありません - それは値の知識をまったく持っていません.
- レジストリ データを独自の機能に入れる (自己修復の問題を防ぐ必要があります)
- 空のコンポーネント GUID を持つコンポーネントを介してレジストリ データをインストールします (その後、修復または自己修復中に書き換えられることはありません)。
- key-path が存在する場合、コンポーネント フラグを決して上書きしないように設定します。
- 代わりに、カスタム アクションを使用して HKLM データ (ライセンス キーなど) をレジストリに書き込みます (これには別の問題がありますが、データがいつ書き込まれるか (どのインストール モードで) を完全に制御できます)
- 安定したレジストリ キー パスを保持していることを確認してください。フラグ値 KeyPath = 1 を設定し、決して変更しないでください - そして決定的に - コンポーネント GUID も変更しないでください
- REINSTALLMODE を「amus」に設定しないでください。プロパティ テーブルにその値をハード コードしないでください。
- 頭のてっぺんからそれらすべてを思い出すことができれば、さらにトリックと経験則があります:-)。
- 複雑なアップグレード メカニズム
- マイナーアップグレードには多くの制限と制限があります
- メジャー アップグレードには他の課題があります (レジストリ データのリセット、インストール後のファイルの欠落、インストール後の COM ファイルの自己修復など...)
- つまらない GUI 機能
- ロケット科学ではありませんが、やや複雑です
- 適切にスムーズな GUI を実装するためのイベントと機能が不足している
- 驚くほど複雑なパッチ
- 効果的に使うのは非常に難しい
- 「ホットフィックス」としての使用以外はお勧めしません。つまり、いくつかのファイルを更新するか、インストールされたセットアップのアンインストール シーケンスで特定の MSI ファイル エラーを修正します。
- いくつかのパッチコメント:
- カスタム アクションの非常に複雑な実装
- 複雑なシーケンス
- 複雑な条件付け
- 複雑ななりすまし / 権限の昇格による部分的な実行
- 全体的に非常にエラーが発生しやすいです。
- ユーザーごとのセットアップの精彩を欠いた実装
- 概念的に疑わしい (フォルダーのリダイレクト、予測不可能性、ユーザーごとのインストールとマシンごとのインストールの両方をサポートする現実世界でのセットアップの不可能性)
- アップグレード、アンインストール、パッチ適用が複雑。さまざまなユーザーやマシンごとに製品を複数回インストールできます
- 主観的なメモとして、ユーザーごとのセットアップの現在の実装は、完全な展開アンチパターンであると考えていることを認めなければなりません。私はそれを決して使用せず、強制されない限り使用しないと主張します.
- 予期せぬ自己修復
- XML ファイルへの書き込み機能が組み込まれていない
- IIS インストールの貧弱な機能
- 問題の一部は、バージョン管理されていないファイルのファイル上書き規則です (予測できない結果が生じる可能性があります)。
- 正直なところ、IIS にはまったく新しい展開テクノロジが必要になる場合があります。これは、バージョン管理されていないファイルの処理を完全に予測可能な方法で定義する方法であり、実用的な現実世界のオプションを備えています。おそらく、強制的に置換されたバージョン管理されていないファイルの自動バックアップ、すべて正しいバージョンでなければならない一貫したテキスト ファイル (「アセンブリ」) のグループの強制など...
- また、IIS および仮想フォルダーとサイトの複雑な構成に関する他のいくつかの問題
- カスタムアクションで「終了コードのチェック」をずさんに有効にすると、パッケージをアップグレードまたはアンインストールできなくなる可能性があります (重大な調整なしでは)。
- 主要なアップグレードが失敗し、重要でないもののロールバックを引き起こす可能性があります
- マイナー アップグレードを使用して、アンインストール シーケンスまたは不適切なコンディショニングを修正できます。
- 他にもいくつかあります...
- 実際、実際の MSI パッケージ自体でよく見られる一般的なアンチパターン(テクノロジーの誤った使用) の膨大な要約を作成しました。
- 私はすべてのコンテンツを支持することができますが、フォーマットは良くありません.それは厄介なブレインダンプですが、それが物事を成し遂げる唯一の方法であるように見えることがあります. それが何であるかを理解してください。
- カスタム アクションの過剰使用は、別の MSI 問題です。この背後には複雑な核心がありますが、全体的な問題は、人々が MSI や WiX などの拡張機能 (または Installshield や Advanced Installer などの商用ツール) で完全に機能する既存のソリューションを使用していないことです。ここに要約があります: WiX / MSI セットアップでカスタム アクションの使用を制限することがなぜ良い考えなのですか?
カスタム アクション (カスタム インストール ロジック) の実装が非常に複雑であるという問題は、避けられないと主張することができます。カスタム アクションを作成する行為は、必要に応じて強力で有能でなければなりません。したがって、複雑になります。テクノロジ自体が展開に一般的に使用されるものを提供する場合、カスタム アクションが必要になることはほとんどありません。つまり、利用可能な場合はカスタム アクションではなく組み込みの MSI 機能を使用するか、利用可能な場合は WiX またはサード パーティの展開ソフトウェア拡張機能を使用する必要があります。
WiX フレームワーク(オープン ソース) と商用ツール( Installshield、Advanced Installer など) は、XML ファイルのアップグレード メカニズムの欠如、共有の作成と管理など、不足している機能に対処するために Windows インストーラーを拡張する機能を実装しています。 、ユーザーとグループの作成、高度な IIS 構成、COM+ インストール、ACL アクセス許可の変更、ファイアウォール規則の設定、インストール プロパティの永続化など...独自のカスタム アクションを実装する必要性はますます少なくなるはずです。可能であれば、他の何千人ものユーザーによって既にテストされている機能を常に使用してください (何百万ものユーザーでさえ - そしてこれらの拡張機能は利用可能な最高の展開専門家によって書かれています - あなたはそれを自分でもっとうまくできると思いますか?)。
Windows インストーラーの企業メリット (非常に重要)
Windows インストーラーにアプローチするには、特定の考え方が必要です。ただし、これまでのインストール テクノロジにはほぼ完全に欠けていた多くの企業にとって重要なメリットがあります。MSI ファイルを使用する企業のメリットについては、一読をお勧めします。特に、Windows インストーラーは価値があるよりも面倒だと考えている人にとっては。
リンクされた記事を簡単に要約すると、以前の展開テクノロジに対する MSI の主な企業の利点は次のとおりです(私の意見では)。
- 信頼できる静かな実行(標準化された、完全に抑制可能な GUI を使用)
- 暗黙的に利用可能なアンインストール(古い展開テクノロジでは悪夢)
- 詳細ログ(実際には非常に詳細ですが、役立つ場合があります)
- 信頼性の高いリモート管理(実際には、全体的な利点 - 列挙された他のすべての利点を組み合わせた効果)
- 昇格されたインストール権限(厄介な一時的な管理者権限はありません)
- 標準化されたコマンド ライン(非常に有益な機能 - 隠されたコマンド ライン オプションを探す必要はもうありません)
- インストーラーの半透過的な性質(オープン フォーマット、ブラック ボックスであるコンパイル済み CA を除く)
- ロールバックのサポート (コンピューターの状態管理、部分的な展開の防止、変更の失敗とロールバック)
- 管理者のインストール(企業の再パッケージ化に不可欠で、すべてのファイルを標準的な方法で抽出します)
- 標準的なパッケージ カスタマイズ アプローチ (トランスフォーム) (基本的に、企業展開用の完全なカスタマイズが可能)
これは、最も重要なものを厳選するためのものです(長年にわたって企業展開を行った後)。正直なところ、これらの機能は世界に大きな違いをもたらし (企業での展開の場合)、MSI はすべての欠陥にもかかわらず本当に使いやすくなっています。
Windowsインストーラーの黄昏
Windows インストーラーが終焉を迎えた今、将来の展開テクノロジがこれらの大きな企業展開の利点を維持し、すべての人、特に開発者に利益をもたらす方法で前述のアンチパターンに対処することを願うばかりです。
展開は開発の重要な部分です。潜在的なエンド ユーザーのために優れたソフトウェアを正常にインストールできないことは、ソフトウェア開発全体で最もコストのかかる間違いである可能性があります。ソフトウェアが完全に機能していることをユーザーが確認できない場合、どうすれば成功できるでしょうか?
Windows インストーラーの複雑さは、より適切に処理 (軽減) する必要があり、その重要な利点は、次のパラダイムがどのようなものであっても適切に維持する必要があります。
かなり良い: Windows Installer の概要。
クラウド プラットフォーム
これはすべて言った。一般的にコンピューティングがクラウド プラットフォームに移行するにつれて、展開の世界は予測不可能な形で大きく変化する可能性があります。しかし、有名なことわざにあるように、物事は変化すればするほど、同じままです。展開では、今後数十年にわたって企業で使用されるすべてのレガシー テクノロジに対処する必要があります。これは、あらゆるマーケティングにもかかわらず、展開がより複雑になるのではなく、より複雑になるように思われる理由に関する記事です。プログラムのインストールの利点と本当の目的は何ですか? .
今後数年間で、展開の未来がどうなるかを見るのは興味深いでしょう。おそらく、家庭用コンピューターの展開は簡素化され、企業への展開はこれまで以上に複雑になるのでしょうか? 将来的には、ほとんどの展開は、おそらくファイルとフォルダーの展開タスクよりもデータベースの展開タスクになるでしょう。現在、サーバーの展開は、データベース スクリプト、ユーザーとグループの作成、共有のセットアップと ACL の許可、パフォーマンス カウンター、ファイアウォール ルールの更新、AD クエリと更新、COM+ とメッセージ キューの構成、サービスのインストールなどで非常に複雑になる可能性があります... - 9ヤード全体。