I agree that one file per component is best, but would doing so conflict with Blair's 2nd solution for registering my services such that the uninstaller can wait for the StopServices step to release the other files in use before deciding that a restart is required?
-----Original Message----- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: June 19, 2013 14:10 To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Uninstall restart issue No, a component can only have one key path, be it a file, directory, or registry entry. Any time the key file changes, the component will be serviced. If you have the exe being the key file and it never changes, then your jar files will never be updated unless you are doing a major upgrade with REP scheduled early (which in effect removes the old version before installing the new version). Personally I would place each file in its own component, in case you ever want to do a minor upgrade or patch in the future. -----Original Message----- From: Alain Forget [mailto:afor...@cmu.edu] Sent: Wednesday, June 19, 2013 12:51 PM To: Hoover, Jacob; 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Uninstall restart issue Oh, I see, so if we make a Component contain multiple files, any time any one of those files are changed, the installer will uninstall and reinstall the entire component, and all the files therein (assuming I understand correctly). This is fine for our purposes, and we are already only doing MajorUpgrades for simiplicity, so this all sounds good. Once I do it, I'll post back to let you know how it turns out. -----Original Message----- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: June 19, 2013 13:30 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] Uninstall restart issue One file per component is the most flexible for maintenance, but depending on your patching/upgrade plan it may not be needed. If the key file to the component is a 3rd party exe (and all of your jars were within this component), then you would have to have RemoveExistingProducts scheduled early, and you could only ever do major upgrades (unless you are going to recompile their exe after incrementing the version info). -----Original Message----- From: Alain Forget [mailto:afor...@cmu.edu] Sent: Wednesday, June 19, 2013 12:12 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue You're quite right; after installing our software, there is a separate jsl.exe process for each of our services. One disturbing thing I've noticed is that if I then reboot the computer after installing our software, then open the Task Manager and press the Show Processes from All Users button, the Task Manager UI becomes unresponsive, even though it will still update the visible processes' statuses. Once our software is uninstalled, bringing up the Task Manager and pressing Show Processes From All Users works fine. Odd that this does not happen immediately after installing, but before restarting. But anyway, one problem at a time, in case what we're doing now will fix it. I will try your 2nd suggestion: <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> One question: I assume that all the class files used by each service should still be in their own parent Component (as the tutorials strongly advocate), or should all files used by a given service be in the the same parent Component as the service (i.e. be placed at the last "..." in the above code)? Alain -----Original Message----- From: Blair Murri [mailto:os...@live.com] Sent: June 19, 2013 09:08 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue I looked at the source code from the jsl website and what they are doing is installing whichever jsl*.exe binary as the service executable (passing '-ini <config-file>' as the argument), and loading the java.dll file from the selected java runtime after parsing the config file, then using jni to connect the service control manager callbacks and api to the java classes. Restart manager (and its predecessor) is going to look at the EXE binary that was used to start each process holding files of interest. It also checks to see if each process of interest is a service or not, treating each slightly differently. Windows Installer doesn't easily share the same service binary for multiple services from different components due to the requirement that the component defining a service have its keypath be the service binary, which is the reason I used a pattern of reusing the jsl.exe binary into multiple target binary files (one for each service). Blair > From: afor...@cmu.edu > To: wix-users@lists.sourceforge.net > Date: Tue, 18 Jun 2013 17:31:25 -0400 > Subject: Re: [WiX-users] Uninstall restart issue > > 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 ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 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
