[wix-users] why does 64 bit bundle install key/value pairs under the 32 bit HKLM/Software/Win6432Node registry key?

[Ian Bell]

EDWIN: Let me make sure I'm following you correctly here. The auto-update
feature of your application downloads a new setup.exe and uses it to upgrade
to the new version *and* it also uninstalls the old version by locating the
UninstallString in the registry for the old version?
IAN:  Something like that.   In short, here is what happens: 
	1) my application downloads the new release (i.e. setup.exe)
	2) my application spawns the child process
	3) my application self terminates
	4) the child process installs the new release by executing the
setup.exe program
	5) the child process confirms the new release was properly installed
by checking registry entries
	6) the child process starts the new release of my application
	7) the child process self-terminates



EDWIN: Have you defined Bundle/@UpgradeCode in your setup project?
Bundle/@UpgradeCode should be static just like Product/@UpgradeCode is
static in your MSI project. Both of those should be different.
IAN: Yes, I have defined the upgrade code in both the bundle project and the
MSI project.   These two upgrade codes are different and static (i.e. they
do not change between releases) 


EDWIN: When you properly define Bundle/@UpgradeCode then burn automatically
detects upgrades and uninstall the old bundle for you.
IAN:  This is the first time I am using the WIX installers and I have not
tested/confirmed this feature with different versions/releases of my
application.   What I have found is that running the WIX SETUP program the
first time installs the application while running the WIX SETUP program a
second time uninstalls/repairs the application.   

EDWIN: To get the proper upgrade behavior on the MSI itself you need
Product/@UpgradeCode and use the MajorUpgrade element or author Upgrade
yourself. I'd recommend using the MajorUpgrade element.
IAN:  I believe I have already done that.   Just to be certain, the WIX MIS
project defines the following:

<Product Id="$(var.ProductCode)"
  Version="$(var.MajorMinorRevisionBuild)"
 
Name="$(var.MyApplicationNameVersionMajorMinorPlatformBitsRevisionDate)"
           Language="1033"
           Manufacturer="$(var.Manufacturer)"
           UpgradeCode="{B0D3A7ED-3886-4F65-B370-DFD208D2FE87}">

    
    <Package InstallerVersion="301"
             Compressed="yes"
             InstallScope="perMachine"
             InstallPrivileges="elevated"
             Description="Installs the
$(var.MyApplicationNameVersionMajorMinorPlatformBitsRevision) program"
             Manufacturer="$(var.Manufacturer)"
             Comments="$(var.MyApplicationReleaseYear) $(var.Manufacturer)"
             Platform="$(var.Platform)"/>

    <Condition Message="$(var.MinimumWindowsVersionSupportedMessage)">
      <![CDATA[Installed OR (VersionNT >=
$(var.MinimumWindowsVersionSupported))]]>
    </Condition>

    <MediaTemplate EmbedCab="yes" />
    <MajorUpgrade DowngradeErrorMessage="$(var.DownGradeErrorMessage)" />


EDWIN: Once all of this is properly setup you should be able to download
your setup.exe and run it to upgrade (install the new version _and_
uninstall the old version) automatically without needing to find the old
version or anything like that.
IB:  Yes, I am aware of this and have previously confirmed this
functionality in WIX installers.   My application queries installation
information in the registry and hard disk for other reasons (e.g. cleaning
up orphaned entries that previous installers failed to remove).   Given my
application already queries registry information, I then use this
information to determine whether a new release is available by comparing it
with information of the new release on the server.
--
Edwin G. Castro

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant
http://www.firegiant.com/