MSIコンポーネント生成のベストプラクティスとは何ですか？

Question

Visual Studio Installerでは、各ファイルをインストーラコンポーネントとしてインストールすることをお勧めします。 Wixで提供されているヒートユーティリティは、すべてのファイルを独自のコンポーネントに入れるという習慣にも従っているようです。

のInstallShieldのコンポーネントウィザードは、共通の保存先のフォルダで、独自のコンポーネントが、グループ内の他のすべてのファイル（例えば、バージョン管理外のファイルを）ポータブル実行可能ファイルを配置するのInstallShieldのセットアップのベストプラクティスを使用しています。

練習1（独自のコンポーネント内の各ファイル）の利点は、各ファイルは、あなたが修理をトリガするために、これらのファイルをしたい場合に重要であるキーファイルとして設定されていることです。また、ファイルごとにコンポーネントを作成するので、コンポーネントの作成（熱など）の自動化が容易になります。練習1の

欠点は、非常に多くのコンポーネントを管理するためのオーバーヘッドとアプリケーションがインストールされた後に、レジストリの膨満感が含まれます。

練習2の利点は、一つのディレクトリにグラフィックファイルの数百をインストールすることインストールで見ることができました。修復機能を気にしない場合、このインストールに何百ものコンポーネントを作成する理由はありますか？

これらの2つの異なる方法は矛盾しています。私は、人々が実際に使用するものとその理由を知りたいと思います。

Answer 1

私はいつも（InstallShieldは何に似たもの）は、Microsoftのアプローチを使用します。 http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx

を私はので、それが最善だと思う： - 重要なファイル（EXE、DLLなど）は、独自のコンポーネントを持っているので、それら 簡単に修復することができます - リソースファイルが一緒に グループ化されている - それは、最適なコンポーネントが（長いインストールを取得するにはあまりにも多くはないが、簡単な修理を可能にするのに十分に）カウントできます

私はまた、ほとんどの市販のセットアップオーサリングツールということに気づきましたこのアプローチを使用してください。

Answer 2

私は過去にこれについて書いたことがあります。私はそれにリンクを見つけることを試みます。私はあなたがすでに質問を理解していると思います。そして、あなたにとって重要なことを決定する時が来ました。私にとって

、私は15,000ファイルをインストール上で動作し、我々は唯一の主要なアップグレードを持つサービス。 「プログラム実行可能ファイル」については、1：1のプリンシパル（COM、サービス、ショートカットなどの必要条件）に従いますが、コンテンツ/データファイルの場合は、キーファイルアプローチを使用しないで1対多に実行します。コンポーネント。確かに、つまり、ここでは1つまたは2つのコンテンツファイルだけを処理するMSPを作成することはできませんが、私たちには重要ではないビジネスニーズに対しては作成できません。

Resilencyは、私たちはとても少ないキーファイルを持つに4文字の単語のビットは、とにかく私たちに幸せになりました。 :-)ところで、VDPROJはまた、すべてのレジストリキーを自分のコンポーネントのキーファイルにしています。それは、私たちにとって不要な修復を引き起こすのは非常に苦痛でした。

このすべてを除いて、これを完全に理解していない人にとっては、あなたがもう欲しくない状況に遭遇し、その影響を理解するまで1：1のパターンに固執します。その選択をすること。