Could you not change your product code of your MSI, and enforce this new one is per machine only? Then with burn, you could detect the previous product code and uninstall it if found (this would only work if the same user was installing the per machine as the one who installed it per user). Or is the problem that burn detects it but isn't able to remove it because it was per user but required elevation?
I still find it strange you had a per user MSI capable of installing to the program files folder. -----Original Message----- From: Derek Wickern [mailto:dwick...@gmail.com] Sent: Tuesday, December 18, 2012 1:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX 3.6 upgrading perUser to perMachine I would really appreciate some help with this. As it is, I can't upgrade to Burn because the installer no longer has privileges to write to ProgramFiles in per-user mode. I found this post from 2009: http://stackoverflow.com/a/678190 >Sadly, the Windows Installer doesn't support that. Some process outside your >package (a bootstrapper/chainer?) will have to manage the upgrade from >per-user to per-machine. Now there is an official bootstrapper. How can I best use it to upgrade per-user to per-machine? On 11/28/12, Derek Wickern <dwick...@gmail.com> wrote: > It looks like I can use MsiEnumRelatedProducts to find the existing > products by upgrade code. I can't uninstall the old products from a > custom action, but I should be able to use the bootstrapper for that. > I know there will be difficulty uninstalling a product which was > installed by another user, but I don't think I can solve that. I'm > just hoping to achieve a smooth upgrade path for most users. > > What's the best way to run my custom code from burn? Should I write a > managed bootstrapper application? > > On 11/27/12, Philip Patrick <patri...@varonis.com> wrote: >> Well, not sure ours was the best solution, but what we did is a >> custom action that literally moves all registry entries related to >> per-user package to per-machine. That means from >> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\SID >> -OF-USER to UserData\S-1-5-18 (latter stores per-machine >> installations). >> >> We decided to go this way because: >> 1. It is not possible to uninstall another MSI from custom action >> since Windows Installer doesn't allow concurrent installations 2. >> Per-user installation could have been installed with different user >> than the one performing upgrade - this way MSI will not "see" that >> there is something installed. At least we saw this behavior from our >> investigations. >> >> Today, I wouldn't recommend going this way - it is too buggy. Instead >> I would create a custom action that detects such per-user >> installation and asks user to uninstall first. >> >> >> >> -----Original Message----- >> From: Derek Wickern [mailto:dwick...@gmail.com] >> Sent: Wednesday, November 28, 2012 02:51 >> To: wix-users@lists.sourceforge.net >> Subject: [WiX-users] WiX 3.6 upgrading perUser to perMachine >> >> I need to upgrade a package which was unfortunately created with >> per-user scope. It's installing to ProgramFiles. I understand that >> MSI can't upgrade my perUser to perMachine. >> >> I have some ideas: >> 1. Automatically uninstall the per-user package (custom action?) 2. >> Install >> the per-machine package right on top of the per-user package 3. >> Detect the scope of the original package and upgrade to the same >> scope. Otherwise default to perMachine. >> >> I just upgraded my project to WiX 3.6 and I'm using burn to create a >> boostrapper. I'm hoping that gives me more options. >> >> What's the best solution here? >> >> --------------------------------------------------------------------- >> --------- Keep yourself connected to Go Parallel: >> INSIGHTS What's next for parallel hardware, programming and related >> areas? >> Interviews and blogs by thought leaders keep you ahead of the curve. >> http://goparallel.sourceforge.net >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> --------------------------------------------------------------------- >> --------- Keep yourself connected to Go Parallel: >> INSIGHTS What's next for parallel hardware, programming and related >> areas? >> Interviews and blogs by thought leaders keep you ahead of the curve. >> http://goparallel.sourceforge.net >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> > > > -- > Derek Wickern > -- Derek Wickern ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
