Hm, interesting. Assuming you are right and this is what's going on, I don't think all four services are sharing jsl.exe, because it is only used to create (or remove) Java-based services. Wouldn't the exe actually be java.exe, because my services are Java programs? If so, I'm not sure how to tell if a running java.exe is for our services or some other Java-based software.
I am currently travelling, but will look more closely into what the services' exe is. As an insanity check, I assume that should be in the Task Manager process list, or must it be found elsewhere? If the exe is java.exe, and not jsl.exe, how do you think that might affect your other proposed solutions (which I like, if I can get them to work and understand them more fully)? Alain -----Original Message----- From: Blair Murri [mailto:os...@live.com] Sent: June 18, 2013 04:22 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue 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 ------------------------------------------------------------------------------ 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
