Re: [WiX-users] Running an MSI twice
The upgrade path wouldn't concern me to much, because our end customer relationships are all 1-to-1. But you got me thinking with the signature part. Maybe my approach on this was not quite the best. Maybe I should consider just teaching my internal customer's how to make easy setup projects for pure configuration purposes. My installer application supports hierarchical binding of MSI packages anyway (kinda like features but with whole MSIs). So there even would be the possibility to just hook a new package below the one they want to configure. Well I guess I'll go with that idea. Makes me feel more secure in this matter. :) Thank you guys for your help. PS.: If some other guy stumbles upon my initial problem, I kinda found a way to work that out: If you take the same-version-but-changed-package and call it with REINSTALL=ALL and REINSTALLMODE=vomus MSI will recache the MSI package instead of taking the one chached already. So that would have been a way. -- 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=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Running an MSI twice
Greetings, I have a question regarding the Major upgrade feature of Wix/MSI. I configured my Wix project to be able to do a major upgrade even on the same version. So only downgrades are not possible. Result: I build version 1.0.0.0 and run it. -- Installs the product. I rebuild version 1.0.0.0 with a different product code and run it. -- Does an upgrade to essentially the same version (including removal of the previous instance) So, everything as expected. My problem now is: - I want to give my internal customers the possibility to configure the MSI package, allowing them to add command line commands, which will get executed by one of my custom actions. Therefore I developed a small .NET application, which accesses the MSI table changing a property which includes the commands AND changing the ProductCode property. My expectations now were, that, because the ProductCode was changed, MSI now again sees the configured package as a Major Upgrade and removes the old instance and installs the new one. But it doesn't. Somehow MSI still knows, that this particular MSI package is installed on the system and does only a reconfiguration of the old instance, by using the original MSI package from windows chache, including the old command property. Is there something else I need to change to tell MSI that the configured package is essentially the same a a new built one? Is that even possible? kind regards, Michael Forstner -- 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=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
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=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running an MSI twice
It's not a major upgrade unless you increment the product version in the first three digits. See the docs here, Remarks section: http://msdn.microsoft.com/en-us/library/aa370859(v=vs.85).aspx --- Phil Wilson On Fri, Mar 7, 2014 at 5:45 AM, fom Forstner Michael f...@keba.com wrote: Greetings, I have a question regarding the Major upgrade feature of Wix/MSI. I configured my Wix project to be able to do a major upgrade even on the same version. So only downgrades are not possible. Result: I build version 1.0.0.0 and run it. -- Installs the product. I rebuild version 1.0.0.0 with a different product code and run it. -- Does an upgrade to essentially the same version (including removal of the previous instance) So, everything as expected. My problem now is: - I want to give my internal customers the possibility to configure the MSI package, allowing them to add command line commands, which will get executed by one of my custom actions. Therefore I developed a small .NET application, which accesses the MSI table changing a property which includes the commands AND changing the ProductCode property. My expectations now were, that, because the ProductCode was changed, MSI now again sees the configured package as a Major Upgrade and removes the old instance and installs the new one. But it doesn't. Somehow MSI still knows, that this particular MSI package is installed on the system and does only a reconfiguration of the old instance, by using the original MSI package from windows chache, including the old command property. Is there something else I need to change to tell MSI that the configured package is essentially the same a a new built one? Is that even possible? kind regards, Michael Forstner -- 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=122218951iu=/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=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running an MSI twice
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=122218951iu=/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
Re: [WiX-users] Running an MSI twice
Are you wanting to create a major upgrade scenario /just /to change the value of that property? If so, that's not necessary. You can dynamically update the property's value at install time, based on data your customers enter into the installer's UI or enter on the command line to run the installer. In this way, there is no need to recompile. Does that help? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-an-MSI-twice-tp7593163p7593212.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=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running an MSI twice
Unfortunately not. The idea is that I deliver a base version of a product. My internal customers can add some configuration commands on their own. Now, if they want to change the configuration commands they use my program and change the related propery in the MSI. Then they deliver it to the end customer, which just deploys the new package to their machines. The new package is called and a upgrade should happen. Unfortunately no user input is possible in my scenario. kind regards -- 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=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running an MSI twice
Be aware, if you write those values back into the MSI, then you just invalidated the digital signature. The MSI will have to be re-signed. MSI is just a database, so you can easily write a script to update it. You can also edit the MSI with Orca (or my favorite, InstEd). Now the (weird) thing to consider. What happens when an end customer gets our package from middleman-1 and then gets an upgrade (or same version) from middleman-2? That would be a weird upgrade path as far as the user is concerned... Dave From: fom Forstner Michael f...@keba.com To: General discussion about the WiX toolset. wix-users@lists.sourceforge.net Sent: Friday, March 7, 2014 4:30 PM Subject: Re: [WiX-users] Running an MSI twice Unfortunately not. The idea is that I deliver a base version of a product. My internal customers can add some configuration commands on their own. Now, if they want to change the configuration commands they use my program and change the related propery in the MSI. Then they deliver it to the end customer, which just deploys the new package to their machines. The new package is called and a upgrade should happen. Unfortunately no user input is possible in my scenario. kind regards -- 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=122218951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
