Re: [WiX-users] Preserving install directory on upgrade
That sounds like a promising approach. I'll try that one too. Anyone know any downside of getting the old installdir that way? kind regards, Michael -Ursprüngliche Nachricht- Von: Phil Wilson [mailto:phildgwil...@gmail.com] Gesendet: Samstag, 19. April 2014 20:28 An: General discussion about the WiX toolset. Betreff: Re: [WiX-users] Preserving install directory on upgrade The issue to beware of is about per user/per machine. Your search is for a per machine install, which is fine if you know that the previous was per machine and this one is not per user, and cross context would not upgrade anyway. Maybe ideally there would be a registry search option that behaves somewhat like the Registry table, searching HKCU (for the CU) on a per user install and HKLM on a per machine install then you'd get the location appropriate for the context if there was a mixture or multiple per user installs. --- Phil Wilson On Fri, Apr 18, 2014 at 4:45 PM, Jeremy Farrell jeremy.farr...@oracle.com wrote: Perhaps I'm missing something, or this just works by luck, but it seems to work for me in WiX v2: Upgrade Id='$(var.GuidUpgrade)' UpgradeVersion MigrateFeatures='no' Property='UPGRADING' / /Upgrade Property Id=OLDINSTALLDIR RegistrySearch Id=GetOldInstallDir Type=raw Win64='$(var.Comp64)' Root=HKLM Key=Software\Microsoft\Windows\CurrentVersion\Uninstall\[UPGRADING] Name=InstallLocation / /Property If I'm living on borrowed time, I'd value an explanation. From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: Friday, April 18, 2014 6:56 PM There is a kind of built-in way, and that's to set the ARPINSTALLLOCATION property (with a type 51 set property CA) after you know the folder location. The good part about this is that it exposes the location to the standard APIs such as using MsiGetProductInfo (INSTALLPROPERTY_INSTALLLOCATION... ) and the equivalents in script etc. The bad part about it is that retrieving it requires code because the registry search to find it is awkward. --- Phil Wilson On Fri, Apr 18, 2014 at 9:45 AM, Neil Sleightholm n...@x2systems.com wrote: Does that persist across an upgrade? (Last time I checked, admittedly in v3.6, it didn't.) Neil -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: 18 April 2014 17:16 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Preserving install directory on upgrade If your msi package will always be launched by a burn bundle, then you could initialize and set Persisted=yes on the burn string variable, which is then passed as a MsiProperty to the package. But if the msi package will be launched by on-demand msiexec install due to advertising or a repair issue, or if the user would ever launch the msi directly, then the value of properties used in the initial install should be saved and initialized the next time the package is launched, as indicated previously. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Preserving install directory on upgrade
Hi, I recently detected a problem within my installer package (No UI). I implemented it with major upgrade capability to easily install new versions. What I have realized now is, that during major upgrade I loose my previousely set install directory: This is my directory structure: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLDIR Name=MyCompany Directory Id=DIR_App Name=MyApp Directory Id=DIR_Base Name=Base Directory Id=DIR_Bin Name=bin/ Directory Id=DIR_Dll Name=dll/ /Directory /Directory /Directory /Directory /Directory /Fragment /Wix The initial installation is called with parameter: INSTALLDIR=C:\test This results as expected with my application being installed to c:\test. If I make now a new version of my installation and call it with no parameter, the previosu version is deleted and the new version is intalled. But now the new version is installed to the default directory C:\Program Files\MyCompany\.. Is there some way to preserve the custom install directory, so that MSI remembers it? Or do I have to write the INSTALLDIR to the registry and get it from there during upgrade? kinf regards, Michael -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Preserving install directory on upgrade
Hi, thanks for your response. I found something similar already on the internet, but thought there might be some built in function. Thanks for the link though. This one is much better described. I will do it that way then. kind regards, Michael -Ursprüngliche Nachricht- Von: Neil Sleightholm [mailto:n...@x2systems.com] Gesendet: Freitag, 18. April 2014 14:58 An: General discussion about the WiX toolset. Betreff: Re: [WiX-users] Preserving install directory on upgrade You would need to save it somewhere and read it on upgrade, Rob has an example here http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/ Neil -Original Message- From: fom Forstner Michael [mailto:f...@keba.com] Sent: 18 April 2014 13:00 To: General discussion about the WiX toolset. Subject: [WiX-users] Preserving install directory on upgrade Hi, I recently detected a problem within my installer package (No UI). I implemented it with major upgrade capability to easily install new versions. What I have realized now is, that during major upgrade I loose my previousely set install directory: This is my directory structure: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLDIR Name=MyCompany Directory Id=DIR_App Name=MyApp Directory Id=DIR_Base Name=Base Directory Id=DIR_Bin Name=bin/ Directory Id=DIR_Dll Name=dll/ /Directory /Directory /Directory /Directory /Directory /Fragment /Wix The initial installation is called with parameter: INSTALLDIR=C:\test This results as expected with my application being installed to c:\test. If I make now a new version of my installation and call it with no parameter, the previosu version is deleted and the new version is intalled. But now the new version is installed to the default directory C:\Program Files\MyCompany\.. Is there some way to preserve the custom install directory, so that MSI remembers it? Or do I have to write the INSTALLDIR to the registry and get it from there during upgrade? kinf regards, Michael -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Modify MSI version
I have to ask again, because I have to make a decision soon. Is there any important point that speaks against modifying the MSI database after build, if it happens in a controlled environment? As a simple example: -- A MSI package including a property called configValue=1 -- My tool changes the property in MSI database from configValue=1 to configValue=2 Is there some inconsistency going on if I do that, or is it okay? kind regards, Michael -Ursprüngliche Nachricht- Von: fom Forstner Michael [mailto:f...@keba.com] Gesendet: Mittwoch, 09. April 2014 13:54 An: General discussion about the WiX toolset. Betreff: Re: [WiX-users] Modify MSI version Hello, I have an additional question concerning that topic. If I consider realizing my installation concept with the possibility to reconfigure my MSI packages with my tools, are there any special things I have to consider? These modifications would only go so far that custom properties would be with different values afterwards. No file changes at all. I understand, that if I sign my MSI packages myself after build, that they will get invalidated by changing the MSI database. So I would have to resign it after modification. But is there more? kind regards, Michael -Ursprüngliche Nachricht- Von: fom Forstner Michael [mailto:f...@keba.com] Gesendet: Mittwoch, 09. April 2014 10:50 An: General discussion about the WiX toolset. Betreff: Re: [WiX-users] Modify MSI version The PackageCode it was. After updating the SummaryInformation stream via code all works as expected. The background of this question: Because MSI doesn't make use of the fourth version number, I think about making use of it myself to provide minor configuration possibilities to my internal sub-customers without the actual need of writing code. (via a custom written tool). Thanks for your help. kind regards Michael -Ursprüngliche Nachricht- Von: Phil Wilson [mailto:phildgwil...@gmail.com] Gesendet: Dienstag, 08. April 2014 19:13 An: General discussion about the WiX toolset. Betreff: Re: [WiX-users] Modify MSI version You may not have changed the PackageCode - Windows Installer is sensitive to this as well as the ProductCode. --- Phil Wilson On Tue, Apr 8, 2014 at 9:32 AM, Pally Sandher pally.sand...@iesve.com wrote: Unless you also change the Upgrade table when you're poking around in your MSI with Orca, it's not going to see the 2.0.0.0 as a new package if you didn't add a MajorUpgrade element when you authored your package. See http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upg rade.html Palbinder Sandher Software Platform Engineer T:+44 (0) 141 945 8500 F:+44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: fom Forstner Michael [mailto:f...@keba.com] Sent: 08 April 2014 09:09 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Modify MSI version Hello, I'm trying to understand how MSI does decide if to use the cached package or the original package I start from. Therefore I installed one of my packages with version 1.0.0.0 . After that I opened the package with Orca and change the product version property to 2.0.0.0 and gave the product code a new GUID. My understanding until now was, that after those changes MSI should consider the new package as an upgrade while installing it. But it doesn't. Upon call the logger say's the following: [09:44:37:947]: Original package == D:\Test.msi [09:44:37:947]: Package we're running from == C:\Windows\Installer\145ea53f.msi The installation then doesn't generate an error but doesn't install the new version either. Instead it starts only reconfigurating version 1.0.0.0. (Counter check: When I install only the modified version 2.0.0.0, the correct version is registered in the system. So the change itself seems legit) Does anyone know why this is? Do I need to change more? Is it even possible? kind regards, Michael -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http
Re: [WiX-users] Modify MSI version
The PackageCode it was. After updating the SummaryInformation stream via code all works as expected. The background of this question: Because MSI doesn't make use of the fourth version number, I think about making use of it myself to provide minor configuration possibilities to my internal sub-customers without the actual need of writing code. (via a custom written tool). Thanks for your help. kind regards Michael -Ursprüngliche Nachricht- Von: Phil Wilson [mailto:phildgwil...@gmail.com] Gesendet: Dienstag, 08. April 2014 19:13 An: General discussion about the WiX toolset. Betreff: Re: [WiX-users] Modify MSI version You may not have changed the PackageCode - Windows Installer is sensitive to this as well as the ProductCode. --- Phil Wilson On Tue, Apr 8, 2014 at 9:32 AM, Pally Sandher pally.sand...@iesve.com wrote: Unless you also change the Upgrade table when you're poking around in your MSI with Orca, it's not going to see the 2.0.0.0 as a new package if you didn't add a MajorUpgrade element when you authored your package. See http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upg rade.html Palbinder Sandher Software Platform Engineer T:+44 (0) 141 945 8500 F:+44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: fom Forstner Michael [mailto:f...@keba.com] Sent: 08 April 2014 09:09 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Modify MSI version Hello, I'm trying to understand how MSI does decide if to use the cached package or the original package I start from. Therefore I installed one of my packages with version 1.0.0.0 . After that I opened the package with Orca and change the product version property to 2.0.0.0 and gave the product code a new GUID. My understanding until now was, that after those changes MSI should consider the new package as an upgrade while installing it. But it doesn't. Upon call the logger say's the following: [09:44:37:947]: Original package == D:\Test.msi [09:44:37:947]: Package we're running from == C:\Windows\Installer\145ea53f.msi The installation then doesn't generate an error but doesn't install the new version either. Instead it starts only reconfigurating version 1.0.0.0. (Counter check: When I install only the modified version 2.0.0.0, the correct version is registered in the system. So the change itself seems legit) Does anyone know why this is? Do I need to change more? Is it even possible? kind regards, Michael -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Modify MSI version
Hello, I have an additional question concerning that topic. If I consider realizing my installation concept with the possibility to reconfigure my MSI packages with my tools, are there any special things I have to consider? These modifications would only go so far that custom properties would be with different values afterwards. No file changes at all. I understand, that if I sign my MSI packages myself after build, that they will get invalidated by changing the MSI database. So I would have to resign it after modification. But is there more? kind regards, Michael -Ursprüngliche Nachricht- Von: fom Forstner Michael [mailto:f...@keba.com] Gesendet: Mittwoch, 09. April 2014 10:50 An: General discussion about the WiX toolset. Betreff: Re: [WiX-users] Modify MSI version The PackageCode it was. After updating the SummaryInformation stream via code all works as expected. The background of this question: Because MSI doesn't make use of the fourth version number, I think about making use of it myself to provide minor configuration possibilities to my internal sub-customers without the actual need of writing code. (via a custom written tool). Thanks for your help. kind regards Michael -Ursprüngliche Nachricht- Von: Phil Wilson [mailto:phildgwil...@gmail.com] Gesendet: Dienstag, 08. April 2014 19:13 An: General discussion about the WiX toolset. Betreff: Re: [WiX-users] Modify MSI version You may not have changed the PackageCode - Windows Installer is sensitive to this as well as the ProductCode. --- Phil Wilson On Tue, Apr 8, 2014 at 9:32 AM, Pally Sandher pally.sand...@iesve.com wrote: Unless you also change the Upgrade table when you're poking around in your MSI with Orca, it's not going to see the 2.0.0.0 as a new package if you didn't add a MajorUpgrade element when you authored your package. See http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upg rade.html Palbinder Sandher Software Platform Engineer T:+44 (0) 141 945 8500 F:+44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: fom Forstner Michael [mailto:f...@keba.com] Sent: 08 April 2014 09:09 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Modify MSI version Hello, I'm trying to understand how MSI does decide if to use the cached package or the original package I start from. Therefore I installed one of my packages with version 1.0.0.0 . After that I opened the package with Orca and change the product version property to 2.0.0.0 and gave the product code a new GUID. My understanding until now was, that after those changes MSI should consider the new package as an upgrade while installing it. But it doesn't. Upon call the logger say's the following: [09:44:37:947]: Original package == D:\Test.msi [09:44:37:947]: Package we're running from == C:\Windows\Installer\145ea53f.msi The installation then doesn't generate an error but doesn't install the new version either. Instead it starts only reconfigurating version 1.0.0.0. (Counter check: When I install only the modified version 2.0.0.0, the correct version is registered in the system. So the change itself seems legit) Does anyone know why this is? Do I need to change more? Is it even possible? kind regards, Michael -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Modify MSI version
Hello, I'm trying to understand how MSI does decide if to use the cached package or the original package I start from. Therefore I installed one of my packages with version 1.0.0.0 . After that I opened the package with Orca and change the product version property to 2.0.0.0 and gave the product code a new GUID. My understanding until now was, that after those changes MSI should consider the new package as an upgrade while installing it. But it doesn't. Upon call the logger say's the following: [09:44:37:947]: Original package == D:\Test.msi [09:44:37:947]: Package we're running from == C:\Windows\Installer\145ea53f.msi The installation then doesn't generate an error but doesn't install the new version either. Instead it starts only reconfigurating version 1.0.0.0. (Counter check: When I install only the modified version 2.0.0.0, the correct version is registered in the system. So the change itself seems legit) Does anyone know why this is? Do I need to change more? Is it even possible? kind regards, Michael -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Resigning MSI package
Hi, I have a question about resigning MSI packages. My scenario: I built a .NET application to handle a whole bunch of MSI packages as a complete product suite (platform). Those MSI packages hold some custom properties that are used for install/update logic and visual appearance of the product tree (child/parent). It is the case now, that we will eventually get MSI packages from some of our external suppliers. My thought was now to edit those MSI packages databases to include our custom properties to make them compatible to my application. As I understand it, this would invalidate the MSI signature. Someone in my earlier discussions mentioned that resigning of MSI packages is possible though. Can you provide me with some information of how to resign MSI packages? kind regards, Michael -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
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
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 to
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
