0

We created a light-weight (VC++, no .Net) Windows Service in VisualStudio 2008, including a Visual Studio Setup Project.
The Setup Project has three custom actions, simple calls of sc.exe (create & start in the "Commit" section, delete in the "Uninstall" section). This works fine on several different Win7 machines, but fails on XP machines (it also fails on the Virtual PC "Windows XP mode") with the msiexec verbose log showing error 1721: "There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor."

When removing the custom actions, the installation finishes without a problem on the WinXP machine. Creating and starting the service by calling sc.exe from the command line after the installation finishes (done by the same user with the same privileges) works too.
Orca shows the type of the custom actions as 3586 for the actions in the "Commit" section and 3074 for the action in the "Uninstall" section.

Research:
Several stack overflow answers and other sites suggest that the cause are missing privileges (also, when installing on Win7, the UAC dialog appears) and propose using "Runas", but the service will be installed on machines where we don't know which users whith which privileges are present and How do you run CMD.exe under the Local System Account? suggests that using the system account might be too much to realize in a simple custom action.
Most of the other questions/answers are regarding WiX, which would add overhead, which we want to prevent at a project as small as this.

The installer and the resulting service shall have as little prerequisites as possible and installing should only require the execution of the .msi file.

Or are we misled and there are better ways to let the installer create and start the service when it is installed?

Community
  • 1
  • 1
MrLogger
  • 1
  • 3
  • With all respect, I'd rather have "overhead" at development time then installation time. Using an install tool that supports the ServiceInstall table such as WiX is a much better idea then reinventing the wheel with fragile custom actions. – Christopher Painter Aug 30 '13 at 15:10
  • As we have no current experience with WiX, we are not sure about the time needed to integrate WiX into the service and produce a working installer. If the general consensus is, that we can generate a working installer with no prior WiX-knowhow in a short timeframe, there is no reason why WiX can't be the solution. – MrLogger Sep 02 '13 at 07:26

0 Answers0