What is the MSI component generation best practice?

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开发者_StackOverflow社区 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.

---

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.

---

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.