1

I have a installation package made using the Wix toolset, that includes a service created with Embarcadero's C++ Builder. ECB has a different syntax to register/unregister services under Windows if compared to Visual Studio C++/C#, I was not able to register the service through the regular Wix element <ServiceInstall>, the installer freezes during the service registration/unregistration. I found a solution through the Wix Custom Actions. I created the following actions:

    <CustomAction
        Id="LaunchApp_SrvInstall"
        Directory="INSTALLDIR"
        Impersonate="no"
        Execute="deferred"
        ExeCommand="&quot;[INSTALLDIR]ACService.exe&quot; /install /silent">
    </CustomAction>
    <CustomAction
        Id="LaunchApp_SrvUninstall"
        Directory="INSTALLDIR"
        Impersonate="no"
        Execute="deferred"
        ExeCommand="&quot;[INSTALLDIR]ACService.exe&quot; /uninstall /silent">
    </CustomAction>

    <InstallExecuteSequence>
        <Custom Action="LaunchApp_SrvInstall"   After="InstallFiles">NOT REMOVE</Custom>
        <Custom Action="LaunchApp_SrvUninstall" Before="RemoveFiles">REMOVE ~= "ALL"</Custom>
    </InstallExecuteSequence>

With the syntax above, during the package install, after the files are copied to the installation directory I have the service registered, and if I'm uninstalling the package the service is unregistered before the installed files are removed. In both cases it works perfectly. The problem I'm facing happens when I try to update the software to a newer version, I have the scenario where the software and the service are running and the user tries to install the new MSI package to update the entire solution. In that case, I have the following popup:

enter image description here

It seems that during the update process, the installer is trying to register the service twice, but I can't figure why. Does anyone here already faced such situation? Is there a way to configure the Custom Actions to work also during the package update?

André Murta
  • 141
  • 2
  • 9
  • Please test on a clean virtual - you could have "dirty state errors". I am not sure that binary needs anything special, you should try this sample project and inject your own binaries to see if that works: https://github.com/Robs79/How-to-create-a-Windows-Service-MSI-Installer-Using-WiX - the service start calls and [SCM code](https://en.wikipedia.org/wiki/Service_Control_Manager) must comply to some standards? – Stein Åsmul Jul 31 '20 at 11:47
  • [Another WiX service sample here](https://github.com/rstropek/Samples/tree/master/WiXSamples/WindowsService). – Stein Åsmul Jul 31 '20 at 11:52
  • Thank you guys. But all the given examples are in C#. I think WiX is the default install tool in Visual Studio; in that case there is no need to use Custom Actions to handle the service installation, because a service created with C# could use the element directly. The problem I'm facing is due to the fact the service was created using C++ Builder, and it seems the element does not have support for a C++ builder created service. – André Murta Jul 31 '20 at 18:11
  • Not sure that is true with the C++ builder. Service binaries should comply with SCM commands? (start, stop, pause, etc...). I am not sure. You should try to inject your C++ builder binaries in the samples above to verify. Did you try this? Using custom actions to install services is not a good approach, but possible. [I have this old answer on various service installation approaches](https://stackoverflow.com/a/61903256/129130). – Stein Åsmul Jul 31 '20 at 18:50
  • It's puzzling, I adapted the sources at https://github.com/rstropek/Samples/tree/master/WiXSamples/WindowsService using a simple example service made with C++ Builder. I have the same behavior as before, the install freezes when trying to register the service. I can see the install folder created, the MSI contents are in there; using Task Manager I confirm the service executable is running, but is not yet registered as a service in Windows. At this point the installation freezes, I think I'll have to use a different MSI package generator. – André Murta Aug 01 '20 at 19:06
  • If you check that into github.com we can take a look? [What does Procmon.exe say](https://stackoverflow.com/questions/59416186/access-to-path-denied-while-reading-a-dll-from-program-files-which-is-actually-g#comment105024050_59416186)? Lots of deployment tools described in my [deployment link mess here](https://stackoverflow.com/a/25005864/129130). – Stein Åsmul Aug 01 '20 at 20:34
  • Search for *"General Debugging"*. – Stein Åsmul Aug 01 '20 at 20:39
  • It worked. I must apologize to the WiX creators because the source of the problem was entirely my lack of knowledge about this tool. @SteinÅsmul, I can't thank you enough for all the tips and orientation. I will capture some screens of the Embarcadero's IDE, in order to show the correlations that must be considered between the service properties at the IDE and the WiX installer package. I hope others will benefit from what I've learned today. – André Murta Aug 01 '20 at 22:17

1 Answers1

2

After the useful tips given in the comments, everything worked when I correlated the properties Name and DisplayName of the Embarcadero's IDE with the tags Name and DisplayName of the WiX installer project source, also, it was necessary to define the Arguments tag in <ServiceInstall>

enter image description here enter image description here

That's it. Now I can handle my service using WiX. I'm quite confident the details above are also valid for the Delphi compiler.

André Murta
  • 141
  • 2
  • 9
  • Great, please be sure to test upgrade scenarios and uninstall and repair scenarios. Version increment binaries. That looks good though. Whenever you use standard MSI constructs you gain a lot of stability - generally. It is like standards compliant html - suddenly it works in all browser. – Stein Åsmul Aug 02 '20 at 01:02
  • [Some messy, pragmatic WiX / MSI "advice" here](https://stackoverflow.com/questions/45840086/how-do-i-avoid-common-design-flaws-in-my-wix-msi-deployment-solution/45840087#45840087). Intended as a summary of things not found in books - hence not very presentable. Not great. Better than nothing :-). – Stein Åsmul Aug 02 '20 at 02:03
  • Tested in different scenarios, including the one during the package update without uninstalling an older version, which caused the popup described in the original post. It worked perfectly. – André Murta Aug 03 '20 at 16:07
  • Always good to do. Deployment is a "gotcha experience". You tend to discover problems when they are too late to fix properly. "In the wild-problem". As stated: using built-in MSI constructs helps a lot for reliability - in general. If you want to use patching, please be aware that this is a problematic area of MSI - avoid if you can. That is easy for small products - just use a full installer. – Stein Åsmul Aug 03 '20 at 16:11