MSIファイルを使用する企業の利点
通常のsetup.exeファイルよりも.msiファイルを使用する利点は何ですか？
ユーザーがほとんど権限を持っていないが、詳細についてはわからないマシンでは、展開が容易であるという印象があります。
Msiexec.exeには、setup.exeシナリオを使用するよりも簡単に展開できる機能がありますか？
.msiアプリケーションを展開する際のヒントやコツはありますか？
ほんのいくつかの利点：
- 宣伝することができます（オンデマンドインストールが行われるように）。
- 広告と同様に、ユーザーが機能を使用しようとするとすぐに機能をインストールできます。
- 状態管理は維持されるため、Windowsインストーラーは、管理者がアプリケーションがマシンにインストールされているかどうかを確認する方法を提供します。
- インストールが失敗した場合にロールバックする機能。
エンタープライズ環境でソフトウェアを展開するときまで思います。MSIを介したソフトウェアの展開はほとんど楽しいものです。対照的に、私はほとんどの場合、別のコンテナーにあるソフトウェアを展開することを恐れています。
MSIインストールの操作に関する追加情報については、「実行」ダイアログにmsiexecと入力してください。
この答えは非常に進行中の作業であり、大まかな概要です。追加、質問、更新を歓迎します。このリストは完全なものではありません。問題のあるパッケージに関する情報をコメントに追加します。
MSIパッケージに見られる典型的な問題と設計上の欠陥
また、多くのMSIファイルにはエラーが含まれていること、時には重大なエラーが含まれていることにも注意する必要がありますが、訓練を受けたアプリケーションパッケージャーはこれを検出でき、ほとんどの場合、問題を解決できます。これは本質的に別の質問に答えるため、これを別の答えとして追加しますが、同じスレッドに関連していると感じています。
MSIに関連する技術的な詳細は非常に複雑です。基本的なレベルでは、ファイルとレジストリ設定をコンポーネント（アトミックインストール）と機能（ディクショナリ機能など、インストールするユーザーが選択できるアプリケーションパーツ）に分解します。コンポーネントを分割するためのいくつかのベストプラクティスルールがあり、MSIファイルのエラーはここにたくさんあります。これらのエラーは通常、「メジャーアップグレード」の使用を標準化することによって処理されます。
実際のインストールは、いくつかのインストールシーケンスで実行されます。一部は昇格された権限で実行されます。これらすべてはデータベーステーブルで定義されており、MSIを理解して処理するのは非常に複雑です。インストールシーケンス全体に広がるのは、標準アクションとカスタムアクションです。標準アクションはMicrosoftが設計したものであり、実行する必要があります（シーケンスは変更される場合があります）。ベンダーは、MSI自体ではカバーされないカスタムロジックを実行するためのカスタムアクションを利用できます。これらは、スクリプトまたはコンパイルされた形式にすることができます。カスタムアクションは、即時（一度に実行、システムを変更する必要はないが変更することが多い）または据え置き（実行スクリプトに書き込まれ、トランザクションとして実行されるため、ロールバックをサポートする）にすることができます。
MSIの一般的なエラーは（順不同-実際の混乱として表示されます）：
- コンポーネント作成エラー（ベストプラクティスに従っていない）。これは、ファイルや設定の欠落や無意味なエラーで爆破するパッチなど、不可解な症状を伴うパッチの適用やアップグレードの問題を引き起こす可能性があります。単純化しすぎるには、ファイルの数が膨大でない限り、コンポーネントごとに1つのファイルを使用する必要があります。
- アップグレードの問題上書きまたはリセットされるユーザーデータに関連します。詳細は以下をご覧ください。
- カスタムアクションの不適切なスケジュールインストールシーケンスの「トランザクションセクション」の外、または間違ったタイプのカスタムアクションが誤って配置されています。これにより、デプロイメントシステムを介してリモートで実行するとアクションが失敗し（昇格された権限がない）、トランザクションのアクションのみがロールバックされるため、ロールバックが実質的に機能しなくなります。 Windowsインストーラートランザクション（データベーストランザクションのコミットを考える）は、標準のアクションの間で実行されますInstallInitializeとInstallFinalizeメインインストールシーケンスでruns高い権限で。システムへのすべての変更は、このトランザクションで行われます-それ以外はすべてエラーです（ただし、残念ながらかなり一般的です）。
- トランザクションインストールシーケンスの外部でシステムに変更を加えるための即時モードのカスタムアクションの使用。即時モードのカスタムアクションは、インストールシーケンスのどこに配置されても、昇格されたユーザー権限で実行されないため、これによりロールバックサポートが無効になり、一般にセキュリティエラーがトリガーされます。
- 自己修復の反復サイクルを引き起こす誤った設計は、明確な理由なしに発生します。 これはinstallsite.orgからのこの主題に関する別の記事です
- カスタムアクション無人インストールモードでGUIの抑制に従わないと、モーダルダイアログが表示され、サイレントモードで実行するとデプロイメントが完全に失敗する場合があります。この問題と、サイレントモードとインタラクティブモードの全体的な違いについては、ここで詳しく説明します（やや冗長で長め）： コントロールパネルからのアンインストールは、.msiからの削除とは異なります
- 誤って作成されたパッケージの一部カスタムアクションはユーザーインターフェイスシーケンスにのみ挿入されますです。これにより、サイレントインストールモードで実行されなくなります。ここでは、サイレントインストールがほぼ排他的に使用されているため、これは企業展開にとって深刻です。この問題はアンインストールにも影響を与える可能性があります。つまり、すべてのクリーンアップカスタムアクションを確実に実行するために、アンインストールのためにインタラクティブにアンインストールを実行する必要がある場合があります。ここでも、ユーザーインターフェイスレベルの詳細については、前の箇条書きのリンクを参照してください。
- セットアップには、インストール先の場所への展開を目的としていないファイルが含まれています。通常、winsxsアセンブリフォルダーに並べてインストールする必要があるシステムファイル。
- インストール速度が遅いは、多くのMSIで報告されるもう1つの「問題」です。 この件に関するいくつかのヒント 。全体として、Windowsインストーラーは、インストールする対象のレジストリーでの登録要件が重いため、かなりのオーバーヘッドを備えています。
- 上書きカスタマイズされた情報または共有データファイル。これは、INIファイルが、たとえばIniFileテーブルではなくFileテーブルを介してインストールされている場合に発生する可能性があります。後者の場合、前者の場合は「変更トランザクション」のように扱われます。 INIファイルに、ファイルとともに展開する非標準のフォーマットまたは大きなコメントセクションが含まれている場合を除いて、これは一般的に間違っています（特定の開発者ツールに共通）。
- ファイルの上書きに関する複雑なルールを指定すると、ファイルが意図せずに上書きされたり、まったく更新されなかったりする可能性があります。これは古典的なMSIの問題です。 アップグレードできないファイルを強制的に上書きする方法については、この記事を確認してください 。ルールは、msiexec.exeコマンドラインレベルで設定された REINSTALLMODEプロパティ のカスタム設定によって少し微調整できます（古いバージョンを上書き、同じバージョンを上書き、すべてのバージョンを上書きなど）。 。）そして、それらはデータファイルとバージョン管理されたファイルでは異なる働きをします。 SDKの詳細 。これを理解することは非常に重要であり、理解されたとしてもよく見当たらないデザインです。
- COMファイルの自己登録インストール中にセキュリティ警告をトリガーしたり、さまざまな方法で問題を引き起こしたりする可能性があります。この記事を確認してください： 有害と見なされる自己登録 。
- メジャーアップグレード（製品をアンインストールして再インストールする）が変更されたファイルをアンインストールし、デフォルトバージョンを再インストールする場合は、ファイル置換の問題のバリエーションがあります。これらの場合コンテンツは元に戻されたか、上書きされたように見えます実際に最初にアンインストールしてから再インストールした場合。
- カスタムユーザー認証情報で実行中のサービスメジャーアップグレードシナリオ中に認証情報を失うだけでなく、設定ファイル（表示）をデフォルトに戻す（実際にはアンインストールおよび再インストールされた）可能性があります。記録のためだけに：私の意見では、ユーザーの資格情報でサービスを実行することは、そもそも設計上の欠陥です。
- パブリックプロパティクライアントプロセスからサーバープロセスに正しく渡されず、カスタムアクションが期待どおりに完了しません。これには、SecureCustomActionPropertiesプロパティの更新が含まれます。
- 一部のアプリケーションは、最初にセットアップをインストールしたユーザー以外のユーザーに対して適切に実行できません。これは重大な設計エラーですが、通常、経験豊富なアプリケーションパッケージャーが self-healingまたはActiveSetup を使用してHKCUレジストリキーおよびserprofileファイルを追加することで修正できます。 =。これは非常に複雑なテーマであり、機能するためには少し黒人の芸術が必要になる場合があります。記録のために：私の意見では、実際の解決策は、アプリケーション自体を変更して、マシンごとの場所からコピーされたデフォルト設定とテンプレートに基づいて、またはアプリケーションの内部デフォルト（ソースコード）。
- 一部のMSIファイルは、管理者以外のすべてのユーザーに完全な読み取り/書き込み権限を設定することによって、インストールされたファイルのセキュリティを台無しにしています。また、権限がないために、アプリケーションが新しいバージョンのWindowsで動作しなくなることもあります。アプリケーションパッケージャは、アプリケーションのカスタムアクセス許可の分析に頻繁に直面します。通常、HKLMまたは％ProgramFiles％のどこかに、追加の権限が必要です。
- 一部のInstallshieldその日のセットアップは、インストール中にインターネットへの接続を試みます。これは、展開が厳しく制御されている企業の展開シナリオではひどいものであり、インストーラーがインターネットから新しいコンテンツを直接ダウンロードすることはできません。
- もう1つのネットワークの問題は、インストール時にインターネットを介して検証されるデータを入力するGUIを表示しようとしたり、Webサイトのライブコンテンツを表示したりする場合です。これは通常、電子メールアドレス、連絡先情報、ライセンスキーなどです。企業環境ではプロキシ構成がないが原因であることが多いため、接続は完全に失敗する可能性があります（インターネットへの直接接続はなく、すべてのインターネットトラフィックは特定のキャッシュサーバーを経由してルーティングされ、各プロセスが提供する必要があります）ファイアウォールを通過するための資格情報）。 セットアップによるライセンス検証の危険に関する記事です 。
- InstallshieldInstallscript言語のランタイムをインストールするために使用されます。この前提条件のセットアップは一般にsetup.exeに含まれており、-問題の伝説的なソースでした。多くのバージョンがあり、いくつかの非互換性があり、多くの実行時エラーが発生していました。バージョン12（またはその近辺）以降、このランタイムは確実にインストールされ、ネイティブにコンパイルされるか、サンドボックス化されて実行されます（どちらか一方、おそらくサンドボックス化されているかは不明）。古いInstallshieldセットアップでは、この展開の問題が表示される場合があります。次のような問題に対するInstallshieldのレガシーサポートサイトがあります。http://consumer.installshield.com/common.asp
- 英語以外の言語でセットアップされたマシンで実行した場合、または英語のマシンでローカライズされた（翻訳された）バージョンのセットアップを実行した場合でも、いくつかのセットアップでインストール動作が不安定になったり、断続的なバグが表示されることがあります。これは、純粋にランタイムエラー、またはローカライズされたダイアログボックスの機能がテキストの切り捨て、誤ったフォーマット、誤った翻訳、または language localization に関連するその他の多くのタイプのエラーである場合があります。専門分野全体（画像内のテキストの翻訳、ソフトウェア自体の翻訳、マーケティング資料の翻訳、国際的なサポート要求への対応、OSの言語設定への適応など）一部の言語では、言語の特殊性に対応するためにアプリケーション全体を変更する必要があります。一般的な問題は文字列マクロとコードページ設定であり、後者はUnicodeの導入による問題ではありません。 翻訳ツールのサンプルスクリーンショットを参照 。
- ほとんどすべてのセットアップは、MSIパッケージの品質をテストするために利用できるいくつかの組み込み検証テストに失敗します。検証の実際的な例については この記事 を参照してください。
- メジャーアップグレードスキャン中に MSIのバージョン番号の3桁のみが実際にチェックされる であるため、MSIのアップグレードが失敗することがあります。
- INIファイルのインストールは、Windowsインストーラの組み込み機能です。エントリは、必要に応じて追加、削除、マージ、または処理できます。ただし、INIファイルはセグメント化された値としてではなく、ファイルとしてインストールされます。これにより、INIファイルが更新されるのではなく、再インストール中に上書きされます。非常に一般的なMSI問題。
- 上記の問題は、.NETアプリケーションとそのConfig.xmlファイルにも当てはまります。この場合、MSIにはコンテンツを詳細に更新する組み込みの方法がなく、カスタムアクションを介して更新をコーディングするか、インストール時にファイル全体を置き換える必要があります。 Wixにはこのための新機能がありますが、Windowsインストーラエンジンにはこの機能が組み込まれていません。
さらに微妙なエラーがいくつかあり、私が忘れていたいくつかのより大きな典型的な問題があります。
[〜＃〜] msdn [〜＃〜]の Windows Installer Best Practice の記事を確認してください。
MSIを使用すると、パッチ（MSPファイル）とアップグレードも簡単になります。 MSIは、プロセス全体を容易にする独自の製品およびアップグレードコードの概念を使用しています。
一部の展開システム（CA Unicenter Software Deliveryは1つの例です）は、特別な方法でMSIを理解することもできます。これにより、展開システムに非常によく統合できます。たとえば、MSIを展開システムのソフトウェアライブラリにフィードすると、製品内のさまざまな機能が自動的に検出され、さらに詳細なカスタムアクション（ローカルインストール、検証、修復など）とロギングが自動的に許可されます。
自己修復/修復もMSIの大きな利点です。
また、オープンソースも確認してください Windows Installer XML 、 "XMLソースコードからWindowsインストールパッケージをビルドするツールセット。ツールセットは、開発者がMSIおよびMSMをビルドするためにビルドプロセスに統合できるコマンドライン環境をサポートしています。セットアップパッケージ。」これは、MSが主要なソフトウェアパッケージのいくつかを準備するために使用します。
変換を行うことができます-理論的には多くのカスタマイズが可能です。プログラムがベンダーによって適切にパッケージ化されている場合は、エンドユーザーとの対話なしに完全に自動化された展開を行うことができます-これは、Windows環境を標準化し、さらに多くのことを行う場合に非常に役立ちます。コンピュータの。
msis [または無人デプロイメント]で人々が何をしているのかを確認するには、たとえば this サイトにアクセスして、フォーラムにアクセスしてください。