Visual Studio Installer声明最佳做法是将每个文件安装为安装程序组件。 Wix提供的热效用似乎也遵循将每个文件放在其自己的组件中的做法。
InstallShield的组件向导使用InstallShield的设置最佳做法，即将可移植可执行文件放在它们自己的组件中，但是将公共目标文件夹中的所有其他文件（例如无版本文件）分组。
练习1（每个文件在其自己的组件中）的优点是每个文件都设置为密钥文件，如果您希望这些文件触发修复，这很重要。它还允许自动创建组件（例如加热），因为您要为每个文件创建组件。
实践1的缺点包括管理这么多组件的开销以及安装应用程序后注册表的膨胀。
在将数百个图形文件安装到一个目录的安装中可以看到练习2的优点。如果您不关心修复功能，是否有任何理由为此安装创建数百个组件？
这两种不同的做法是相互矛盾的，我想知道人们实际使用哪一种以及为什么这样做。
答案 0 :(得分：3)
我过去曾写过这篇文章，我会尝试找到它的链接。我想你已经理解了这个问题，现在是你决定什么对你很重要的时候了。
对我来说，我使用15,000多个文件进行安装，我们只提供主要升级服务。对于“程序可执行文件”，我们遵循1：1主体（COM，服务，快捷方式等等必须）但对于内容/数据文件，我们实际上做了1对多，没有密钥文件方法来减少我们的数量组件。当然，这意味着我们无法在这里和那里创建仅提供一个或两个内容文件的MSP，但是对于我们的业务需求而言，这对我们来说根本不重要。
Resilency对我们来说是一个4字母的字，因此拥有较少的关键文件会让我们更快乐。 :-) BTW，VDPROJ也使每个注册表项成为它自己组件的密钥文件，这对于我们触发不必要的修复非常痛苦。
除此之外，对于那些不完全理解所有这一切的人，我会坚持1：1的模式，直到遇到你不再想要的情况并且你了解其影响做出这个选择。
答案 1 :(得分：3)
我总是使用Microsoft方法（类似于InstallShield所做的）： http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx
我认为这是最好的，因为： - 重要文件（EXE，DLL等）有自己的组件，因此可以轻松修复 - 资源文件组合在一起 - 它允许最佳的组件数量（不是太多而无法长时间安装，但足以容易修复）
我还注意到大多数商业设置创作工具都使用这种方法。