Hi, I changed my approach a little bit. For reference:
This is what I added to my wxs file: <CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' /> <InstallUISequence> <Custom Action='CheckingSpecialist' After='LaunchConditions' /> </InstallUISequence> <Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist.dll' /> And this is my small CheckSpecialist.c: http://pastebin.com/mBL01Wtz So the return value is either ERROR_SUCCESS or !ERROR_SUCCESS. I do not use MsiSetProperty any more and just one custom action. If anybody sees a bad thing in this approach/code I would really appreciate a hint. Regards, Luke Am 25.07.2010 17:27, schrieb Blair: > If the other setup package is ultimately MSI, you should ideally use the > Upgrade table to remove it (via the RemoveExistingProducts action using the > "Major Upgrade" method). However, that doesn't work if the ALLUSERS value > differs between the two installations and you will need to look at ways to > bootstrap that uninstallation, since you can't run it at all from the > InstallExecuteSequence. > > If the other setup package is not-at-all MSI, there is nothing to pass to > Windows Installer, since WI can only deal with MSI packages, and you will > need to execute the uninstall executable somehow/somewhere. > > -----Original Message----- > From: Lukas Haase [mailto:lukasha...@gmx.at] > Sent: Sunday, July 25, 2010 5:18 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI > > Dear Blair, > > Thank you for the hint! I will replace my MessageBox-call prompt with > MsiProcessMessage/WcaProcessMessage ... > > Apart from this, my approach is good practice? Or is it maybe better to > pass the uninstall to MSI and executing it there rather than calling > ShellExecuteEx from the DLL? > > Regards, > Luke > > > Am 23.07.2010 08:54, schrieb Blair: >> You shouldn't prompt from the execute sequence. There are ways of > "running" >> MSI files where there is no user session to respond to the prompt and you >> would hang your install. >> >> The best way to show a message box from a custom action (and the only >> supported way if you must do so from the execute sequence) is using the >> MsiProcessMessage API (or something that wraps it, like WcaProcessMessage > or >> Microsoft.Deployment.WindowsInstaller.Session.Message). >> >> -----Original Message----- >> From: Lukas Haase [mailto:lukasha...@gmx.at] >> Sent: Thursday, July 22, 2010 12:47 PM >> To: wix-users@lists.sourceforge.net >> Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI >> >> Dear Blair, >> >> Am 22.07.2010 01:04, schrieb Blair: >>> 1. You can build MSIs with WiX that don't require running the setup as >>> administrator. Nothing that can be done outside of Windows Installer >> without >>> elevation requires elevation in Windows Installer to also do. >> >> In fact this is exactly what I do NOT want: I need to register a COM >> component which requires admin privileges. >> >> So I have >> >> <Property Id="ALLUSERS">1</Property> >> >> and >> >> <Condition Message="..."> >> Privileged >> </Condition> >> >> and I am lucky. In fact this is exactly what messed up my previous >> installations with SetupSpecialist: The old "viewer" did not need >> registering a COM, so some users installed as admins and systemwide, >> others not. >> >> Finally, SetupSpecialist lets you run the setup as normal user and when >> registering the COM the there is an error. The setup terminates and the >> a half installed system is left. >> >> In my opinion it is the best and consistent way to install the software >> just into the system (incl. Shortcuts for all users) >> >>> 2. Windows Installer has no built-in support for detecting/removing >> non-MSI >>> packages. However, if you know how to find/remove your SetupSpecialist >>> package (the Uninstall key, perhaps?) then you can detect presence and >>> automate removal as part of your upgrade (does the old installer allow >>> "silent" removal?) You may have trouble detecting/removing things >> installed >>> by other than the current user, however, but that is due to the nature of >>> how Windows treats user accounts/profiles, not do to any inherent >> limitation >>> in Windows Installer itself. >> >> Thank you for the hint. This is what I have done now. As written in a >> new post ("InstallExecuteSequence completely ignored") I face heavy >> problems concerning this right now. >> >> However, my approach is: >> >> <CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' >> DllEntry='CheckSpecialist' /> >> <CustomAction Id='RefuseInstall' Error='You must uninstall the old one >> first' /> >> >> <InstallExecuteSequence> >> <Custom Action='CheckingSpecialist' After='LaunchConditions' /> >> <Custom Action='RefuseInstall' After='CheckingSpecialist'>ABORT = >> "1"</Custom> >> </InstallExecuteSequence> >> >> <Binary Id='CheckingSpecialist' >> SourceFile='CheckSpecialist/Release/CheckSpecialist.dll' /> >> >> The DLL just opens the registry key in Uninstall and reads out the path >> to the uninstall program. >> >> Then it asks: "You must remove the old first, do you want to?". If the >> users answers with no, then ABORT = 1 is set. >> >> Otherwise, the process uninstall is started with ShellExecuteEx and >> waited for termination with WaitForSingleObject. Afterwards ABORT = 0 is >> set. >> >> If it fails to open the key (i.e. no old version found) just ABORT = 0 >> is set. >> >> Is this a good idea or did I break some best practices? >> >> Regards, >> Luke >> >> >> >> > ---------------------------------------------------------------------------- >> -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> > ---------------------------------------------------------------------------- > -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > > > ---------------------------------------------------------------------------- > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
