[wix-users] set the Start option for a service to switch from 'auto' to 'manual' based on an install-time Property value

[John Zajac]

I have a WiX project where I wish to set the Start option for a service to
switch from 'auto' to 'manual' based on an install-time Property value.
>From this
<http://t.sidekickopen04.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs8r4Px6W3LyXBW4WrMg4N3J2C4j166gNf7lS-kF03?t=http%3A%2F%2Fwww.mail-archive.com%2Fwix-users%40lists.sourceforge.net%2Fmsg33422.html&si=5758464741081088&pi=866ea751-5338-4566-f2c4-f2883fe2d128>
thread and also this SO post
<http://t.sidekickopen04.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs8r4Px6W3LyXBW4WrMg4N3J2C4j166gNf7lS-kF03?t=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F2500242%2Fparameterise-service-start-option-in-wix-installer&si=5758464741081088&pi=866ea751-5338-4566-f2c4-f2883fe2d128>,
I
see my options are:

- Install time
  - Use conditions on Components with one component for each
combination of Start attribute's value.
  - Use custom action to update StartType column of ServiceInstall table
(http://msdn.microsoft.com/en-us/library/aa371637(VS.85).aspx).  Schedule this
action somewhere before InstallServices action.
  - Use transforms to do the same.



I use Heat to generate my components, and some XSLTs to modify a bit of
them, so it will make the conditional components strategy somewhat
challenging for me unless I hardcode this specific Service related
component. I'm going to start with this approach anyway since it as a
general guideline I try to keep custom CA script code out of my installs as
much as possible (even though sometimes they seem to be the least resistant
path, Windows Installer best practices aside..).

However, my question here is about the other two alternatives:

1) Use custom action to update StartType column of ServiceInstall
table (http://msdn.microsoft.com/en-us/library/aa371637(VS.85).aspx).
Schedule this action somewhere before InstallServices action.

2) Use transforms to do the same.


For #1 - is this suggesting accessing the MSI database at run time and
changing it, in a (probably Deferred) Custom Action ? And if so, since this
change does NOT impact the actual cached MSI database (correct me if I'm
wrong), does that negatively impact any Modify/Change, Repair, and Upgrade
(MSP minor or small updates, or MSI major upgrades) scenarios?

For #2 - is this basically the same as #1 however instead of code to open,
read, and write the running MSI database, it would be code to apply an MST
file having those table differences, at run time? And if so, can this MST
be embedded in an MSI using WiX (sort of like MSI chaining which I recall
disliking) or does it have to be in an exe bootstrapper now?

Feedback, advice from anyone who has been in a similar situation is much
appreciated.