インストーラー：WIXまたはInno Setup？
これら2つのツールを比較しています。私の印象は次のとおりです。
- Inno SetupはMSIを生成しませんが、WIXが実行できるすべてのことを実行できます
- WIXはMSIを生成しますが、学習曲線が急です
この特徴付けに同意しますか？他にどんな違いがありますか？ WIX＃ このストーリーをどのように振り返るのですか？ Inno SetupはWindowsインストーラーを使用しないため、アンインストールに問題がありますか？ Inno Setupは、コマンドにより、インストールを以前のバージョンにダウングレードできますか、それともアプリケーションのインストール/アップグレードのみですか？
MSIを使用して久しぶりにInnoSetupに切り替えたとき、振り返ることはありませんでした。
私のインストールが頭痛になることを望んでいませんでした。 「設定して忘れる」ことができるものが必要でした
デフォルトでは、InnoSetupはアンインストールを生成します。単純または複雑なインストールおよびアンインストールのニーズを処理できます。
InnoSetupを使用するアプリケーションをアップグレードする方法はいくつかあります。
- 最初は、既存のインストールを上書きする上書きメソッドを使用しました。
- 最近、新しいバージョンがインストールされたときに、以前のバージョンの自動アンインストールを切り替えました。
InnoSetupでは、ダウングレードは通常、古いバージョンをアンインストールして再インストールします。
あなたはMSIの部分ではなくMSIについて正しく、MSIの学習曲線が急勾配であることは正しいです。ただし、どちらにも他の機能にはない機能があります。 MSIの利点について Glytzhkof を引用させてください。
グリツコフはこんにちはと言います;-）。 serverfault.com で私の最初の回答を両方読んで、MSIの急な学習曲線に起因する一般的な問題の概要を確認してください。ここでのこの回答は理論上の利点に焦点を当てており、 other answer （同じスレッドで）は一般的なMSIの問題を頭上で要約しています。追加は大歓迎です-私はちょうど最も一般的な問題を追加しました。
- Transparency（オープンインストーラー形式）-MSIを確認および検査できます。これは大企業にとって大きな問題です。コンパイルされたカスタムアクションを除いて、MSIファイルは「ホワイトボックス」です。設定によってシステム全体のネットワーク設定などの変更が発生した場合は、実際に確認できます。
- カスタマイズ可能性-ベンダーのインストーラー更新との相互運用性を維持しながら、組織のニーズと標準に適合するようにMSIをトランスフォームを介してカスタマイズできます。インストーラー自体を変更するのではなく、トランスフォームと呼ばれる別の組織固有のファイルにカスタマイズを作成します。カスタムアクションおよび一般的にインストーラーの何でも無効にすることができます。「ブラックボックス」カスタムアクションは、ベンダーに連絡して説明することで承認できます。これらの変換ファイルは、MSIファイルを別の言語にローカライズするために使用されることもあります。複数の変換を1つのMSIに適用できます。
- 標準化-MSIは「何でも許可」することはできません。インストーラーの包括的なフレームワークを提供します。これには、すべて標準形式のアンインストールも含まれます。インストーラーGUIは、リモートでトリガーできるサイレントインストールとアンインストールをサポートする組み込み機能で標準化されています。
- 管理とレポート-Windowsインストーラーは、製品がインストールしたすべてのアイテムの包括的なデータベースを維持します。製品がインストールされているかどうか、インストールされている機能、およびインストールされているファイルのバージョンを確実に判別できます。さらに、ベース製品に適用されているパッチがあれば、そのリストを取得できます。
- セキュリティ-包括的なインストールデータベースから、インストールされた製品のセキュリティの脆弱性を検出することが可能です。 MSIには、「昇格された権利」の原則も含まれているため、制限されたユーザーは、インストールに管理者権限が必要な製品のインストールをトリガーできます。これは「アドバタイズメント機能」の一部であり、管理者はすべてのワークステーションに実際にインストールすることなく、ユーザーがインストーラーを使用できるようにすることができます。物事を機能させるために一時的な権利を台無しにする必要はありません。
- 検証-MSIファイルを検証ルールでチェックして、多くの内部整合性ルール（ICEと呼ばれる）に準拠していることを確認できます。企業は独自のICEチェックを作成して、特別な企業ルールと要件を適用できます。これはQAに大いに役立ちます。
- Resiliency-WindowsインストーラーのAdmin install機能は、MSIからソースファイルを抽出する標準的な方法を提供します。その後、これらのソースファイルを共有に配置して、すべてのワークステーションでインストールできるようにします。これにより、CDなどのインストールメディアを要求せずに、修復、アンインストール、および変更の操作を完了できます。これは、特別な状況で古いバージョンのソースファイルへのアクセスを必要とする可能性があるパッチ適用および更新操作にとって特に重要です。
- ロールバック-MSIファイルのインストールは通常、復元ポイントの作成をトリガーします。さらに、インストール中に置換または上書きされたすべてのファイルとレジストリ項目は、インストールが完了しなかった場合に保存および復元されます。これにより、インストールが失敗した場合でも、ワークステーションが安定した状態に保たれます。不十分に設計されたMSIファイルがWindowsの組み込み機能に違反する可能性があると思われるかもしれませんが、詳細については、このスレッドの他の投稿を参照してください。
- Patching＆Updates-Windowsインストーラーの非常に複雑なパッチはシステムで完全に管理および登録されているため、インストールされているものをチェックすることでシステムのセキュリティ状態を確認できます。更新はいくつかの基本的なバリアントに標準化されており、これにより、更新をより確実に実行できます。展開システムは、失敗した更新とその理由を報告できます。
- Logging-Windowsインストーラは標準化されたログ機能を提供します。これは以前のバージョンよりもはるかに優れていますが、ほとんど冗長です。ログアナライザーを使用してログファイルを解読でき、カスタムログレベルを使用して、不要な情報を含む非常に大きなログファイルを生成しないようにすることができます。デバッグの目的では、詳細なログが非常に役立ちます。 MSIログファイルを手動で読み取る適切な方法については、 Rob Menschingのブログ を参照してください。
このスレッドに返信するのが遅い。私の会社の製品には何年もInno Setupを使用しています。それはほとんどのことを非常にうまく行いますが、私にとって最大のハードルはカスタムアクションです。 Inno Setupでは、Pascal言語のバリアントを使用する必要があります。 WiXツールセットを使用すると、自分のカスタムアクションにC＃を使用できます。確かに、これは個人的な好みですが、それが、他の点では優れたInno Setupプラットフォームから優れたWiXプラットフォームに切り替えた主な理由です。それと、別の応答ですでに言及されているMSIを使用することには非常に多くの利点があったという事実。
率直に言って、私にとって、Pascalの学習曲線は、本WiX 3.6：A Developer's Guide to Windows Installer XMLを使用したWiXの学習曲線よりも優れていました。
両方をビルドシステムに統合しました。
しかし、私たちは、1つの単純な理由で、非ビジネス顧客向けのinnosetup exeファイルとオンデマンドのmsiのみを宣伝することにしました。
マルチローカライズ版のセットアッププログラムをMSIとともに出荷することはできません。言語ごとに1つのインストーラーが必要で、これは非常に面倒です。 GUI全体を書き換えることを可能にするハッキングが行われる可能性がありますが、これは十分に文書化されておらず、盗むオープンソースや多くの作業はありません。
GUIは、WiXの最悪の部分であり、技術的にはInnosetupより優れています。
Innosetupを使用すると、1つのexeファイルを5つの言語で簡単に出荷できます。私たちはすでに6つのバイナリ[Free、Home、Pro-それぞれ32/64ビット]を持っているので、亜種の爆発は巨大であり、日本語のWebページで日本語バージョンを販売し、最初に現れるのは英語のみのインストールです。悪い印象。
グループポリシーなどが必要なビジネスユーザー向けのMSIは英語のみで、ビジネスユーザーには問題ありません。
この答えは非常に遅くなります。しかし、私はこの投稿に出くわし、質問に対する1つの答えが単に「両方を持たないのはなぜですか？」 （ケーキを食べて、それも食べてください）そして、「1つだけの労力を費やして2番目のものを実質的に無料で入手できるのに、なぜ両方を実装する労力を費やすのですか？」
そのために、MSIサポート付きのInno Setupスクリプトを紹介します。
https://github.com/cubiclesoft/php-app-server/blob/master/installers/win-innosetup/yourapp.iss
コマンドラインで/MSI={GUID}が渡されると起動するカスタムPascal関数がいくつか使用されています（スクリプトの便利な変更をトリガーします（たとえば、[スタート]または[プログラムの追加と削除]に[アンインストール]アイコンがない））。
そして、上記のInno SetupスクリプトをサポートするWiXスクリプトを提示します。
https://github.com/cubiclesoft/php-app-server/blob/master/installers/win-wix/yourapp.wxs
WiXスクリプトは、Inno SetupベースのインストーラーEXE（唯一のペイロード）をラップして、Inno Setupスクリプトをトリガーし、MSI互換の方法で処理を実行し、MSIをクランクアウトします。それは完璧ではありませんが、Inno Setupの方法を実行して、髪を引っ張ることなくMSI（GPO/SCCM/DSCサイレントデプロイメントなど）のほとんどの利点を得ることができるため、時間を大幅に節約できます。これは、ほとんどの場合、ファイルをシステムと少数のレジストリエントリ（つまり、基本的なアプリ）に展開するだけの場合に最適です。このアプローチは、コンポーネントがたくさんある大規模なアプリケーションにはお勧めしませんが、試してみて機能する場合は、お知らせください。 Inno Setup EXEを起動するMSIバージョンがあると、少なくともシステム管理者は導入を行うのに妥当なものになります。
WiXスクリプトはInno Setup側のカスタムPascal関数に依存することに注意してください。旧式のInno Setupインストーラーを取り、それをWiXスクリプトでラップして、機能することを期待することはできません（おそらく機能しません）。しかし、おそらくInno Setupの将来のバージョンでは、同様のものがネイティブでサポートされる予定です。