views:

56

answers:

2

When I create a Windows Installer package (say using WiX) and I install the application App.exe as well as the App.exe.config should the config file have its own component or should it be a companion file to the application executable?

<Component Id="C.App.exe">
  <File Source="App.exe"/>
</Component>
<Component Id="C.App.exe.config">
  <File Source="App.exe.config"/>
</Component>

versus

<Component Id="C.App.exe" Guid="86623B7A-8A87-11DF-AE7B-FE1AE0D72085">
  <File Id="F.App.exe" Source="App.exe"/>
  <File Source="App.exe.config" CompanionFile="F.App.exe"/>
</Component>

If I install different App.exe.config files depending on some external property (say run-time environment like test or release) does that affect what choice I should make?

A: 

It is recommended to put a single resource (file, registry key, etc.) into a single component. In this case this resource is a KeyPath of the component. Windows Installer watches the key path of each component to decide if it worth installing, repairing, upgrading, etc.

This article of Rob Mensching explains the things in detail.

Yan Sklyarenko
There is no such universal reccomendation. It's more important to understand the implications of picking keyfiles for components in terms of costing and servicability.
Christopher Painter
I agree. Though I consider "one component - one resource" a good approach for small number of files in case one resource is really a single unit of installation, "it depends" is more correct in general. +1 to your answer :)
Yan Sklyarenko
I agree that 1 per is a good starting point also. Problem is App.Config files are very interesting in that they mix application resources and configuration data in a single atomic file. Windows Installer wasn't really designed for that so you have to be very cafeful when servicing them. Overwriting or not overwriting can often lead to problems.
Christopher Painter
I usually suggest having 2 config files. One that has the defaults installed by setup and will always be overwritten during upgrades and another that has override values provided by the user and will never be overwritten during an upgrade. I just with the .NET Base Class Libraries supported something like this out of the box.
Christopher Painter
+2  A: 

The answer is it depends. Rob's article mentioned by Yan is a good read, here is another:

Defining Installer Components http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx

The trick is to understand how costing and repairs are based on keyfiles, how the default versioning rules work, how you plan on servicing your application in the future and making your decision based on that.

Christopher Painter
Even though your link doesn't answer my particular question it is probably the most concise description on how to create components.
Martin Liversage
Be sure to read http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx, http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx and http://msdn.microsoft.com/en-us/library/aa368267(VS.85).aspxSorry, the answer really is 'it depends'. Also read http://blogs.msdn.com/b/windows_installer_team/archive/tags/best+practice+guidelines/ Tao 1-6.
Christopher Painter

related questions