What is the MSI component generation best practice?

Question

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.

Querida

Was about to post this, am very interested in the answer. – Fadeout

For anything small enough: use one file per component. This avoids all kinds of problems. When the number of files to deploy gets to big, you might consider adding a "flag key file" to each folder and use this to trigger the upgrade or reinstall of the whole component. – Many

Answer 1

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.

Illbehaved

Excellent link, this directly contradicts all other documentation that I've seen! :V – Fadeout

Thanks, I was looking for the Microsoft Best Practice. I use InstallShield and was only familiar with practice 2. I have been investigating moving toward Wix and in the book "WiX: A Developer's Guide to Windows Installer XML" it states on page 43 that practice 2 is considered a bad practice and I do not know where the author came up with this statement. I am also looking into automating the generation of my install components which would be alot easier if I followed practice 1. It seems like I cannot use Wix's heat if I want to follow practice 2. – Querida

@Querida There is a tool named ISWix is available for WIX creation. They are following this practice to create Wix files and folder structure – Winner

Answer 2

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.

Driblet

What happens if you want to change one of those components? For example, let's say you have a component with 10 files in it. Can you add or remove one or more files from it without causing problems? – Fadeout

If you do a Major Upgrade you can. Minor Upgrades will be problematic. – Driblet

FYI: I currently use InstallShield and follow practice 2 for non versioned files. These files are servicable through small updates as long as you set one of the updated files in the component you are servicing to be the key file in the small update and set the "Always Overwrite" flag on each of the non versioned files that are being updated. I believe this goes against best practices but I have found this to work without problems. – Querida

What about WebSites and WebServices in asp.net? would you create each cs file/ aspsx file in a diffrenet component? or should each folder or website be a component of its own? i managed somehow (i have no idea how!) to create a scenario where the all website is a comoponent and each subfolder is looked like a virtual component it doesnt exists in the components tree in installshield 2011 and it is looking like this in the files and folders view : under the component column it sais RootComponent(Subdirectory name) – Vintner