MSI 组件生成最佳实践是什么？
Visual Studio 安装程序指出，最佳实践是将每个文件安装为安装程序组件。 Wix 提供的 heat 实用程序似乎也遵循将每个文件放入其自己的组件中的做法。
InstallShield 的组件向导使用InstallShield 的安装最佳实践，将可移植可执行文件放置在其自己的组件中，但按公共目标文件夹对所有其他文件（例如未版本控制的文件）进行分组。
实践一（每个文件在其自己的组件中）的优点是每个文件都设置为密钥文件，如果您希望这些文件触发修复，这一点很重要。它还允许更轻松地自动创建组件（例如热量），因为您正在为每个文件创建一个组件。
实践一的缺点包括管理如此多组件的开销以及安装应用程序后注册表的膨胀。
在将数百个图形文件安装到一个目录的安装中可以看出实践 2 的优点。如果您不关心修复功能，是否有理由为此安装创建数百个组件？
这两种不同的做法是相互冲突的，我想知道人们实际上使用哪一种以及为什么。
Visual Studio Installer states that it is a best practice to install each file as an installer component. The heat utility provided with Wix also seems to follow the practice of putting every file in its own component.
InstallShield's component wizard uses InstallShield's setup best practice of placing portable executable files in their own component but groups all other files (e.g. unversioned files) by the common destination folder.
The advantage of practice one (each file in its own component) is that each file is set up as a key file which is important if you want these files to trigger repairs. It also allows automation of creating the components (e.g. heat) easier since you are creating a component for each file.
The disadvantages of practice one include the overhead of managing so many components and the bloating of the registry after the application is installed.
An advantage of practice 2 could be seen in an install that installs hundreds of graphics files to one directory. If you do not care about repair functionality, is there any reason to create hundreds of components for this install?
These 2 different practices are conflicting and I want to know which one that people actually use and why.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我总是使用 Microsoft 方法（类似于 InstallShield 的方法）：
http://msdn.microsoft.com/en-us/ Library/aa368269(VS.85).aspx
我认为这是最好的，因为：
- 重要文件（EXE、DLL等）有自己的组件，因此可以轻松修复
- 资源文件分组在一起
- 它允许最佳的组件数量（不会太多以进行长时间安装，但足以允许轻松修复）
我还注意到大多数商业设置创作工具都使用这种方法。
I always use the Microsoft approach (something similar to what InstallShield does):
http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx
I think it's the best because:
- important files (EXE, DLL etc.) have their own component, so they can be repaired easily
- resource files are grouped together
- it allows an optimum components count (not too many to get a long install, but enough to allow an easy repair)
I also noticed that most commercial setup authoring tools use this approach.
我过去写过有关此内容的文章，我会尝试找到它的链接。我认为您已经理解了这个问题，现在是您决定什么对您来说重要的时候了。
对我来说，我负责安装超过 15,000 个文件，并且我们只提供重大升级服务。对于“程序可执行文件”，我们遵循 1:1 原则（无论如何，COM、服务、快捷方式等都是必须的），但对于内容/数据文件，我们实际上采用一对多、无密钥文件的方法来减少我们的数量。成分。当然，这意味着我们无法创建一个只为一两个内容文件提供服务的 MSP，但对于我们的业务需求来说，这对我们来说并不重要。
弹性对我们来说有点像一个 4 个字母的词，所以拥有更少的关键文件会让我们更快乐。 :-) 顺便说一句，VDPROJ 还使每个注册表项成为其自己组件的密钥文件，这对于我们触发不必要的修复来说非常痛苦。
除此之外，对于任何不完全理解所有这些的人，我会坚持 1:1 模式，直到您遇到您不再想要的情况并且您了解做出该选择的影响。
I've written about this in the past and I'll try to find a link to it. I think you already understand the question and it's just time for you to decide what is important to you.
For me, I work on installs with 15,000+ files and we only service with major upgrades. For "Program Executables" we follow 1:1 principals ( a must for COM, Services, ShortCuts and so on anyways ) but for content/data files we actually do a 1 to many with no key file approach to cut down on our number of components. Sure, that means we won't be able to create an MSP that services just one or two content files here and there but for our business needs that's simply not important to us.
Resilency was a bit of a 4 letter word to us so having less key files makes us happier anyways. :-) BTW, VDPROJ also makes every registry key a keyfile of it's own component and that was quite painful for us triggering unneeded repairs.
All of this aside, for anyone who doesn't fully understand all of this, I'd stick to the 1:1 pattern until you come across a situation where you don't want to anymore and you understand the impact of making that choice.