Hi, thanks for your respones. I think I may have just been using the wrong words to describe my situation. I'm quite new to Wix/MSI. Let me try to explain the problem with an example.
I have created the following small project: ====================================================== <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi";> <Product Id="*" Name="TestWix" Language="1033" Version="1.0.0.0" Manufacturer="Manufacturer" UpgradeCode="4f13d2b9-9a63-41ca-adad-9cd300f270af"> <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" /> <MajorUpgrade AllowSameVersionUpgrades="yes" DowngradeErrorMessage="A newer version of [ProductName] is already installed." /> <MediaTemplate EmbedCab="yes" /> <Property Id="UTILIZE_IN_CA" Value="1234"/> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFilesFolder"> <Directory Id="INSTALLFOLDER" Name="TestWix" /> </Directory> </Directory> <ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER"> <Component Id="MyComponent" Guid="3B37424F-EC58-43E8-9F67-87F56160438D"> <File Id="MyFile" Source="U:\test.txt" KeyPath="yes"/> </Component> </ComponentGroup> <Feature Id="ProductFeature" Title="TestWix" Level="1"> <ComponentGroupRef Id="ProductComponents" /> </Feature> </Product> </Wix> ====================================================== So, because I allow same version upgrades in the MajorUpgrade tag I essentially can rebuild the project without any changes and install it right over an older package which was installed before. I guess that works because every build brings a new GUID for the ProductCode property. So, as expected upon install of the new package the FindRelatedProducts Action reports that it has found an installed product, which will, simply said, be replaced by the new installation: Action 00:15:49: FindRelatedProducts. Searching for related applications Action start 00:15:49: FindRelatedProducts. FindRelatedProducts: Found application: {c33104a2-87c6-4b0b-9b9f-6a86d599d7f2} Action ended 00:15:49: FindRelatedProducts. Return value 1. My situation: I want to be able to change the property "UTILIZE_IN_CA" without everytime rebuilding. In fact, my internal customers can't do that. I want to supply them with a program, which manipulates the MSI database in a way that "UTILIZE_IN_CA" and the "ProductCode" will get changed to a new value. I have already made this program and I think I can say it works fine. I can confirm the changes via Orca. My expections were now, because I changed the property ProductCode, installing the changed MSI package over the unchanged package installation, will result in the same behaviour as before, so that a "upgrade" process can happen. But the prolem is, it doesn't: Action 00:16:25: FindRelatedProducts. Searching for related applications Action start 00:16:25: FindRelatedProducts. Action ended 00:16:25: FindRelatedProducts. Return value 0. MSI says there is no related product and just starts a reconfiguration process of the already installed package utilizing the cached MSI package from the C:\Windows directory, which ofcourse does not include the changed property. Is there something else I need to change to trigger MSI to consider the changed package as a "upgrade"? Is it even possible? Are there more things that FindRelatedProducts checks to decide if it has found a product or not? kind regards, Michael ________________________________________ Von: Nick Ramirez [nickra...@hotmail.com] Gesendet: Freitag, 7. März 2014 19:25 An: wix-users@lists.sourceforge.net Betreff: Re: [WiX-users] Running an MSI twice Changing ProductCode and Version, but keeping UpgradeCode the same denotes a major upgrade of the same product. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-an-MSI-twice-tp7593163p7593173.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
