Restart manager in your situation is probably working something like this:
Look at each component that is being removed
Look at each and every file in each of those components
Look at each and every process holding any of those files open?
Is that process's binary the keypath of any component that contains a
ServiceConfig that will be stopping that service in this transaction? If so,
eliminate this process as one that will cause a reboot.
If there are any processes left over, prompt for user decision (since a reboot
could happen).
If after actually running the transaction none of the files are still open when
they are deleted then no actual reboot will be requested (or executed) as a
result of files-in-use (despite the dialog).
I'm guessing in your case that all four services are sharing one executable
(jsl.exe) and that executable isn't the keypath of one or more of the
components supplying the ServiceConfig stop directives. Thus, restart manager
doesn't find the service(s) and thus doesn't know how the restart will be
avoided (since none of the processes can use restart manager's "freeze dry"
method since all of them in your case are services).
To address this one remedy would be to restructure along these lines:
<Component Id="ClientCommModuleService">
<File KeyFile="yes" Name="ClientCommModuleService.exe" Source="jsl.exe"/>
<ServiceControl Name="MYCLIENTClientCommModule" Stop="both" .../>
...
</Component>
<CustomAction Id="cmdInstallClientCommModuleService" .../><!-- reference
#ClientCommModuleService.exe instead of #jsl.exe in defining this CA-->
<InstallExecuteSequence>
<Custom Action="cmdInstallClientCommModuleService"
...>$ClientCommModuleService>2</Custom>
</InstallExecuteSequence>
repeat for each of the remaining three services.
A big problem with using JSL this way is that is that it is a form of Self-Reg
(and all the evil that entails). A much better (more reliable and repeatable)
way would be to identify each of the elements from your .ini service config
files related to service configuration and copy them into the appropriate
places in the ServiceControl & ServiceInstall (and their child elements) along
the lines of this:
<Component Id="ClientCommModuleService">
<File KeyFile="yes" Name="ClientCommModuleService.exe" Source="jsl.exe"/>
<ServiceInstall Name="MYCLIENTClientCommModule" Arguments="-ini
[#jsl_ClientCommModuleServiceConfig.ini]" ...>
...
</ServiceInstall>
<ServiceControl Name="MYCLIENTClientCommModule" Stop="both" .../>
...
</Component>
Even better would be to write a Wix Extension to wrap this second pattern and
contribute it to the JSL project so they could maintain it (since the "-ini"
argument (and how that file is parsed) is their implementation detail) which
would parse the INI file at build time to fill in all the service related
pieces (that way data is never entered twice). It could even select jsl.exe or
jsl64.exe automatically based on whether the component was 32- or 64-bit, or
include the debug version if debug is defined, or whatever).
Blair Murri
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
