There's nothing wrong with a sequence of InstallExecute, REP, InstallFinalize at the end of the execute sequence - it's one of the choices documented in MSDN. Some rambling thoughts/brain dump to think about: 1. Are you sure you haven't overlapped the Progid element with the registry stuff? I'm pretty sure that the Progid setting populates the Extension and Progid tables in the MSI file - you can check that - and that means Windows Installer will just do all that registration without you needing to add registry entries. Something like that may be going on. 2. You're sure that the component guid is the same in the old and the upgrade installs? 3. Is there a bitness change going on? Was the old version x86 and the new one 64? It's not clear from the log what bitness is being created and which removed. The other issue in this area is Registry Reflection. A 64-bit file association prior to Windows 7 was automatically available to 32 and 64-bit programs. It's suggested here: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464643(v=vs.85).aspx that both items, native and WOW64 be explicitly created, so an x64 install would create both x64 and WOW64 file associations.
Phil Wilson On Tue, Dec 3, 2013 at 11:19 AM, Brian Gillespie <br...@mcneel.com> wrote: > Hi, > > I'm using WiX 3.5 in VS 2010. > > Some of my users are experiencing a problem after performing a major > upgrade of our product. One component (WiX for the component shown below) > seems to have it's file extension and mime type properly registered during > WriteRegistryValues, and then the registration is removed because > RemoveRegistryValues executes after WriteRegistryValues. > > Our application includes VS2005 runtimes, and so I think our InstallExecute > sequencing may be less than ideal, but seems to hold together for the most > part: > > *Install Execute:* > <InstallExecuteSequence> > <!-- see the RemoveExistingProducts help entry at > http://msdn.microsoft.com/en-us/library/aa371197.aspx for other options > for > scheduling RemoveExistingProducts --> > <!-- Sequencing RemoveExistingProducts after InstallFinalize seems to > leave more on the machine than I'd like > - especially when switching between commercial and beta builds. At > least for betas, I think it's better to do a full remove > right before InstallInitialize. > <RemoveExistingProducts > After="InstallFinalize"></RemoveExistingProducts> > --> > > <!-- > "Avoid placing RemoveExistingProducts action before > InstallInitialize" > A warning from the community content at MSDN: > http://msdn.microsoft.com/en-us/library/aa371197.aspx > If your installation includes VS2005 runtime merge modules and > upgrades existing installation > (which also contains the same C /C++ runtime merge modules), avoid > placing RemoveExistingProducts > action before InstallInitialize, otherwise upgrade on Vista will > uninstall already installed > SxS runtime modules and silently fails to install them again, > obviously breaking all > installed programs depending on VS2005 cruntime. (can be cured by MSI > 'repair' facility). > <RemoveExistingProducts > Before="InstallInitialize"></RemoveExistingProducts> > --> > > <InstallExecute Before="RemoveExistingProducts"></InstallExecute> > <RemoveExistingProducts > Before="InstallFinalize"></RemoveExistingProducts> > <!-- Other custom actions omitted for brevity --> > </InstallExecuteSequence> > > > > *Component registration is as follows:* > <Component Id="RhinoInstallerEngine.64bit.$(var.Platform)" > Guid="11B0087A-8339-482D-8F17-BCD30780EC1B" > Directory="INSTALLDIR.System.x64"> > <File Id="RhinoInstallerEngine.64bit.$(var.Platform).rhiexec.exe" > Source="..\$(var.Platform)\Program Files\System\x64\rhiexec.exe"/> > <RegistryValue Root="HKLM" > Key="SOFTWARE\Classes\Rhino.InstallerPackage\DefaultIcon" > Value=""[INSTALLDIR.System.x64]rhiexec.exe",0" Type="string" /> > <RegistryValue Root="HKLM" > Key="SOFTWARE\Classes\Rhino.InstallerPackage" Name="FriendlyTypeName" > Value="!(loc.RHIFileDescription)" Type="string" /> > <ProgId Id='Rhino.InstallerPackage' Description='Rhino Installer > Package' Icon='RhinoInstallerEngine.64bit.$(var.Platform).rhiexec.exe' > IconIndex='0'> > <Extension Id='rhi' ContentType='application/rhi'> > <Verb Id='open' Command='!(loc.RHIFileVerb)' > TargetFile='RhinoInstallerEngine.64bit.$(var.Platform).rhiexec.exe' > Argument='"%1"' /> > </Extension> > </ProgId> > </Component> > > > *Attached is the verbose install log.* > Of note are lines: > *Line 48242*: MSI (s) (5C:20) [09:35:54:748]: Executing op: > RegAddValue(Name=Content Type,Value=application/rhi,) > > *Line 62911*: MSI (s) (5C:78) [09:36:06:713]: Executing op: > RegRemoveValue(Name=Content Type,Value=application/rhi,) > > Any ideas how I can fix this? Please let me know if you need any other > details. > > - Brian > > Brian Gillespie > Rhinoceros Development > Robert McNeel & Associates > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
