[WiX-users] Upgrading old installer
So I have created a nice new installer using WiX for my customer complete with nice shiny new custom bootstrapper and everyone was happy. Rejoicing in the death of their old buggy Visual Studio based installer. However I have struck a problem. There are a number of user configurable config files installed (yes I know bad idea but I had to work with this). The Component attribute is set to 144 for them which is the Permanent and NeverOverwrite. So all is fine except I upgrade the old installer (same upgradecode). So the process goes. 1.MSI sees they are there leave them alone 2.MSI Installs files. 3. Now it uninstalls using the logic of the old installer the config files have not changed (I’m guess in real life that would be odd but possible). So it uninstalls them because there was no logic to keep them in the old installer. Now I could use a new upgrade code and leave the old installer there but their is a danger then someone will manual uninstall it. (They probably would) I could use a custom action to copy the files then copy them back but that seems messy. Anyone had the same problem Thanks in advance. Craig -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-old-installer-tp7599056.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading old installer
Anyone -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-old-installer-tp7599052p7599055.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading old installer
Well unfortunately there are a lot of config files. but the simple answer is no most will be either left alone or changed by the application. The ones changed by the application i am not worried about as they will stay it's the others that have the problem. As a side note I know I don't have to set the neverovewrite. From: Jeremiahf jeremi...@gmail.com Sent: 28 January 2015 16:59 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Upgrading old installer So you want to leave the old config file there? Will your new installer configure the new config file and maintain it from there on? On Wed, Jan 28, 2015 at 8:15 AM, Kraygsoft craig.ree...@kraygsoft.com wrote: Anyone -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-old-installer-tp7599052p7599055.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- They may forget what you said but they will never forget how you made them feel. -- Anonymous -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading old installer
So you want to leave the old config file there? Will your new installer configure the new config file and maintain it from there on? On Wed, Jan 28, 2015 at 8:15 AM, Kraygsoft craig.ree...@kraygsoft.com wrote: Anyone -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-old-installer-tp7599052p7599055.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- They may forget what you said but they will never forget how you made them feel. -- Anonymous -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading Burn bootstrapper with msi
Hello everyone, I have a situation where until now I had one bootstrapper chaining several msi packages, but now I must switch to one msi instead of bootstrapper. The problem is that msi installer will not trigger the upgrade using upgrade code of the bootstrapper. I have searched through the net for some solution for this but I was unsuccessful so far. I would like to resolve this with internal mechanism for upgrade instead of doing some custom action that will uninstall the bootstrapper, is this possible? Best regards, Mihailo -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading Burn bootstrapper with msi
Windows Installer can remove the bootstrapper for you. Use the Windows Installer FindRelatedProducts action with the bootstrappers UPGRADECODE and version. -Original Message- From: Mihailo Milenković [mailto:mihailo.milenko...@pstech.rs] Sent: Monday, October 27, 2014 4:08 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading Burn bootstrapper with msi Hello everyone, I have a situation where until now I had one bootstrapper chaining several msi packages, but now I must switch to one msi instead of bootstrapper. The problem is that msi installer will not trigger the upgrade using upgrade code of the bootstrapper. I have searched through the net for some solution for this but I was unsuccessful so far. I would like to resolve this with internal mechanism for upgrade instead of doing some custom action that will uninstall the bootstrapper, is this possible? Best regards, Mihailo -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading Burn bootstrapper with msi
Hello Blaine,
I have already tried with FindRelatedProducts and RemoveExistingProducts
instead of using MajorUpgrade and UpgardeCode in product element but also with
no success.
Upgrade Id={BOOTSTRAPPER GUID}
UpgradeVersion Minimum=0.0.0.0 IncludeMinimum=yes Maximum=3.4.0.0
IncludeMaximum=no OnlyDetect=no Property=LEGACYVERSIONDETECTED /
/Upgrade
InstallExecuteSequence
AppSearch Before=LaunchConditions /
FindRelatedProducts Before=AppSearch /
RemoveExistingProducts After=InstallInitialize /
/InstallExecuteSequence
Regards,
Mihailo
-Original Message-
From: Wheeler, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
Sent: Monday, October 27, 2014 14:57
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] Upgrading Burn bootstrapper with msi
Windows Installer can remove the bootstrapper for you. Use the Windows
Installer FindRelatedProducts action with the bootstrappers UPGRADECODE and
version.
-Original Message-
From: Mihailo Milenković [mailto:mihailo.milenko...@pstech.rs]
Sent: Monday, October 27, 2014 4:08 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading Burn bootstrapper with msi
Hello everyone,
I have a situation where until now I had one bootstrapper chaining several msi
packages, but now I must switch to one msi instead of bootstrapper. The problem
is that msi installer will not trigger the upgrade using upgrade code of the
bootstrapper. I have searched through the net for some solution for this but I
was unsuccessful so far.
I would like to resolve this with internal mechanism for upgrade instead of
doing some custom action that will uninstall the bootstrapper, is this possible?
Best regards,
Mihailo
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading from Wix 3.5 to 3.8 and Visual Studio 2013
Hi all, I am working on task which includes upgrading Visual Studio 2010 to 2013 as well as upgrading WiX 3.5 to WiX 3.8. I have the basic knowledge of WiX and i am not the expertise as such. Conversion of .NET projects were successful, however in case of WiX projects conversion from 3.5 to 3.8 i have outlined the following steps: 1. Locally install WiX 3.8 2. Get latest source code from Source Control. 3. Open the solution file in Visual Studio 2013. 4. Right click on .Wixproj file and click upgrade. Now all the projects are upgraded to latest version of .Net 4.5/4.5.1. When i tried to build the solution i am getting the following error for all wix projects (below mentioned is a sample error list for reference) Error 104 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Error 105 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Error 106 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Error 107 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Error 108 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Can anyone guide me on this on how to fix the build issues. Please do the needful. -- Thanks and Regards Chetan V Dabade +91 9663967000 -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from Wix 3.5 to 3.8 and Visual Studio 2013
Hi all, I found the issue and fixed it. The issue was under each .wixproj file the value of $(WixToolPath) was referring to older version of Wix (.i.e 3.5) WixToolPath$(ProgramFiles)\Windows Installer Xml v3.5\bin\/WixToolPath I re-visited each individual projects unloaded it, edit the .wixproj file and change the value to WixToolPath$(ProgramFiles)\WiX Toolset v3.8\bin\/WixToolPath By doing this all project are able to build, but at the end i am getting the following strange issues *Error 427 The Windows Installer XML variable 'WixUICostingPopupOptOut' is declared in more than one location. Please remove one of the declarations. C:\src\wix38\src\ext\UIExtension\wixlib\Common.wxs 18 1 XInstall**Error* *430* *The Windows Installer XML variable 'WixUICostingPopupOptOut' is declared in more than one location. Please remove one of the declarations.* *C:\src\wix38\src\ext\UIExtension\wixlib\Common.wxs* *18* *1* *Installer* i scanned my whole machine but couldn't find file *Common.wxs* and in addition under Installer.wxs file there is a variable declared as: *WixVariable Id=WixUICostingPopupOptOut Value=1 Overridable=yes /* while googling i found the above mentioned error http://www.joyofsetup.com/2010/05/20/its-time-to-experiment/ and Bob has addressed on how to avoid the issue : http://www.joyofsetup.com/2010/05/28/experimental-results-part-i/ http://www.joyofsetup.com/2010/10/09/experimental-results-part-ii/ The above mentioned bug has been addressed in Wix version 3.5/3.6, i have installed Wix 3.8 (3.8.1128.0) How do i address these issues ?? Please help Thanks, Chetan On Mon, Jul 28, 2014 at 2:24 PM, Chetan Dabade chetandab...@gmail.com wrote: Hi all, I am working on task which includes upgrading Visual Studio 2010 to 2013 as well as upgrading WiX 3.5 to WiX 3.8. I have the basic knowledge of WiX and i am not the expertise as such. Conversion of .NET projects were successful, however in case of WiX projects conversion from 3.5 to 3.8 i have outlined the following steps: 1. Locally install WiX 3.8 2. Get latest source code from Source Control. 3. Open the solution file in Visual Studio 2013. 4. Right click on .Wixproj file and click upgrade. Now all the projects are upgraded to latest version of .Net 4.5/4.5.1. When i tried to build the solution i am getting the following error for all wix projects (below mentioned is a sample error list for reference) Error 104 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Error 105 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Error 106 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Error 107 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Error 108 The specified task executable location C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe is invalid. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets 2066 Can anyone guide me on this on how to fix the build issues. Please do the needful. -- Thanks and Regards Chetan V Dabade +91 9663967000 -- Thanks and Regards Chetan V Dabade +91 9663967000 -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from Wix 3.5 to 3.8 and Visual Studio 2013
On 28-Jul-14 08:51, Chetan Dabade wrote: i scanned my whole machine but couldn't find file *Common.wxs* and in addition under Installer.wxs file there is a variable declared as: *WixVariable Id=WixUICostingPopupOptOut Value=1 Overridable=yes /* while googling i found the above mentioned error http://www.joyofsetup.com/2010/05/20/its-time-to-experiment/ and Bob has addressed on how to avoid the issue : http://www.joyofsetup.com/2010/05/28/experimental-results-part-i/ http://www.joyofsetup.com/2010/10/09/experimental-results-part-ii/ The above mentioned bug has been addressed in Wix version 3.5/3.6, i have installed Wix 3.8 (3.8.1128.0) As I said at http://www.joyofsetup.com/2010/10/09/experimental-results-part-ii/: If you've built a customized dialog set, remove the WixUICostingPopupOptOut WiX variable definition from your dialog set fragment or you're likely to get an error message at link time: The Windows Installer XML variable 'WixUICostingPopupOptOut' is declared in more than one location. Please remove one of the declarations. -- sig://boB http://joyofsetup.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
what if at build time I change the name of the MSI to be the same as the original MSI's name and use the same upgrade code? Would that work ? Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079p7595124.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
I do not have direct experience with this issue, but I suspect the thing to do is to leave the new package name as is, but rather author multiple upgrade codes to also remove the old product. http://www.joyofsetup.com/2008/09/07/hint-be-generous-with-upgrade-codes/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079p7595125.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
Thanks I have add the older MSI's upgrade code to the upgrade table and will test that tomorrow :) Cheers, STeve -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: June-09-14 4:46 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading... I do not have direct experience with this issue, but I suspect the thing to do is to leave the new package name as is, but rather author multiple upgrade codes to also remove the old product. http://www.joyofsetup.com/2008/09/07/hint-be-generous-with-upgrade-codes/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079p7595125.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading...
I have a quick question... We released 4.2.0.x about 3 months ago. and our Services MSI was named TITUS_Services_Setup_x86 we shipped only the 32 bit services with our Client installer with a different GUID and upgrade code. now we have changed our Services MSI to TITUS_Client_Services_x86 and TITUS_Client_Services_x64 with different GUID and upgrade code and the version is now 14.4.5.x (our client installer now installs the Services based on the bitness of the OS) Because the name of the MSI has changed, the upgrade code is different and the version number is completely different will an upgrade be seamless? or does it make sense to tell clients to uninstall 4.2.0.x and then install 14.4.5.x? thanks, Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079.html Sent from the wix-users mailing list archive at Nabble.com. -- 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] Upgrading...
Your Second Option is Best, if not you will have a side by side install Quoting Steve-Ogilvie steven.ogil...@titus.com: I have a quick question... We released 4.2.0.x about 3 months ago. and our Services MSI was named TITUS_Services_Setup_x86 we shipped only the 32 bit services with our Client installer with a different GUID and upgrade code. now we have changed our Services MSI to TITUS_Client_Services_x86 and TITUS_Client_Services_x64 with different GUID and upgrade code and the version is now 14.4.5.x (our client installer now installs the Services based on the bitness of the OS) Because the name of the MSI has changed, the upgrade code is different and the version number is completely different will an upgrade be seamless? or does it make sense to tell clients to uninstall 4.2.0.x and then install 14.4.5.x? thanks, Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079.html Sent from the wix-users mailing list archive at Nabble.com. -- 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
[WiX-users] Upgrading a package previously intsalled via a burn bundle with a msi.
Hey folks, Hello, was wondering if I could get some thoughts on this... I've been asked to provide a bundled exe created in burn and a MSI for our product... The idea being that clients will generally use the exe which will install the our msi and VSTO. The standalone MSI I've been asked to provide in case a client wants to do a network deployment. My concern here is that a client receives a version 1 and then decides they want to upgrade via a network deployment when we release version 2? Is this a common scenario? And is there a recommended approach for accommodating it if so? Thanks, James -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading a multiple instance install
Everyone, I have a multiple instance install that I am working on and ran into an issue doing upgrade testing. It looks like all instances are removed when one of the instances is upgraded. This looks to be because WIX does not allow for the UpgradeCode to be modified in the instance element. I found the following discussion that hints that there is a feature request to add this support but I have not been able to find the reference as of yet. http://sourceforge.net/mailarchive/message.php?msg_id=28034637 To support this it looks like I am going to have to get the build process to manually generate the required instance transforms. Does anyone have any incite on a better way to get instance transforms working correctly without a lot of workarounds? Thank you, MAT SKILDUM SR PPRINCIPAL ENGINEER mathew.skil...@aspect.commailto:mathew.skil...@aspect.com aspect.comhttp://www.aspect.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading a multiple instance install
See https://wix.codeplex.com/SourceControl/network/forks/jchoover/Wix?branch=instances and/or https://wix.codeplex.com/SourceControl/network/forks/patoshea/InstanceTransforms/contribution/4700. Both are essentially the same reapplication of my prior contribution setup for 3.8. I'll submit my pull request once the documentation has been updated. -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Monday, May 13, 2013 11:16 AM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) Subject: [WiX-users] Upgrading a multiple instance install Everyone, I have a multiple instance install that I am working on and ran into an issue doing upgrade testing. It looks like all instances are removed when one of the instances is upgraded. This looks to be because WIX does not allow for the UpgradeCode to be modified in the instance element. I found the following discussion that hints that there is a feature request to add this support but I have not been able to find the reference as of yet. http://sourceforge.net/mailarchive/message.php?msg_id=28034637 To support this it looks like I am going to have to get the build process to manually generate the required instance transforms. Does anyone have any incite on a better way to get instance transforms working correctly without a lot of workarounds? Thank you, MAT SKILDUM SR PPRINCIPAL ENGINEER mathew.skil...@aspect.commailto:mathew.skil...@aspect.com aspect.comhttp://www.aspect.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading an Install fails to downgrade a 3rd party library
Hiya all,
Similar to this question on StackOverflow
(http://stackoverflow.com/questions/4227456/windows-installer-deletes-versioned-file-during-product-upgrade-instead-of-down)
I've got a new version of an install that accesses an old version of a 3rd
party library.
Previous version (1.0) references Apex3D.exe version 3.0.7
New version (1.1) references Apex3D.exe version 2.96
This is a downgrade by a 3rd party, and we want the upgrade from v1.0 to v1.1
to replace Apex version 3.0.7 with Apex version 2.96.
It doesn't. It deletes version 3.0.7 and doesn't install version 2.96.
Relevant bits of the .wxs file:
MajorUpgrade DowngradeErrorMessage=Blah.
AllowDowngrades=no AllowSameVersionUpgrades=yes/
Component Id=cmpB42F5061E6D22CE98B0C7438BC306A32
Guid={CD7EE807-D48D-48FF-AE48-C53382818ABD}
File Id=fil89806A85680A72004AF8F43D0B163260 KeyPath=yes
Source=!(wix.ToolsDir)\Apex3D.exe /
/Component
If I add the Schedule=afterInstallExecute attribute to the MajorUpgrade node
then the 3.0.7 version remains (instead of the version I want). I've also tried
changing the Component Id and GUID attribute and the File Id attribute without
it helping, and even adding a RemoveFile node before the File node in the
component (as described here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-wix-how-to-always-overwrite-a-file-td6904118.html).
The relevant bits of the verbose msiexec log are:
MSI (c) (E0:60) [16:52:35:610]: Note: 1: 2228 2: 3: MsiAssembly 4: SELECT
`MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`,
`MsiAssembly`.`File_Manifest`, `Component`.`KeyPath` FROM `MsiAssembly`,
`Component` WHERE `MsiAssembly`.`Component_` = `Component`.`Component` AND
`MsiAssembly`.`Component_` = ?
MSI (c) (E0:60) [16:52:35:770]: Disallowing installation of component:
{79D3B0FF-D062-4452-9351-1A90089709AA} since the same component with higher
versioned keyfile exists
Action ended 16:52:43: CostFinalize. Return value 1.
MSI (c) (E0:60) [16:52:43:354]: Doing action: MigrateFeatureStates
Action start 16:52:43: MigrateFeatureStates.
MSI (c) (E0:60) [16:52:43:355]: Migrating feature settings from product(s)
'{01C34727-654C-4F0D-9EFB-29ABC365E4BD}'
MSI (c) (E0:60) [16:52:43:358]: MigrateFeatureStates: based on existing
product, setting feature 'ApplicationFeature' to 'Local' state.
MSI (s) (04:60) [16:53:01:572]: Executing op:
ComponentRegister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},KeyPath=C:\Program
Files (x86)\...\Apex3D.exe,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
...
MSI (s) (04:60) [16:52:58:374]: Disallowing installation of component:
{79D3B0FF-D062-4452-9351-1A90089709AA} since the same component with higher
versioned keyfile exists
...
MSI (s) (04:34) [16:52:59:434]: Executing op:
UnregisterSharedComponentProvider(Component={79D3B0FF-D062-4452-9351-1A90089709AA},ProductCode={01C34727-654C-4F0D-9EFB-29ABC365E4BD})
MSI (s) (04:34) [16:52:59:434]: Executing op:
ComponentUnregister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},,BinaryType=0,)
...
MSI (s) (04:34) [16:53:00:706]: Executing op:
FileRemove(,FileName=Apex3D.exe,,ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA})
...
MSI (s) (04:60) [16:53:01:572]: Executing op:
ComponentRegister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},KeyPath=C:\Program
Files (x86)\...\Apex3D.exe,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
Any ideas how I can get this to work without faking the file version to be
higher than 3.0.7? I don't want to have to remember to update the fake version
number every time with release the product.
Cheers,
Jack
--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party library
You could try scheduling remove existing products earlier, after
InstallInitialize.
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 3:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading an Install fails to downgrade a 3rd party library
Hiya all,
Similar to this question on StackOverflow
(http://stackoverflow.com/questions/4227456/windows-installer-deletes-versioned-file-during-product-upgrade-instead-of-down)
I've got a new version of an install that accesses an old version of a 3rd
party library.
Previous version (1.0) references Apex3D.exe version 3.0.7 New version (1.1)
references Apex3D.exe version 2.96
This is a downgrade by a 3rd party, and we want the upgrade from v1.0 to v1.1
to replace Apex version 3.0.7 with Apex version 2.96.
It doesn't. It deletes version 3.0.7 and doesn't install version 2.96.
Relevant bits of the .wxs file:
MajorUpgrade DowngradeErrorMessage=Blah.
AllowDowngrades=no AllowSameVersionUpgrades=yes/
Component Id=cmpB42F5061E6D22CE98B0C7438BC306A32
Guid={CD7EE807-D48D-48FF-AE48-C53382818ABD}
File Id=fil89806A85680A72004AF8F43D0B163260 KeyPath=yes
Source=!(wix.ToolsDir)\Apex3D.exe /
/Component
If I add the Schedule=afterInstallExecute attribute to the MajorUpgrade node
then the 3.0.7 version remains (instead of the version I want). I've also tried
changing the Component Id and GUID attribute and the File Id attribute without
it helping, and even adding a RemoveFile node before the File node in the
component (as described here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-wix-how-to-always-overwrite-a-file-td6904118.html).
The relevant bits of the verbose msiexec log are:
MSI (c) (E0:60) [16:52:35:610]: Note: 1: 2228 2: 3: MsiAssembly 4: SELECT
`MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`,
`MsiAssembly`.`File_Manifest`, `Component`.`KeyPath` FROM `MsiAssembly`,
`Component` WHERE `MsiAssembly`.`Component_` = `Component`.`Component` AND
`MsiAssembly`.`Component_` = ?
MSI (c) (E0:60) [16:52:35:770]: Disallowing installation of component:
{79D3B0FF-D062-4452-9351-1A90089709AA} since the same component with higher
versioned keyfile exists Action ended 16:52:43: CostFinalize. Return value 1.
MSI (c) (E0:60) [16:52:43:354]: Doing action: MigrateFeatureStates Action start
16:52:43: MigrateFeatureStates.
MSI (c) (E0:60) [16:52:43:355]: Migrating feature settings from product(s)
'{01C34727-654C-4F0D-9EFB-29ABC365E4BD}'
MSI (c) (E0:60) [16:52:43:358]: MigrateFeatureStates: based on existing
product, setting feature 'ApplicationFeature' to 'Local' state.
MSI (s) (04:60) [16:53:01:572]: Executing op:
ComponentRegister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},KeyPath=C:\Program
Files (x86)\...\Apex3D.exe,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
...
MSI (s) (04:60) [16:52:58:374]: Disallowing installation of component:
{79D3B0FF-D062-4452-9351-1A90089709AA} since the same component with higher
versioned keyfile exists ...
MSI (s) (04:34) [16:52:59:434]: Executing op:
UnregisterSharedComponentProvider(Component={79D3B0FF-D062-4452-9351-1A90089709AA},ProductCode={01C34727-654C-4F0D-9EFB-29ABC365E4BD})
MSI (s) (04:34) [16:52:59:434]: Executing op:
ComponentUnregister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},,BinaryType=0,)
...
MSI (s) (04:34) [16:53:00:706]: Executing op:
FileRemove(,FileName=Apex3D.exe,,ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA})
...
MSI (s) (04:60) [16:53:01:572]: Executing op:
ComponentRegister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},KeyPath=C:\Program
Files (x86)\...\Apex3D.exe,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
Any ideas how I can get this to work without faking the file version to be
higher than 3.0.7? I don't want to have to remember to update the fake version
number every time with release the product.
Cheers,
Jack
--
Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in
Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game on Steam. $5K
grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
WiX
Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party library
Hiya Jacob,
It's currently the default, which is afterInstallValidate which is even earlier
I think.
Cheers,
Jack
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 28 March 2013 14:24
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
You could try scheduling remove existing products earlier, after
InstallInitialize.
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 3:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading an Install fails to downgrade a 3rd party library
Hiya all,
Similar to this question on StackOverflow
(http://stackoverflow.com/questions/4227456/windows-installer-deletes-versioned-file-during-product-upgrade-instead-of-down)
I've got a new version of an install that accesses an old version of a 3rd
party library.
Previous version (1.0) references Apex3D.exe version 3.0.7 New version (1.1)
references Apex3D.exe version 2.96
This is a downgrade by a 3rd party, and we want the upgrade from v1.0 to v1.1
to replace Apex version 3.0.7 with Apex version 2.96.
It doesn't. It deletes version 3.0.7 and doesn't install version 2.96.
Relevant bits of the .wxs file:
MajorUpgrade DowngradeErrorMessage=Blah.
AllowDowngrades=no AllowSameVersionUpgrades=yes/
Component Id=cmpB42F5061E6D22CE98B0C7438BC306A32
Guid={CD7EE807-D48D-48FF-AE48-C53382818ABD}
File Id=fil89806A85680A72004AF8F43D0B163260 KeyPath=yes
Source=!(wix.ToolsDir)\Apex3D.exe /
/Component
If I add the Schedule=afterInstallExecute attribute to the MajorUpgrade node
then the 3.0.7 version remains (instead of the version I want). I've also tried
changing the Component Id and GUID attribute and the File Id attribute without
it helping, and even adding a RemoveFile node before the File node in the
component (as described here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-wix-how-to-always-overwrite-a-file-td6904118.html).
The relevant bits of the verbose msiexec log are:
MSI (c) (E0:60) [16:52:35:610]: Note: 1: 2228 2: 3: MsiAssembly 4: SELECT
`MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`,
`MsiAssembly`.`File_Manifest`, `Component`.`KeyPath` FROM `MsiAssembly`,
`Component` WHERE `MsiAssembly`.`Component_` = `Component`.`Component` AND
`MsiAssembly`.`Component_` = ?
MSI (c) (E0:60) [16:52:35:770]: Disallowing installation of component:
{79D3B0FF-D062-4452-9351-1A90089709AA} since the same component with higher
versioned keyfile exists Action ended 16:52:43: CostFinalize. Return value 1.
MSI (c) (E0:60) [16:52:43:354]: Doing action: MigrateFeatureStates Action start
16:52:43: MigrateFeatureStates.
MSI (c) (E0:60) [16:52:43:355]: Migrating feature settings from product(s)
'{01C34727-654C-4F0D-9EFB-29ABC365E4BD}'
MSI (c) (E0:60) [16:52:43:358]: MigrateFeatureStates: based on existing
product, setting feature 'ApplicationFeature' to 'Local' state.
MSI (s) (04:60) [16:53:01:572]: Executing op:
ComponentRegister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},KeyPath=C:\Program
Files (x86)\...\Apex3D.exe,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
...
MSI (s) (04:60) [16:52:58:374]: Disallowing installation of component:
{79D3B0FF-D062-4452-9351-1A90089709AA} since the same component with higher
versioned keyfile exists ...
MSI (s) (04:34) [16:52:59:434]: Executing op:
UnregisterSharedComponentProvider(Component={79D3B0FF-D062-4452-9351-1A90089709AA},ProductCode={01C34727-654C-4F0D-9EFB-29ABC365E4BD})
MSI (s) (04:34) [16:52:59:434]: Executing op:
ComponentUnregister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},,BinaryType=0,)
...
MSI (s) (04:34) [16:53:00:706]: Executing op:
FileRemove(,FileName=Apex3D.exe,,ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA})
...
MSI (s) (04:60) [16:53:01:572]: Executing op:
ComponentRegister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},KeyPath=C:\Program
Files (x86)\...\Apex3D.exe,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
Any ideas how I can get this to work without faking the file version to be
higher than 3.0.7? I don't want to have to remember to update the fake version
number every time with release the product.
Cheers,
Jack
--
Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in
Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game on Steam. $5K
grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party library
I don't like any of these per say, but just throwing some ideas out for you to
ponder/try.
1) Rename the file and have it in a different component
2) messing around with REINSTALLMODE to force overwrites. (Would be very bad
if your MSI installed any shared components)
3) I see a hackish approach listed as an answer
http://stackoverflow.com/questions/14122136/how-can-i-make-sure-a-downgraded-library-is-installed-by-my-msi
where one tweaks the MSI's File table to lie about the version but I am not
sure that I like that idea. (Also seems install shield does this
http://stackoverflow.com/questions/5542841/how-to-force-file-replacement-on-msi-upgrade
)
4)A possible approach from
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/downgrading-a-file-during-an-upgrade-td3951448.html
would be to
Component Id=cmpB42F5061E6D22CE98B0C7438BC306A32
Guid={CD7EE807-D48D-48FF-AE48-C53382818ABD}
File Id=fil89806A85680A72004AF8F43D0B163260 KeyPath=yes
Source=!(wix.ToolsDir)\Apex3D.exe /
/Component
Component Id=R_cmpB42F5061E6D22CE98B0C7438BC306A32 Guid=*
Transitive=yes
RemoveFile Id=R_cmpB42F5061E6D22CE98B0C7438BC306A32 Name=
Apex3D.exe On=install/
Condition?cmpB42F5061E6D22CE98B0C7438BC306A32=3 AND NOT
PATCH/Condition
/Component
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 9:38 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
Hiya Jacob,
It's currently the default, which is afterInstallValidate which is even earlier
I think.
Cheers,
Jack
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 28 March 2013 14:24
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
You could try scheduling remove existing products earlier, after
InstallInitialize.
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 3:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading an Install fails to downgrade a 3rd party library
Hiya all,
Similar to this question on StackOverflow
(http://stackoverflow.com/questions/4227456/windows-installer-deletes-versioned-file-during-product-upgrade-instead-of-down)
I've got a new version of an install that accesses an old version of a 3rd
party library.
Previous version (1.0) references Apex3D.exe version 3.0.7 New version (1.1)
references Apex3D.exe version 2.96
This is a downgrade by a 3rd party, and we want the upgrade from v1.0 to v1.1
to replace Apex version 3.0.7 with Apex version 2.96.
It doesn't. It deletes version 3.0.7 and doesn't install version 2.96.
Relevant bits of the .wxs file:
MajorUpgrade DowngradeErrorMessage=Blah.
AllowDowngrades=no AllowSameVersionUpgrades=yes/
Component Id=cmpB42F5061E6D22CE98B0C7438BC306A32
Guid={CD7EE807-D48D-48FF-AE48-C53382818ABD}
File Id=fil89806A85680A72004AF8F43D0B163260 KeyPath=yes
Source=!(wix.ToolsDir)\Apex3D.exe /
/Component
If I add the Schedule=afterInstallExecute attribute to the MajorUpgrade node
then the 3.0.7 version remains (instead of the version I want). I've also tried
changing the Component Id and GUID attribute and the File Id attribute without
it helping, and even adding a RemoveFile node before the File node in the
component (as described here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-wix-how-to-always-overwrite-a-file-td6904118.html).
The relevant bits of the verbose msiexec log are:
MSI (c) (E0:60) [16:52:35:610]: Note: 1: 2228 2: 3: MsiAssembly 4: SELECT
`MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`,
`MsiAssembly`.`File_Manifest`, `Component`.`KeyPath` FROM `MsiAssembly`,
`Component` WHERE `MsiAssembly`.`Component_` = `Component`.`Component` AND
`MsiAssembly`.`Component_` = ?
MSI (c) (E0:60) [16:52:35:770]: Disallowing installation of component:
{79D3B0FF-D062-4452-9351-1A90089709AA} since the same component with higher
versioned keyfile exists Action ended 16:52:43: CostFinalize. Return value 1.
MSI (c) (E0:60) [16:52:43:354]: Doing action: MigrateFeatureStates Action start
16:52:43: MigrateFeatureStates.
MSI (c) (E0:60) [16:52:43:355]: Migrating feature settings from product(s)
'{01C34727-654C-4F0D-9EFB-29ABC365E4BD}'
MSI (c) (E0:60) [16:52:43:358]: MigrateFeatureStates: based on existing
product, setting feature 'ApplicationFeature' to 'Local' state.
MSI (s) (04:60) [16:53:01:572]: Executing op:
ComponentRegister(ComponentId={79D3B0FF-D062-4452-9351-1A90089709AA},KeyPath=C:\Program
Files (x86)\...\Apex3D.exe,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
...
MSI (s) (04:60) [16:52:58:374
Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party library
Hiya Jacob,
Yeah, I went with number one in the end, two was too dangerous, three sounded
like a maintenance nightmare (seeing as the 3rd party dll is likely to change
again in the future) and I couldn't get four to work.
Cheers,
Jack
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 28 March 2013 15:42
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
I don't like any of these per say, but just throwing some ideas out for you to
ponder/try.
1) Rename the file and have it in a different component
2) messing around with REINSTALLMODE to force overwrites. (Would be very bad
if your MSI installed any shared components)
3) I see a hackish approach listed as an answer
http://stackoverflow.com/questions/14122136/how-can-i-make-sure-a-downgraded-library-is-installed-by-my-msi
where one tweaks the MSI's File table to lie about the version but I am not
sure that I like that idea. (Also seems install shield does this
http://stackoverflow.com/questions/5542841/how-to-force-file-replacement-on-msi-upgrade
) 4)A possible approach from
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/downgrading-a-file-during-an-upgrade-td3951448.html
would be to
Component Id=cmpB42F5061E6D22CE98B0C7438BC306A32
Guid={CD7EE807-D48D-48FF-AE48-C53382818ABD}
File Id=fil89806A85680A72004AF8F43D0B163260 KeyPath=yes
Source=!(wix.ToolsDir)\Apex3D.exe /
/Component
Component Id=R_cmpB42F5061E6D22CE98B0C7438BC306A32 Guid=*
Transitive=yes
RemoveFile Id=R_cmpB42F5061E6D22CE98B0C7438BC306A32 Name=
Apex3D.exe On=install/
Condition?cmpB42F5061E6D22CE98B0C7438BC306A32=3 AND NOT
PATCH/Condition
/Component
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 9:38 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
Hiya Jacob,
It's currently the default, which is afterInstallValidate which is even earlier
I think.
Cheers,
Jack
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 28 March 2013 14:24
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
You could try scheduling remove existing products earlier, after
InstallInitialize.
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 3:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading an Install fails to downgrade a 3rd party library
Hiya all,
Similar to this question on StackOverflow
(http://stackoverflow.com/questions/4227456/windows-installer-deletes-versioned-file-during-product-upgrade-instead-of-down)
I've got a new version of an install that accesses an old version of a 3rd
party library.
Previous version (1.0) references Apex3D.exe version 3.0.7 New version (1.1)
references Apex3D.exe version 2.96
This is a downgrade by a 3rd party, and we want the upgrade from v1.0 to v1.1
to replace Apex version 3.0.7 with Apex version 2.96.
It doesn't. It deletes version 3.0.7 and doesn't install version 2.96.
Relevant bits of the .wxs file:
MajorUpgrade DowngradeErrorMessage=Blah.
AllowDowngrades=no AllowSameVersionUpgrades=yes/
Component Id=cmpB42F5061E6D22CE98B0C7438BC306A32
Guid={CD7EE807-D48D-48FF-AE48-C53382818ABD}
File Id=fil89806A85680A72004AF8F43D0B163260 KeyPath=yes
Source=!(wix.ToolsDir)\Apex3D.exe /
/Component
If I add the Schedule=afterInstallExecute attribute to the MajorUpgrade node
then the 3.0.7 version remains (instead of the version I want). I've also tried
changing the Component Id and GUID attribute and the File Id attribute without
it helping, and even adding a RemoveFile node before the File node in the
component (as described here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-wix-how-to-always-overwrite-a-file-td6904118.html).
The relevant bits of the verbose msiexec log are:
MSI (c) (E0:60) [16:52:35:610]: Note: 1: 2228 2: 3: MsiAssembly 4: SELECT
`MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`,
`MsiAssembly`.`File_Manifest`, `Component`.`KeyPath` FROM `MsiAssembly`,
`Component` WHERE `MsiAssembly`.`Component_` = `Component`.`Component` AND
`MsiAssembly`.`Component_` = ?
MSI (c) (E0:60) [16:52:35:770]: Disallowing installation of component:
{79D3B0FF-D062-4452-9351-1A90089709AA} since the same component with higher
versioned keyfile exists Action ended 16:52:43: CostFinalize. Return value 1.
MSI (c) (E0:60) [16:52:43:354]: Doing action: MigrateFeatureStates Action start
16:52:43: MigrateFeatureStates.
MSI (c
Re: [WiX-users] upgrading from 64-bit to 32-bit product leavesfiles behind
INI file ? Has this file changed since installed ? Are the modified and
created dates still the same ? Any files modified after installation are
assumed to be data that needs to be kept, and are not uninstalled. You'd need
an explicit RemoveFile to remove it. Ideally, don't install any config
files - generate them in the application from defaults if they aren't
present.
-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: 19 September 2012 20:04
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] upgrading from 64-bit to 32-bit product leavesfiles
behind
Bob Arnson wrote:
Benjamin Kaduk wrote:
I'm really confused by this behavior, and don't know where to look
further.
The verbose upgrade log. It will tell you why MSI decided to leave a
ile behind.
The problem is, as far as I can tell from the verbose upgrade log, MSI does
not think it is leaving anything behind.
There are some number of lines Disallowing uninstallation of component
{GUID} since another client exists, but looking at the MSI in orca, those
components all seem to be part of the C runtime, with the exception of my INI
file which is staying at the same location.
Is there some other string that I should be looking for? I have read the
entire log, but admit that I do not fully understand some parts of it.
-Ben Kaduk
-
-
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will
include endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires
that you delete it without acting upon or copying any of its contents, and we
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY,
UK.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] upgrading from 64-bit to 32-bit product leaves files behind
On Tue, Sep 18, 2012 at 8:17 PM, Bob Arnson b...@joyofsetup.com wrote: On 18-Sep-12 16:24, Benjamin Kaduk wrote: I'm really confused by this behavior, and don't know where to look further. The verbose upgrade log. It will tell you why MSI decided to leave a file behind. If it decided to do so. It could also be that it doesn't know where the 64-bit Program Files folder is when started from a 32-bit context, so it is unable to locate and remove the file. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] upgrading from 64-bit to 32-bit product leaves files behind
Bob Arnson wrote:
Benjamin Kaduk wrote:
I'm really confused by this behavior, and don't know where to look
further.
The verbose upgrade log. It will tell you why MSI decided to leave a
ile behind.
The problem is, as far as I can tell from the verbose upgrade log, MSI
does not think it is leaving anything behind.
There are some number of lines Disallowing uninstallation of component
{GUID} since another client exists, but looking at the MSI in orca, those
components all seem to be part of the C runtime, with the exception of my
INI file which is staying at the same location.
Is there some other string that I should be looking for? I have read the
entire log, but admit that I do not fully understand some parts of it.
-Ben Kaduk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] upgrading from 64-bit to 32-bit product leaves files behind
Hi all, I've got a product that has historically been 32-bit only but has since gained a 64-bit installer. I still have to distribute both 32- and 64-bit versions (if only to support 32-bit systems as well as 64). I don't want to allow both a 32-bit and a 64-bit version to be installed side-by-side, since the 64-bit package provides the 32-bit libraries. In particular, I want to enforce this at upgrade/installation time, so a new 64-bit package should upgrade an old 32-bit package; it also seems natural that a new 32-bit package would upgrade an old 64-bit package (even though I can't think of a reason someone would want to do that). To effect this behavior, we have different UpgradeCodes for the 32- and 64-bit versions, and within the Product element I have Upgrade elements for both the different UpgradeCodes. This works great for the 32-64-bit upgrade, but the behavior in the 64-32-bit upgrade is harder for me to explain. In this case, the installer GUI does not present me with the major upgrade logic (that is, Uninstall previous versions) that I see in the other upgrade scenarios on my checklist. If I look at the verbose msiexec log for the upgrade, though, the RemoveExistingProducts action does seem to get run, and the old package is unregistered (it no longer shows up in the Programs and Features control panel item). Yet, the files in Program Files are not removed! We have RemoveExistingFiles sequenced as After=InstallValidate, which by my reading means that the old version should be completely uninstalled before anything from the new version gets installed. I'm really confused by this behavior, and don't know where to look further. For completeness, I'll mention that I'm using WiX 3.5, the RemoveExistingProducts element is conditional on both (Not Installed) and one (or more) of the upgrades having been detected, and we do not set a 'secure' attribute on the property element used to detect the upgrade case (as is recommended at, e.g., http://stackoverflow.com/questions/114165/how-to-implement-wix-installer-upgrade ). Thanks, Ben Kaduk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] upgrading from 64-bit to 32-bit product leaves files behind
On 18-Sep-12 16:24, Benjamin Kaduk wrote: I'm really confused by this behavior, and don't know where to look further. The verbose upgrade log. It will tell you why MSI decided to leave a file behind. -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading to Burn [list of steps to take]
Hello all, We already have a big size msi for our product and it supports installation of various features. Now, with Wix3.6 onwards, we want to use Burn in our build stage. My main concern before moving to Burn is that : - how would I know if my current MSI needs Burn supported functionality or not ? - Can burn only help in checking the pre-requisites of an installation and chaining of smaller MSI s ? - What other questions should I ask myself if I want to move from old MSI generation (using Wix3.5) to a new process of generation using Burn ? If anyone experienced with Burn could help me answering such queries, that would be grateful. Thanks Vivek -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-to-Burn-list-of-steps-to-take-tp7580375.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading to Burn [list of steps to take]
The out of the box bootstrappers provided by Wix currently doesn't have a feature tree to drive the MSI's. You could show your MSI UI, but that would deter from the single unified installation experience. If you have a single MSI that has no prerequisites then using burn would only allow you for a more advanced user experience. If you have prerequisites and would like a unified installation process, then the most common direction would be to generate a custom bootstrapper to allow for feature selection, and store those features in variables and then use the burn engine to pass those variables to your MSI. If your MSI is getting overly large, you could also consider using multiple smaller MSI's and conditionally install them based on the feature tree selection. Writing a custom bootstrapper is not heavily documented, however there is both the WixSTDBA (Native C++) and Wix's own BA (written in C#) as examples of where one could start. Jacob -Original Message- From: vchauras [mailto:vivekchauras...@gmail.com] Sent: Friday, September 07, 2012 5:37 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading to Burn [list of steps to take] Hello all, We already have a big size msi for our product and it supports installation of various features. Now, with Wix3.6 onwards, we want to use Burn in our build stage. My main concern before moving to Burn is that : - how would I know if my current MSI needs Burn supported functionality or not ? - Can burn only help in checking the pre-requisites of an installation and chaining of smaller MSI s ? - What other questions should I ask myself if I want to move from old MSI generation (using Wix3.5) to a new process of generation using Burn ? If anyone experienced with Burn could help me answering such queries, that would be grateful. Thanks Vivek -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-to-Burn-list-of-steps-to-take-tp7580375.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading one of multiple installed instances, round 2
This post is a follow-up to my previous post(s) in this forum, wherein I've been trying to figure out a way to reliably upgrade a single instance of a multiple-instance installation. I had determined to try again to set up the installation to do a major upgrade, but it appears I have failed (again). The issue is this: Once a given instance of a multiple-instance installation has been installed, there does not seem to be a way to launch the installation *again* (for that instance) other than in maintenance or uninstall mode. I've tried many different permutations of command lines, but the typical error message is Invalid command line argument. Consult the Windows Installer SDK for detailed command line help. Now I suppose that this error message is trying to tell me (in a very obtuse way) that I can't install the same instance twice. On the other hand, this error message comes up even after changing the version and product code of the installation package. At that point, how does windows installer associate the new installation with the old? Perhaps if I could unravel that mystery, this whole thing would come together. At this point, I'd be inclined to believe that multiple-instance installation + major upgrade simply isn't possible, but it seems like some of you have figured this out. What are you using for a command-line when launching a new version of the installation? Thanks much. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading one of multiple installed instances, round 2
Hi Daniel With a Major Upgrade you are essentially installing a new product and uninstalling an old one, so I found the commandline needed the MSINEWINSTANCE=1 set for upgrading the instance. Also try searching the Wix-Users email archive as there are some very good emails on how people have solved the different issues that come up. Michael -Original Message- From: Daniel Pratt [mailto:colorblind...@gmail.com] Sent: Thursday, 15 September 2011 9:12 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Upgrading one of multiple installed instances, round 2 This post is a follow-up to my previous post(s) in this forum, wherein I've been trying to figure out a way to reliably upgrade a single instance of a multiple-instance installation. I had determined to try again to set up the installation to do a major upgrade, but it appears I have failed (again). The issue is this: Once a given instance of a multiple-instance installation has been installed, there does not seem to be a way to launch the installation *again* (for that instance) other than in maintenance or uninstall mode. I've tried many different permutations of command lines, but the typical error message is Invalid command line argument. Consult the Windows Installer SDK for detailed command line help. Now I suppose that this error message is trying to tell me (in a very obtuse way) that I can't install the same instance twice. On the other hand, this error message comes up even after changing the version and product code of the installation package. At that point, how does windows installer associate the new installation with the old? Perhaps if I could unravel that mystery, this whole thing would come together. At this point, I'd be inclined to believe that multiple-instance installation + major upgrade simply isn't possible, but it seems like some of you have figured this out. What are you using for a command-line when launching a new version of the installation? Thanks much. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading one of multiple installed instances, round 2
On 14-Sep-11 19:12, Daniel Pratt wrote: uninstall mode. I've tried many different permutations of command lines, but the typical error message is Invalid command line argument. Consult the Windows Installer SDK for detailed command line help. Now I suppose that this error message is trying to tell me (in a very obtuse way) that I can't install the same instance twice. On the other hand, this I wouldn't assume that; MSI has a bunch of initialization errors that would let it be more specific. Can you post some examples of command lines that give that message? -- sig://boB http://joyofsetup.com/ -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading one of multiple installed instances, round 2
On Wed, Sep 14, 2011 at 7:46 PM, Bob Arnson b...@joyofsetup.com wrote: On 14-Sep-11 19:12, Daniel Pratt wrote: uninstall mode. I've tried many different permutations of command lines, but the typical error message is Invalid command line argument. Consult the Windows Installer SDK for detailed command line help. Now I suppose that this error message is trying to tell me (in a very obtuse way) that I can't install the same instance twice. On the other hand, this I wouldn't assume that; MSI has a bunch of initialization errors that would let it be more specific. Can you post some examples of command lines that give that message? -- sig://boB http://joyofsetup.com/ I figured out what stupid thing I was doing. Apologies for the false alarm. -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] upgrading custom actions to be data driven
Hi: I'm currently in the process of upgrading my custom actions to be data driven. In the current implementation of the msi I'm using properties to enable/disable feature visibility. Is there a way to do this from a table given that what was about 30 properties are now going to be entries in a custom table. Or, within my new custom action should I set the relevant column in the feature table. Also, is there a way to make a column in a table the installPath of a component? Any help appreciated. Cheers Sean. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] upgrading custom actions to be data driven
Before I begin describing how to refactor hard wired custom actions to data driven custom actions, I have to ask: Can your problem be solved using Windows Installer's built-in Condition table? What is unique about your story that requires a custom action in the first place? Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Sean Farrow sean.far...@seanfarrow.co.uk To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Sent: Sat, January 15, 2011 5:02:12 AM Subject: [WiX-users] upgrading custom actions to be data driven Hi: I'm currently in the process of upgrading my custom actions to be data driven. In the current implementation of the msi I'm using properties to enable/disable feature visibility. Is there a way to do this from a table given that what was about 30 properties are now going to be entries in a custom table. Or, within my new custom action should I set the relevant column in the feature table. Also, is there a way to make a column in a table the installPath of a component? Any help appreciated. Cheers Sean. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] upgrading custom actions to be data driven
Hi Chris: Several things, There are multiple language directories for multiple versions of the product I'm installing to. Also,m binary files have to be created whilst installing and hence added to the RemoveFiles table. Hope this explains things. Cheers Sean. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: 15 January 2011 13:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] upgrading custom actions to be data driven Before I begin describing how to refactor hard wired custom actions to data driven custom actions, I have to ask: Can your problem be solved using Windows Installer's built-in Condition table? What is unique about your story that requires a custom action in the first place? Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Sean Farrow sean.far...@seanfarrow.co.uk To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Sent: Sat, January 15, 2011 5:02:12 AM Subject: [WiX-users] upgrading custom actions to be data driven Hi: I'm currently in the process of upgrading my custom actions to be data driven. In the current implementation of the msi I'm using properties to enable/disable feature visibility. Is there a way to do this from a table given that what was about 30 properties are now going to be entries in a custom table. Or, within my new custom action should I set the relevant column in the feature table. Also, is there a way to make a column in a table the installPath of a component? Any help appreciated. Cheers Sean. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
Hi, I keep an extensive archive of older versions of WiX at http://madbutcher.dyndns.org/snippets/WiX/ In case anyone needs it :) Regards, Albert van Peppen -Oorspronkelijk bericht- Van: Rob Mensching [mailto:r...@robmensching.com] Verzonden: vrijdag 7 januari 2011 17:37 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Upgrading wixproj Unfortunately, no. That build was a (now very old) intermediate release. We don't save intermediate releases for very long. We don't have the resources to support drops at all points in time of the development cycle. If you're using the the development branch of the WiX toolset (which both WiX v3.5 and WiX v3.6 are) then you need to upgrade regularly. I know it's a pain but that is the cost to pay while being able to see and participate in every step of the development process. Also note that if you stay current and find issues, it is easier for us to accommodate your needs. -- virtually, Rob Mensching - http://RobMensching.com LLC On Wed, Jan 5, 2011 at 10:48 AM, Eric Goforth eric.gofo...@gmail.comwrote: Thanks Rob, I'd like to avoid having to upgrade all our projects at this time. Is there a version at http://wix.sf.net/releases that will work with my \Microsoft\WiX\v3.5\Wix2010.targets style wix projects? -Eric On Wed, Jan 5, 2011 at 2:31 AM, Rob Mensching r...@robmensching.com wrote: And to answer the actual question, I think 3.5.1419 has rolled off. That build is almost a year out of date, we don't keep development builds around for more than a few months typically (and less when we get to Escrow like with WiX v3.5). On Tue, Jan 4, 2011 at 11:30 PM, Rob Mensching r...@robmensching.com wrote: Weekly release are at http://wix.sf.net/releases. Yes, I know, we need to clean all this stuff up. Sorry. Eventually http://wixtoolset.org will have all the information. On Tue, Jan 4, 2011 at 2:14 PM, Eric Goforth eric.gofo...@gmail.com wrote: Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406) right now and I don't see a way to download 3.5.1419, is it possible to do that? I checked out http://wixtoolset.org/ too, but it looks like that's just a place-holder site for now. -Eric On Tue, Jan 4, 2011 at 5:03 PM, Eric Goforth eric.gofo...@gmail.com wrote: Thanks, it looks like he has 3.5.1419, I have 3.5.2415. On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote: All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading- wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl
Re: [WiX-users] Upgrading wixproj
Unfortunately, no. That build was a (now very old) intermediate release. We don't save intermediate releases for very long. We don't have the resources to support drops at all points in time of the development cycle. If you're using the the development branch of the WiX toolset (which both WiX v3.5 and WiX v3.6 are) then you need to upgrade regularly. I know it's a pain but that is the cost to pay while being able to see and participate in every step of the development process. Also note that if you stay current and find issues, it is easier for us to accommodate your needs. -- virtually, Rob Mensching - http://RobMensching.com LLC On Wed, Jan 5, 2011 at 10:48 AM, Eric Goforth eric.gofo...@gmail.comwrote: Thanks Rob, I'd like to avoid having to upgrade all our projects at this time. Is there a version at http://wix.sf.net/releases that will work with my \Microsoft\WiX\v3.5\Wix2010.targets style wix projects? -Eric On Wed, Jan 5, 2011 at 2:31 AM, Rob Mensching r...@robmensching.com wrote: And to answer the actual question, I think 3.5.1419 has rolled off. That build is almost a year out of date, we don't keep development builds around for more than a few months typically (and less when we get to Escrow like with WiX v3.5). On Tue, Jan 4, 2011 at 11:30 PM, Rob Mensching r...@robmensching.com wrote: Weekly release are at http://wix.sf.net/releases. Yes, I know, we need to clean all this stuff up. Sorry. Eventually http://wixtoolset.org will have all the information. On Tue, Jan 4, 2011 at 2:14 PM, Eric Goforth eric.gofo...@gmail.com wrote: Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406) right now and I don't see a way to download 3.5.1419, is it possible to do that? I checked out http://wixtoolset.org/ too, but it looks like that's just a place-holder site for now. -Eric On Tue, Jan 4, 2011 at 5:03 PM, Eric Goforth eric.gofo...@gmail.com wrote: Thanks, it looks like he has 3.5.1419, I have 3.5.2415. On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote: All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
Thanks Rob, I'd like to avoid having to upgrade all our projects at this time. Is there a version at http://wix.sf.net/releases that will work with my \Microsoft\WiX\v3.5\Wix2010.targets style wix projects? -Eric On Wed, Jan 5, 2011 at 2:31 AM, Rob Mensching r...@robmensching.com wrote: And to answer the actual question, I think 3.5.1419 has rolled off. That build is almost a year out of date, we don't keep development builds around for more than a few months typically (and less when we get to Escrow like with WiX v3.5). On Tue, Jan 4, 2011 at 11:30 PM, Rob Mensching r...@robmensching.com wrote: Weekly release are at http://wix.sf.net/releases. Yes, I know, we need to clean all this stuff up. Sorry. Eventually http://wixtoolset.org will have all the information. On Tue, Jan 4, 2011 at 2:14 PM, Eric Goforth eric.gofo...@gmail.comwrote: Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406) right now and I don't see a way to download 3.5.1419, is it possible to do that? I checked out http://wixtoolset.org/ too, but it looks like that's just a place-holder site for now. -Eric On Tue, Jan 4, 2011 at 5:03 PM, Eric Goforth eric.gofo...@gmail.com wrote: Thanks, it looks like he has 3.5.1419, I have 3.5.2415. On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote: All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading wixproj
Hello, I have installed Windows Installer XML Toolset 3.5 on my development machine, which is running Vista 32-bit, for what it's worth. I'm then opening a .wixproj file using Visual Studio 2010 that was created by a different developer here using WIX3.5/VS2010, I believe. At any rate, when I open the file, I get prompted by Visual Studio to upgrade the solution. The developer who originally created this file doesn't get this message. Prior to my upgrade, when i look at the .wixproj file, I see the following tags: WixTargetsPath Condition= '$(WixTargetsPath)' == '' AND '$(MSBuildExtensionsPath32)' != '' $(MSBuildExtensionsPath32)\Microsoft\WiX\v3.5\Wix2010.targets/WixTargetsPath WixTargetsPath Condition= '$(WixTargetsPath)' == '' $(MSBuildExtensionsPath)\Microsoft\WiX\v3.5\Wix2010.targets/WixTargetsPath After the upgrade has completed, these lines are changed to: WixTargetsPath Condition= '$(WixTargetsPath)' == '' AND '$(MSBuildExtensionsPath32)' != '' $(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets/WixTargetsPath WixTargetsPath Condition= '$(WixTargetsPath)' == '' $(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets/WixTargetsPath This looks like it's rolling back the version to me. Any idea what's up? I also have VS 2008 on my machine, but we're doing all new development (including this Wix project) in 2010. I watched the other developer open this .wixproj file in VS 2010 a few minutes ago, and he wasn't prompted to do an upgrade. Thanks, -Eric -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
It looks like they have an older version of 3.5 installed than you do. I believe it used to v3.5 but was later switched to use v3.x. If you both install the same version it should solve your problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890126.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
Hello, I looked at the other developer's add/remove programs, it showed the same version as mine: Windows Installer XML Toolset 3.5 Before the upgrade, I see: $(MSBuildExtensionsPath)\Microsoft\WiX\v3.5\Wix2010.targets In the .wixproj file, after the upgrade, I see: $(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets Is v3.x\Wix.targets a newer version than v3.5\Wix2010.targets, it seems older to me. Both myself and the other developer are opening the .wixproj files with VS 2010. Thanks, Eric On Tue, Jan 4, 2011 at 3:57 PM, jhennessey jack.hennes...@hyland.com wrote: It looks like they have an older version of 3.5 installed than you do. I believe it used to v3.5 but was later switched to use v3.x. If you both install the same version it should solve your problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890126.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
Thanks, it looks like he has 3.5.1419, I have 3.5.2415. On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote: All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406) right now and I don't see a way to download 3.5.1419, is it possible to do that? I checked out http://wixtoolset.org/ too, but it looks like that's just a place-holder site for now. -Eric On Tue, Jan 4, 2011 at 5:03 PM, Eric Goforth eric.gofo...@gmail.com wrote: Thanks, it looks like he has 3.5.1419, I have 3.5.2415. On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote: All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
Weekly release are at http://wix.sf.net/releases. Yes, I know, we need to clean all this stuff up. Sorry. Eventually http://wixtoolset.org will have all the information. On Tue, Jan 4, 2011 at 2:14 PM, Eric Goforth eric.gofo...@gmail.com wrote: Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406) right now and I don't see a way to download 3.5.1419, is it possible to do that? I checked out http://wixtoolset.org/ too, but it looks like that's just a place-holder site for now. -Eric On Tue, Jan 4, 2011 at 5:03 PM, Eric Goforth eric.gofo...@gmail.com wrote: Thanks, it looks like he has 3.5.1419, I have 3.5.2415. On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote: All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
And to answer the actual question, I think 3.5.1419 has rolled off. That build is almost a year out of date, we don't keep development builds around for more than a few months typically (and less when we get to Escrow like with WiX v3.5). On Tue, Jan 4, 2011 at 11:30 PM, Rob Mensching r...@robmensching.com wrote: Weekly release are at http://wix.sf.net/releases. Yes, I know, we need to clean all this stuff up. Sorry. Eventually http://wixtoolset.org will have all the information. On Tue, Jan 4, 2011 at 2:14 PM, Eric Goforth eric.gofo...@gmail.comwrote: Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406) right now and I don't see a way to download 3.5.1419, is it possible to do that? I checked out http://wixtoolset.org/ too, but it looks like that's just a place-holder site for now. -Eric On Tue, Jan 4, 2011 at 5:03 PM, Eric Goforth eric.gofo...@gmail.com wrote: Thanks, it looks like he has 3.5.1419, I have 3.5.2415. On Tue, Jan 4, 2011 at 4:40 PM, jhennessey jack.hennes...@hyland.com wrote: All builds will say Windows Installer XML Toolset 3.5 but you need to check the actual build version (I think the latest is 3.5.2430.0). v3.x\Wix.targets is what is current -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890254.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading wixproj
Yes, we switched to v3.x in hopes that the VS project system will not have an upgrade in WiX v3.6 and later. There were a great many changes in VS2010 that caused the project system upgrade. It's painful and hopefully we've done the work necessary to not need another one for the life of WiX v3.x now... Of course, WiX v4.0 will break everything later. smile/ On Tue, Jan 4, 2011 at 12:57 PM, jhennessey jack.hennes...@hyland.comwrote: It looks like they have an older version of 3.5 installed than you do. I believe it used to v3.5 but was later switched to use v3.x. If you both install the same version it should solve your problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp5890061p5890126.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Hi, I changed my approach a little bit. For reference: This is what I added to my wxs file: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / InstallUISequence Custom Action='CheckingSpecialist' After='LaunchConditions' / /InstallUISequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist.dll' / And this is my small CheckSpecialist.c: http://pastebin.com/mBL01Wtz So the return value is either ERROR_SUCCESS or !ERROR_SUCCESS. I do not use MsiSetProperty any more and just one custom action. If anybody sees a bad thing in this approach/code I would really appreciate a hint. Regards, Luke Am 25.07.2010 17:27, schrieb Blair: If the other setup package is ultimately MSI, you should ideally use the Upgrade table to remove it (via the RemoveExistingProducts action using the Major Upgrade method). However, that doesn't work if the ALLUSERS value differs between the two installations and you will need to look at ways to bootstrap that uninstallation, since you can't run it at all from the InstallExecuteSequence. If the other setup package is not-at-all MSI, there is nothing to pass to Windows Installer, since WI can only deal with MSI packages, and you will need to execute the uninstall executable somehow/somewhere. -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Sunday, July 25, 2010 5:18 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Thank you for the hint! I will replace my MessageBox-call prompt with MsiProcessMessage/WcaProcessMessage ... Apart from this, my approach is good practice? Or is it maybe better to pass the uninstall to MSI and executing it there rather than calling ShellExecuteEx from the DLL? Regards, Luke Am 23.07.2010 08:54, schrieb Blair: You shouldn't prompt from the execute sequence. There are ways of running MSI files where there is no user session to respond to the prompt and you would hang your install. The best way to show a message box from a custom action (and the only supported way if you must do so from the execute sequence) is using the MsiProcessMessage API (or something that wraps it, like WcaProcessMessage or Microsoft.Deployment.WindowsInstaller.Session.Message). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Am 22.07.2010 01:04, schrieb Blair: 1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. In fact this is exactly what I do NOT want: I need to register a COM component which requires admin privileges. So I have Property Id=ALLUSERS1/Property and Condition Message=... Privileged /Condition and I am lucky. In fact this is exactly what messed up my previous installations with SetupSpecialist: The old viewer did not need registering a COM, so some users installed as admins and systemwide, others not. Finally, SetupSpecialist lets you run the setup as normal user and when registering the COM the there is an error. The setup terminates and the a half installed system is left. In my opinion it is the best and consistent way to install the software just into the system (incl. Shortcuts for all users) 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. Thank you for the hint. This is what I have done now. As written in a new post (InstallExecuteSequence completely ignored) I face heavy problems concerning this right now. However, my approach is: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / CustomAction Id='RefuseInstall' Error='You must uninstall the old one first' / InstallExecuteSequence Custom Action='CheckingSpecialist' After='LaunchConditions' / Custom Action='RefuseInstall' After='CheckingSpecialist'ABORT = 1/Custom /InstallExecuteSequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist/Release/CheckSpecialist.dll' / The DLL just opens the registry key in Uninstall and reads out the path to the uninstall program. Then it asks: You must remove the old first, do you want
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Dear dB, Thank you for your comment. You are right, maybe a bootstrapper would have been the better apporach ... I will have a look at dotNetInstaller. Am 23.07.2010 16:43, schrieb dB.: Having dealt with a similar scenario with InstallShield, the best I can suggest is to bootstrap uninstall. You can use dotNetInstaller (http://dotnetinstaller.codeplex.com) and write a command line that will uninstall the previous application. Write an MSI to uninstall the legacy thing or write a tool to do it. I'd do everything to avoid bloating the new installer with any kind of logic that deals with a legacy installer. For your user/administrator problem - when you run as administrator, you can do everything any user can do. So embed a manifest in the bootstrapper that will make it always run as administrator. If you must have just 1 MSI, you will try to do what we did. In the MSI we would detect that a previous installshield application is installed (registry) and ran uninstall, dropping an .rsp file that drives the installshield uninstall. We made the MSI believe it's doing a major upgrade (some convenience properties here: http://code.dblock.org/ShowPost.aspx?id=42). It was pretty hard overall and took more effort to clean-up once the customers were off those very old versions. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 4:20 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading from other setup program to WiX/MSI Hi, Today I began creating my first WiX project. Until now I used SetupSpecialist but as I am facing serious problems with it I want to use WiX in future. This is my first big question: On clients' computers there will be an old instance of my program (with SetupSpecialist) installed. Even worse: My new version requires the setup to be run as administrator. However, the old versions might be installed as normal users. What is the best way to handle this situation? Thank you. Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Sorry, I havent been following this thread, but I did have a glance at the code while waiting for an installation :) !ERROR_SUCCESS isnt a valid custom action return. See this list http://msdn.microsoft.com/en-us/library/aa368072%28VS.85%29.aspx -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: 26 July 2010 11:44 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Hi, I changed my approach a little bit. For reference: This is what I added to my wxs file: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / InstallUISequence Custom Action='CheckingSpecialist' After='LaunchConditions' / /InstallUISequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist.dll' / And this is my small CheckSpecialist.c: http://pastebin.com/mBL01Wtz So the return value is either ERROR_SUCCESS or !ERROR_SUCCESS. I do not use MsiSetProperty any more and just one custom action. If anybody sees a bad thing in this approach/code I would really appreciate a hint. Regards, Luke Am 25.07.2010 17:27, schrieb Blair: If the other setup package is ultimately MSI, you should ideally use the Upgrade table to remove it (via the RemoveExistingProducts action using the Major Upgrade method). However, that doesn't work if the ALLUSERS value differs between the two installations and you will need to look at ways to bootstrap that uninstallation, since you can't run it at all from the InstallExecuteSequence. If the other setup package is not-at-all MSI, there is nothing to pass to Windows Installer, since WI can only deal with MSI packages, and you will need to execute the uninstall executable somehow/somewhere. -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Sunday, July 25, 2010 5:18 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Thank you for the hint! I will replace my MessageBox-call prompt with MsiProcessMessage/WcaProcessMessage ... Apart from this, my approach is good practice? Or is it maybe better to pass the uninstall to MSI and executing it there rather than calling ShellExecuteEx from the DLL? Regards, Luke Am 23.07.2010 08:54, schrieb Blair: You shouldn't prompt from the execute sequence. There are ways of running MSI files where there is no user session to respond to the prompt and you would hang your install. The best way to show a message box from a custom action (and the only supported way if you must do so from the execute sequence) is using the MsiProcessMessage API (or something that wraps it, like WcaProcessMessage or Microsoft.Deployment.WindowsInstaller.Session.Message). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Am 22.07.2010 01:04, schrieb Blair: 1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. In fact this is exactly what I do NOT want: I need to register a COM component which requires admin privileges. So I have Property Id=ALLUSERS1/Property and Condition Message=... Privileged /Condition and I am lucky. In fact this is exactly what messed up my previous installations with SetupSpecialist: The old viewer did not need registering a COM, so some users installed as admins and systemwide, others not. Finally, SetupSpecialist lets you run the setup as normal user and when registering the COM the there is an error. The setup terminates and the a half installed system is left. In my opinion it is the best and consistent way to install the software just into the system (incl. Shortcuts for all users) 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. Thank you for the hint. This is what I have done now. As written in a new post (InstallExecuteSequence completely ignored) I face heavy problems concerning this right now. However, my approach is: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / CustomAction Id='RefuseInstall' Error='You must
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Dear Peter, Thank you for the hint! I replaced it now by ERROR_INSTALL_USEREXIT which fits the best in my opinion. Regards, Luke Am 26.07.2010 13:03, schrieb Peter Shirtcliffe: Sorry, I havent been following this thread, but I did have a glance at the code while waiting for an installation :) !ERROR_SUCCESS isnt a valid custom action return. See this list http://msdn.microsoft.com/en-us/library/aa368072%28VS.85%29.aspx -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: 26 July 2010 11:44 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Hi, I changed my approach a little bit. For reference: This is what I added to my wxs file: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / InstallUISequence Custom Action='CheckingSpecialist' After='LaunchConditions' / /InstallUISequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist.dll' / And this is my small CheckSpecialist.c: http://pastebin.com/mBL01Wtz So the return value is either ERROR_SUCCESS or !ERROR_SUCCESS. I do not use MsiSetProperty any more and just one custom action. If anybody sees a bad thing in this approach/code I would really appreciate a hint. Regards, Luke Am 25.07.2010 17:27, schrieb Blair: If the other setup package is ultimately MSI, you should ideally use the Upgrade table to remove it (via the RemoveExistingProducts action using the Major Upgrade method). However, that doesn't work if the ALLUSERS value differs between the two installations and you will need to look at ways to bootstrap that uninstallation, since you can't run it at all from the InstallExecuteSequence. If the other setup package is not-at-all MSI, there is nothing to pass to Windows Installer, since WI can only deal with MSI packages, and you will need to execute the uninstall executable somehow/somewhere. -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Sunday, July 25, 2010 5:18 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Thank you for the hint! I will replace my MessageBox-call prompt with MsiProcessMessage/WcaProcessMessage ... Apart from this, my approach is good practice? Or is it maybe better to pass the uninstall to MSI and executing it there rather than calling ShellExecuteEx from the DLL? Regards, Luke Am 23.07.2010 08:54, schrieb Blair: You shouldn't prompt from the execute sequence. There are ways of running MSI files where there is no user session to respond to the prompt and you would hang your install. The best way to show a message box from a custom action (and the only supported way if you must do so from the execute sequence) is using the MsiProcessMessage API (or something that wraps it, like WcaProcessMessage or Microsoft.Deployment.WindowsInstaller.Session.Message). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Am 22.07.2010 01:04, schrieb Blair: 1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. In fact this is exactly what I do NOT want: I need to register a COM component which requires admin privileges. So I have Property Id=ALLUSERS1/Property and Condition Message=... Privileged /Condition and I am lucky. In fact this is exactly what messed up my previous installations with SetupSpecialist: The old viewer did not need registering a COM, so some users installed as admins and systemwide, others not. Finally, SetupSpecialist lets you run the setup as normal user and when registering the COM the there is an error. The setup terminates and the a half installed system is left. In my opinion it is the best and consistent way to install the software just into the system (incl. Shortcuts for all users) 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. Thank you for the hint. This is what I have done now. As written in a new post (InstallExecuteSequence completely ignored) I face heavy problems concerning this right now
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Dear Blair, Thank you for the hint! I will replace my MessageBox-call prompt with MsiProcessMessage/WcaProcessMessage ... Apart from this, my approach is good practice? Or is it maybe better to pass the uninstall to MSI and executing it there rather than calling ShellExecuteEx from the DLL? Regards, Luke Am 23.07.2010 08:54, schrieb Blair: You shouldn't prompt from the execute sequence. There are ways of running MSI files where there is no user session to respond to the prompt and you would hang your install. The best way to show a message box from a custom action (and the only supported way if you must do so from the execute sequence) is using the MsiProcessMessage API (or something that wraps it, like WcaProcessMessage or Microsoft.Deployment.WindowsInstaller.Session.Message). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Am 22.07.2010 01:04, schrieb Blair: 1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. In fact this is exactly what I do NOT want: I need to register a COM component which requires admin privileges. So I have Property Id=ALLUSERS1/Property and Condition Message=... Privileged /Condition and I am lucky. In fact this is exactly what messed up my previous installations with SetupSpecialist: The old viewer did not need registering a COM, so some users installed as admins and systemwide, others not. Finally, SetupSpecialist lets you run the setup as normal user and when registering the COM the there is an error. The setup terminates and the a half installed system is left. In my opinion it is the best and consistent way to install the software just into the system (incl. Shortcuts for all users) 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. Thank you for the hint. This is what I have done now. As written in a new post (InstallExecuteSequence completely ignored) I face heavy problems concerning this right now. However, my approach is: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / CustomAction Id='RefuseInstall' Error='You must uninstall the old one first' / InstallExecuteSequence Custom Action='CheckingSpecialist' After='LaunchConditions' / Custom Action='RefuseInstall' After='CheckingSpecialist'ABORT = 1/Custom /InstallExecuteSequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist/Release/CheckSpecialist.dll' / The DLL just opens the registry key in Uninstall and reads out the path to the uninstall program. Then it asks: You must remove the old first, do you want to?. If the users answers with no, then ABORT = 1 is set. Otherwise, the process uninstall is started with ShellExecuteEx and waited for termination with WaitForSingleObject. Afterwards ABORT = 0 is set. If it fails to open the key (i.e. no old version found) just ABORT = 0 is set. Is this a good idea or did I break some best practices? Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
If the other setup package is ultimately MSI, you should ideally use the Upgrade table to remove it (via the RemoveExistingProducts action using the Major Upgrade method). However, that doesn't work if the ALLUSERS value differs between the two installations and you will need to look at ways to bootstrap that uninstallation, since you can't run it at all from the InstallExecuteSequence. If the other setup package is not-at-all MSI, there is nothing to pass to Windows Installer, since WI can only deal with MSI packages, and you will need to execute the uninstall executable somehow/somewhere. -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Sunday, July 25, 2010 5:18 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Thank you for the hint! I will replace my MessageBox-call prompt with MsiProcessMessage/WcaProcessMessage ... Apart from this, my approach is good practice? Or is it maybe better to pass the uninstall to MSI and executing it there rather than calling ShellExecuteEx from the DLL? Regards, Luke Am 23.07.2010 08:54, schrieb Blair: You shouldn't prompt from the execute sequence. There are ways of running MSI files where there is no user session to respond to the prompt and you would hang your install. The best way to show a message box from a custom action (and the only supported way if you must do so from the execute sequence) is using the MsiProcessMessage API (or something that wraps it, like WcaProcessMessage or Microsoft.Deployment.WindowsInstaller.Session.Message). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Am 22.07.2010 01:04, schrieb Blair: 1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. In fact this is exactly what I do NOT want: I need to register a COM component which requires admin privileges. So I have Property Id=ALLUSERS1/Property and Condition Message=... Privileged /Condition and I am lucky. In fact this is exactly what messed up my previous installations with SetupSpecialist: The old viewer did not need registering a COM, so some users installed as admins and systemwide, others not. Finally, SetupSpecialist lets you run the setup as normal user and when registering the COM the there is an error. The setup terminates and the a half installed system is left. In my opinion it is the best and consistent way to install the software just into the system (incl. Shortcuts for all users) 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. Thank you for the hint. This is what I have done now. As written in a new post (InstallExecuteSequence completely ignored) I face heavy problems concerning this right now. However, my approach is: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / CustomAction Id='RefuseInstall' Error='You must uninstall the old one first' / InstallExecuteSequence Custom Action='CheckingSpecialist' After='LaunchConditions' / Custom Action='RefuseInstall' After='CheckingSpecialist'ABORT = 1/Custom /InstallExecuteSequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist/Release/CheckSpecialist.dll' / The DLL just opens the registry key in Uninstall and reads out the path to the uninstall program. Then it asks: You must remove the old first, do you want to?. If the users answers with no, then ABORT = 1 is set. Otherwise, the process uninstall is started with ShellExecuteEx and waited for termination with WaitForSingleObject. Afterwards ABORT = 0 is set. If it fails to open the key (i.e. no old version found) just ABORT = 0 is set. Is this a good idea or did I break some best practices? Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
You shouldn't prompt from the execute sequence. There are ways of running MSI files where there is no user session to respond to the prompt and you would hang your install. The best way to show a message box from a custom action (and the only supported way if you must do so from the execute sequence) is using the MsiProcessMessage API (or something that wraps it, like WcaProcessMessage or Microsoft.Deployment.WindowsInstaller.Session.Message). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Am 22.07.2010 01:04, schrieb Blair: 1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. In fact this is exactly what I do NOT want: I need to register a COM component which requires admin privileges. So I have Property Id=ALLUSERS1/Property and Condition Message=... Privileged /Condition and I am lucky. In fact this is exactly what messed up my previous installations with SetupSpecialist: The old viewer did not need registering a COM, so some users installed as admins and systemwide, others not. Finally, SetupSpecialist lets you run the setup as normal user and when registering the COM the there is an error. The setup terminates and the a half installed system is left. In my opinion it is the best and consistent way to install the software just into the system (incl. Shortcuts for all users) 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. Thank you for the hint. This is what I have done now. As written in a new post (InstallExecuteSequence completely ignored) I face heavy problems concerning this right now. However, my approach is: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / CustomAction Id='RefuseInstall' Error='You must uninstall the old one first' / InstallExecuteSequence Custom Action='CheckingSpecialist' After='LaunchConditions' / Custom Action='RefuseInstall' After='CheckingSpecialist'ABORT = 1/Custom /InstallExecuteSequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist/Release/CheckSpecialist.dll' / The DLL just opens the registry key in Uninstall and reads out the path to the uninstall program. Then it asks: You must remove the old first, do you want to?. If the users answers with no, then ABORT = 1 is set. Otherwise, the process uninstall is started with ShellExecuteEx and waited for termination with WaitForSingleObject. Afterwards ABORT = 0 is set. If it fails to open the key (i.e. no old version found) just ABORT = 0 is set. Is this a good idea or did I break some best practices? Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Having dealt with a similar scenario with InstallShield, the best I can suggest is to bootstrap uninstall. You can use dotNetInstaller (http://dotnetinstaller.codeplex.com) and write a command line that will uninstall the previous application. Write an MSI to uninstall the legacy thing or write a tool to do it. I'd do everything to avoid bloating the new installer with any kind of logic that deals with a legacy installer. For your user/administrator problem - when you run as administrator, you can do everything any user can do. So embed a manifest in the bootstrapper that will make it always run as administrator. If you must have just 1 MSI, you will try to do what we did. In the MSI we would detect that a previous installshield application is installed (registry) and ran uninstall, dropping an .rsp file that drives the installshield uninstall. We made the MSI believe it's doing a major upgrade (some convenience properties here: http://code.dblock.org/ShowPost.aspx?id=42). It was pretty hard overall and took more effort to clean-up once the customers were off those very old versions. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 4:20 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading from other setup program to WiX/MSI Hi, Today I began creating my first WiX project. Until now I used SetupSpecialist but as I am facing serious problems with it I want to use WiX in future. This is my first big question: On clients' computers there will be an old instance of my program (with SetupSpecialist) installed. Even worse: My new version requires the setup to be run as administrator. However, the old versions might be installed as normal users. What is the best way to handle this situation? Thank you. Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Dear Blair, Am 22.07.2010 01:04, schrieb Blair: 1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. In fact this is exactly what I do NOT want: I need to register a COM component which requires admin privileges. So I have Property Id=ALLUSERS1/Property and Condition Message=... Privileged /Condition and I am lucky. In fact this is exactly what messed up my previous installations with SetupSpecialist: The old viewer did not need registering a COM, so some users installed as admins and systemwide, others not. Finally, SetupSpecialist lets you run the setup as normal user and when registering the COM the there is an error. The setup terminates and the a half installed system is left. In my opinion it is the best and consistent way to install the software just into the system (incl. Shortcuts for all users) 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. Thank you for the hint. This is what I have done now. As written in a new post (InstallExecuteSequence completely ignored) I face heavy problems concerning this right now. However, my approach is: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / CustomAction Id='RefuseInstall' Error='You must uninstall the old one first' / InstallExecuteSequence Custom Action='CheckingSpecialist' After='LaunchConditions' / Custom Action='RefuseInstall' After='CheckingSpecialist'ABORT = 1/Custom /InstallExecuteSequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist/Release/CheckSpecialist.dll' / The DLL just opens the registry key in Uninstall and reads out the path to the uninstall program. Then it asks: You must remove the old first, do you want to?. If the users answers with no, then ABORT = 1 is set. Otherwise, the process uninstall is started with ShellExecuteEx and waited for termination with WaitForSingleObject. Afterwards ABORT = 0 is set. If it fails to open the key (i.e. no old version found) just ABORT = 0 is set. Is this a good idea or did I break some best practices? Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading from other setup program to WiX/MSI
Hi, Today I began creating my first WiX project. Until now I used SetupSpecialist but as I am facing serious problems with it I want to use WiX in future. This is my first big question: On clients' computers there will be an old instance of my program (with SetupSpecialist) installed. Even worse: My new version requires the setup to be run as administrator. However, the old versions might be installed as normal users. What is the best way to handle this situation? Thank you. Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 1:20 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading from other setup program to WiX/MSI Hi, Today I began creating my first WiX project. Until now I used SetupSpecialist but as I am facing serious problems with it I want to use WiX in future. This is my first big question: On clients' computers there will be an old instance of my program (with SetupSpecialist) installed. Even worse: My new version requires the setup to be run as administrator. However, the old versions might be installed as normal users. What is the best way to handle this situation? Thank you. Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading
That's known as a Minor Update but it's only one of the available upgrade types. See http://msdn.microsoft.com/en-us/library/aa370579.aspx Palbinder Sandher Software Deployment IT Administrator 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: Daniel Marjamäki [mailto:daniel...@spray.se] Sent: 21 November 2009 10:59 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading Sorry.. the solution was to execute the msi like this: msiexec.exe /I product.msi REINSTALL=All REINSTALLMODE=vomus So I am not stuck anymore. Regards, Daniel Daniel Marjamäki wrote: I am having trouble with upgrades. Upon installation I want to completely uninstall any old versions. I have seen so many answers about this in various places. But nothing works. I use the same UpgradeCode in both old and new versions. I use the same Product Id in both old and new versions. I use wix 3.0.5419.0 Here is my WIX code: Upgrade Id='$(var.ProductUpgradeCode)' UpgradeVersion OnlyDetect='no' Property='PREVIOUSFOUND' Minimum='1.0.0' IncludeMinimum='yes' Maximum='$(var.ProductVersion)' IncludeMaximum='no' / /Upgrade InstallExecuteSequence RemoveExistingProducts After=InstallInitialize / /InstallExecuteSequence When I compile that I get no error messages. When I execute the MSI I get an error message that another version is already installed and I need to uninstall that manually. What is the PREVIOUSFOUND good for? I don't have it anywhere else in my WIX file. None of the answers I have seen so far have explained this. I wonder how the RemoveExistingProducts knows which entry to look at in the upgrade table. If I have two UpgradeVersion elements in the upgrade table (to also prevent downgrade) then a newer version of my program might be matched in the upgrade table. -- View this message in context: http://n2.nabble.com/Upgrading-tp4042099p4042249.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading
To do major upgrade (from that web page Pally supplied) you would need to either remove the OnlyDetect attribute or change its value to no AND change the Product Id between builds/releases. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, November 23, 2009 4:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Upgrading That's known as a Minor Update but it's only one of the available upgrade types. See http://msdn.microsoft.com/en-us/library/aa370579.aspx Palbinder Sandher Software Deployment IT Administrator 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: Daniel Marjamäki [mailto:daniel...@spray.se] Sent: 21 November 2009 10:59 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading Sorry.. the solution was to execute the msi like this: msiexec.exe /I product.msi REINSTALL=All REINSTALLMODE=vomus So I am not stuck anymore. Regards, Daniel Daniel Marjamäki wrote: I am having trouble with upgrades. Upon installation I want to completely uninstall any old versions. I have seen so many answers about this in various places. But nothing works. I use the same UpgradeCode in both old and new versions. I use the same Product Id in both old and new versions. I use wix 3.0.5419.0 Here is my WIX code: Upgrade Id='$(var.ProductUpgradeCode)' UpgradeVersion OnlyDetect='no' Property='PREVIOUSFOUND' Minimum='1.0.0' IncludeMinimum='yes' Maximum='$(var.ProductVersion)' IncludeMaximum='no' / /Upgrade InstallExecuteSequence RemoveExistingProducts After=InstallInitialize / /InstallExecuteSequence When I compile that I get no error messages. When I execute the MSI I get an error message that another version is already installed and I need to uninstall that manually. What is the PREVIOUSFOUND good for? I don't have it anywhere else in my WIX file. None of the answers I have seen so far have explained this. I wonder how the RemoveExistingProducts knows which entry to look at in the upgrade table. If I have two UpgradeVersion elements in the upgrade table (to also prevent downgrade) then a newer version of my program might be matched in the upgrade table. -- View this message in context: http://n2.nabble.com/Upgrading-tp4042099p4042249.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading
I am having trouble with upgrades. Upon installation I want to completely uninstall any old versions. I have seen so many answers about this in various places. But nothing works. I use the same UpgradeCode in both old and new versions. I use the same Product Id in both old and new versions. I use wix 3.0.5419.0 Here is my WIX code: Upgrade Id='$(var.ProductUpgradeCode)' UpgradeVersion OnlyDetect='no' Property='PREVIOUSFOUND' Minimum='1.0.0' IncludeMinimum='yes' Maximum='$(var.ProductVersion)' IncludeMaximum='no' / /Upgrade InstallExecuteSequence RemoveExistingProducts After=InstallInitialize / /InstallExecuteSequence When I compile that I get no error messages. When I execute the MSI I get an error message that another version is already installed and I need to uninstall that manually. What is the PREVIOUSFOUND good for? I don't have it anywhere else in my WIX file. None of the answers I have seen so far have explained this. I wonder how the RemoveExistingProducts knows which entry to look at in the upgrade table. If I have two UpgradeVersion elements in the upgrade table (to also prevent downgrade) then a newer version of my program might be matched in the upgrade table. -- View this message in context: http://n2.nabble.com/Upgrading-tp4042099p4042099.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading
Sorry.. the solution was to execute the msi like this: msiexec.exe /I product.msi REINSTALL=All REINSTALLMODE=vomus So I am not stuck anymore. Regards, Daniel Daniel Marjamäki wrote: I am having trouble with upgrades. Upon installation I want to completely uninstall any old versions. I have seen so many answers about this in various places. But nothing works. I use the same UpgradeCode in both old and new versions. I use the same Product Id in both old and new versions. I use wix 3.0.5419.0 Here is my WIX code: Upgrade Id='$(var.ProductUpgradeCode)' UpgradeVersion OnlyDetect='no' Property='PREVIOUSFOUND' Minimum='1.0.0' IncludeMinimum='yes' Maximum='$(var.ProductVersion)' IncludeMaximum='no' / /Upgrade InstallExecuteSequence RemoveExistingProducts After=InstallInitialize / /InstallExecuteSequence When I compile that I get no error messages. When I execute the MSI I get an error message that another version is already installed and I need to uninstall that manually. What is the PREVIOUSFOUND good for? I don't have it anywhere else in my WIX file. None of the answers I have seen so far have explained this. I wonder how the RemoveExistingProducts knows which entry to look at in the upgrade table. If I have two UpgradeVersion elements in the upgrade table (to also prevent downgrade) then a newer version of my program might be matched in the upgrade table. -- View this message in context: http://n2.nabble.com/Upgrading-tp4042099p4042249.html Sent from the wix-users mailing list archive at Nabble.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading to WiX 3, CNDL0005 error.
Greetings all, I'm working up updating an installer from WiX 2 to WiX3. I've used WixCop to do most of the conversion, but I'm getting the following error: error CNDL0005 : The File element contains an unexpected child element 'util:PerformanceCounter'. The area in question is: File Id=perfc.ini Name=perfc.ini Source=..\foo\bar\perfc.ini util:PerformanceCounter Name=bar / /File I have the namespace defined, and am calling candle with -ext WixUtilExtension, and have been unable to determine the root cause of the issue with the resources I could find. Any help would be appreciated. -Andy -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading to WiX 3, CNDL0005 error.
According to wix.chm, File isn't a valid parent element for util:PerformanceCounter. It needs to be under a Util:PerformanceCategory element, which in turn needs to be under a Component element, not a File. See the CHM for more information. Thanks, Mike Carlson -Original Message- From: Andy Glass [mailto:agl...@laserfiche.com] Sent: Thursday, July 23, 2009 11:01 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Upgrading to WiX 3, CNDL0005 error. Greetings all, I'm working up updating an installer from WiX 2 to WiX3. I've used WixCop to do most of the conversion, but I'm getting the following error: error CNDL0005 : The File element contains an unexpected child element 'util:PerformanceCounter'. The area in question is: File Id=perfc.ini Name=perfc.ini Source=..\foo\bar\perfc.ini util:PerformanceCounter Name=bar / /File I have the namespace defined, and am calling candle with -ext WixUtilExtension, and have been unable to determine the root cause of the issue with the resources I could find. Any help would be appreciated. -Andy -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading...
Hello, I used WIX to create an installer for our last release of our software. I was using NSIS prior to that, but we had customers who wanted to be to implement installs over a network, so we switched. So, we are at a point where I have to do another release, and I want to be able to 1) Install new if the older version does not exist, and 2) uninstall the older version before installing if it does exist. I have looked at Upgrade and Upgrade codes, etc., but cannot grasp what exactly I have to do. All the attempts I have tried have either given me the already installed error, or installed separate keeping the older version in the programs listing. Any suggestions on a good source to understand this? I have tried the documentation here on the site, but can't seem to figure out if I need new GUIDs or use older ones, etc. Thank You, John -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
Take at look at the WiX tutorial at http://www.tramontana.co.hu/wix/lesson4.php This has some detail on doing upgrades. That should start you on your way. Chris -Original Message- From: John D. Marinuzzi [mailto:nu...@hypack.com] Sent: Wednesday, July 22, 2009 13:12 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading... Hello, I used WIX to create an installer for our last release of our software. I was using NSIS prior to that, but we had customers who wanted to be to implement installs over a network, so we switched. So, we are at a point where I have to do another release, and I want to be able to 1) Install new if the older version does not exist, and 2) uninstall the older version before installing if it does exist. I have looked at Upgrade and Upgrade codes, etc., but cannot grasp what exactly I have to do. All the attempts I have tried have either given me the already installed error, or installed separate keeping the older version in the programs listing. Any suggestions on a good source to understand this? I have tried the documentation here on the site, but can't seem to figure out if I need new GUIDs or use older ones, etc. Thank You, John -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
Few options available here and you can find more using search engine of your choice: Neil Sleightholm's blog: - http://neilsleightholm.blogspot.com/2009/01/wix-script-for-major-upgrades.ht ml My take on it: - http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8- major-upgrade.aspx One of my responses as well: - http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg16251.html Not to mention WiX.chm: - How To: Implement a Major Upgrade In Your Installer Alex -Original Message- From: John D. Marinuzzi [mailto:nu...@hypack.com] Sent: Wednesday, July 22, 2009 10:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading... Hello, I used WIX to create an installer for our last release of our software. I was using NSIS prior to that, but we had customers who wanted to be to implement installs over a network, so we switched. So, we are at a point where I have to do another release, and I want to be able to 1) Install new if the older version does not exist, and 2) uninstall the older version before installing if it does exist. I have looked at Upgrade and Upgrade codes, etc., but cannot grasp what exactly I have to do. All the attempts I have tried have either given me the already installed error, or installed separate keeping the older version in the programs listing. Any suggestions on a good source to understand this? I have tried the documentation here on the site, but can't seem to figure out if I need new GUIDs or use older ones, etc. Thank You, John -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading SQL Server in Wix
Hi Guys, I wanted to ask the community for any best practices or methods used with the upgrading of SQL Databases through WIX. The install step is fine and pretty straight forward, the upgrade process is messy and I am unsure what scripts will run and when. I did a quick search but wasn't able to find too much regarding the issue. Does anyone have any links to blogs or similar resources on people presenting solutions to the SQL Server upgrade process using wix? I obviously am encountering issues where I will want it to run certain scripts depending on certain versions. Does this mean I can put a Condition on the component such as UPGRADEDVERSION = 1.1.10.0 or something? Thanks, Murray This e-mail and any attachments to it (the Communication) are confidential and are for the use only of the intended recipient. The Communication may contain copyright material of the Snowden Group (Snowden), or any of its related entities or of third parties. If you are not the intended recipient of the Communication, please notify the sender immediately by return e-mail, delete the Communication, and do not copy, print, retransmit, disclose, store or act in reliance on the Communication. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Snowden. Although virus protection devices and procedures are in place, Snowden does not guarantee the integrity of the Communication, or that it is free from errors, viruses or interference. Snowden advises email recipients to carry out their own virus checks before opening any attachment. Please note that the main telephone number for the Snowden Perth office has changed to +61 8 9213 9213. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading SQL Server in Wix
Murray I know there is some stuff if you search through the history of this mailing list. I don't know of any tutorials or other info, but that doesn't mean there isn't any. First what runs in an upgrade is really going to depend on if you are doing an MSI Major Upgrade or Minor Upgrade. If it's a minor upgrade then you can use the ExecuteOnInstall (for install) and ExecuteOnReinstall (for upgrade) flags. If it is a major upgrade then you need to put the scripts into different components (one for install), a different one for upgrade. You then need to condition the components to run when you need. For you question about different versions - then I would say, group them into components and put the conditions on components. An alternate, what we use is that upgrades are actually conditioned in the SQLScripts themselves, based on versions (and alternately GUIDs) being written into a table in the database, so all I rely on WIX for is to execute the install scripts the first time, and upgrade scripts from then on. Michael -Original Message- From: Murray Hipper [mailto:mhip...@snowdengroup.com] Sent: Tuesday, 5 May 2009 3:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading SQL Server in Wix Hi Guys, I wanted to ask the community for any best practices or methods used with the upgrading of SQL Databases through WIX. The install step is fine and pretty straight forward, the upgrade process is messy and I am unsure what scripts will run and when. I did a quick search but wasn't able to find too much regarding the issue. Does anyone have any links to blogs or similar resources on people presenting solutions to the SQL Server upgrade process using wix? I obviously am encountering issues where I will want it to run certain scripts depending on certain versions. Does this mean I can put a Condition on the component such as UPGRADEDVERSION = 1.1.10.0 or something? Thanks, Murray This e-mail and any attachments to it (the Communication) are confidential and are for the use only of the intended recipient. The Communication may contain copyright material of the Snowden Group (Snowden), or any of its related entities or of third parties. If you are not the intended recipient of the Communication, please notify the sender immediately by return e-mail, delete the Communication, and do not copy, print, retransmit, disclose, store or act in reliance on the Communication. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Snowden. Although virus protection devices and procedures are in place, Snowden does not guarantee the integrity of the Communication, or that it is free from errors, viruses or interference. Snowden advises email recipients to carry out their own virus checks before opening any attachment. Please note that the main telephone number for the Snowden Perth office has changed to +61 8 9213 9213. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an older version of product
I am not sure this will work but it is worth a try. Change you v2 upgrade code then add this:Upgrade Id=old upgrade code UpgradeVersion Minimum=0.0.0 Maximum=99.99.32767 IncludeMinimum=yes IncludeMaximum=no Property=REMOVEOLDPRODUCT / /Upgrade What this does is detect any version of the old product and always remove it. Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com mailto:n...@x2systems.com From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com] Sent: Thu 02/04/2009 01:40 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading an older version of product Thanks Phil. Your have hit the bullseye. You are right. I saw the log and it seemed the ALLUSERS property which was the reason. Using ORCA I added ALLUSERS as a new row in the property table and set its value to 1. After that the upgrade worked perfectly. So, now my next question is... Is there any way to remove the older version even if the ALLUSERS property is different for the two versions? The old MSI was created by some other guy and has been deployed to many machines. I have to use ALLUSERS as 1 in my new setup. Is there any way to uninstall the old product? Thanks. Sudripta. Re: [WiX-users] Upgrading an older version of producthttp://sourceforge.net/mailarchive/message.php?msg_name=5C889913FF236E4190093AF280AB4EC40167E7E295%40wwlkfmail1.wonderware.com From: Wilson, Phil phil.wil...@wo... - 2009-04-02 00:09 It's nothing to do with the same user account. It's about the value of the MSI's ALLUSERS property. If you didn't set it before then it defaulted to a per-user install. Your current setup is a per system install with ALLUSERS=1 that will not upgrade the other version. Produce a log while doing the upgrade and see what FindRelatedProducts reports. It's not important that ARPNOMDIFY is different. It is important that ALLUSERS is different. Phil Wilson -Original Message- From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...] Sent: Wednesday, April 01, 2009 4:53 PM To: wix-us...@li... Subject: Re: [WiX-users] Upgrading an older version of product The older version hadn't any ALLUSERS value set. The new version has ALLUSERS set to 1. But, I am installing both the versions from the same user account and it's still failing. One more important aspect is that the older version had 'ARPNOMODIFY' set to 1. But, it hadn't any 'ARPNOREMOVE' property. The new version hasn't got any of the property. Thanks. Sudripta. Re: [WiX-users] Upgrading an older version of producthttp://sourceforge.net/mailarchive/message.php?msg_name=5C889913FF236E4190093AF280AB4EC40167E7E22F%40wwlkfmail1.wonderware.com From: Wilson, Phil phil.wil...@wo... - 2009-04-01 23:38 . and are the ALLUSERS values the same? I believe there's a permachine / perUser choice but the MSI default is per user I believe. Phil Wilson -Original Message- From: Jim Williams [mailto:jimwilliam...@co...] Sent: Wednesday, April 01, 2009 4:21 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Upgrading an older version of product Do you have a RemoveExistingProducts action defined in your execution sequence? Jim Williams -Original Message- From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...] Sent: Wednesday, April 01, 2009 4:03 PM To: wix-us...@li... Subject: [WiX-users] Upgrading an older version of product I have two versions of my MSI... one is version 1.0.0.0 and another is 2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many significant differences between version 1.0.0.0 and 2.0.1000.0, including different install directories and files-to-install. Version 1.0.0.0 installs under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0 except the upgrade code. But, even when the upgrade codes are same, version 2.0.1000.0 is unable to detect the previous version '1.0.0.0'. I have the following element defined within my wix file: Upgrade Id='B5521437-2271-4c41-9F5D-58D4F960874C' UpgradeVersion OnlyDetect='no' Property='PRODUCTOLDVERSIONFOUND' Maximum='2.0.1000.0' IncludeMaximum='no'/ /Upgrade But, seems the old version is not getting removed/replaced by the new version. The new version installs/uninstalls as a separate product. What am I doing wrong? Thanks. Sudripta. -- ___ WiX-users mailing list wix-us...@li... https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list wix-us...@li... https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading an older version of product
I have two versions of my MSI... one is version 1.0.0.0 and another is 2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many significant differences between version 1.0.0.0 and 2.0.1000.0, including different install directories and files-to-install. Version 1.0.0.0 installs under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0 except the upgrade code. But, even when the upgrade codes are same, version 2.0.1000.0 is unable to detect the previous version '1.0.0.0'. I have the following element defined within my wix file: Upgrade Id='B5521437-2271-4c41-9F5D-58D4F960874C' UpgradeVersion OnlyDetect='no' Property='PRODUCTOLDVERSIONFOUND' Maximum='2.0.1000.0' IncludeMaximum='no'/ /Upgrade But, seems the old version is not getting removed/replaced by the new version. The new version installs/uninstalls as a separate product. What am I doing wrong? Thanks. Sudripta. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an older version of product
Do you have a RemoveExistingProducts action defined in your execution sequence? Jim Williams -Original Message- From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com] Sent: Wednesday, April 01, 2009 4:03 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading an older version of product I have two versions of my MSI... one is version 1.0.0.0 and another is 2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many significant differences between version 1.0.0.0 and 2.0.1000.0, including different install directories and files-to-install. Version 1.0.0.0 installs under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0 except the upgrade code. But, even when the upgrade codes are same, version 2.0.1000.0 is unable to detect the previous version '1.0.0.0'. I have the following element defined within my wix file: Upgrade Id='B5521437-2271-4c41-9F5D-58D4F960874C' UpgradeVersion OnlyDetect='no' Property='PRODUCTOLDVERSIONFOUND' Maximum='2.0.1000.0' IncludeMaximum='no'/ /Upgrade But, seems the old version is not getting removed/replaced by the new version. The new version installs/uninstalls as a separate product. What am I doing wrong? Thanks. Sudripta. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an older version of product
. and are the ALLUSERS values the same? I believe there's a permachine / perUser choice but the MSI default is per user I believe. Phil Wilson -Original Message- From: Jim Williams [mailto:jimwilliam...@comcast.net] Sent: Wednesday, April 01, 2009 4:21 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Upgrading an older version of product Do you have a RemoveExistingProducts action defined in your execution sequence? Jim Williams -Original Message- From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com] Sent: Wednesday, April 01, 2009 4:03 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading an older version of product I have two versions of my MSI... one is version 1.0.0.0 and another is 2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many significant differences between version 1.0.0.0 and 2.0.1000.0, including different install directories and files-to-install. Version 1.0.0.0 installs under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0 except the upgrade code. But, even when the upgrade codes are same, version 2.0.1000.0 is unable to detect the previous version '1.0.0.0'. I have the following element defined within my wix file: Upgrade Id='B5521437-2271-4c41-9F5D-58D4F960874C' UpgradeVersion OnlyDetect='no' Property='PRODUCTOLDVERSIONFOUND' Maximum='2.0.1000.0' IncludeMaximum='no'/ /Upgrade But, seems the old version is not getting removed/replaced by the new version. The new version installs/uninstalls as a separate product. What am I doing wrong? Thanks. Sudripta. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an older version of product
Yes, I have the following element defined within InstallExecuteSequence of version 2.0.1000.0. RemoveExistingProducts After=InstallValidate / Another thing is that in the new version of the product, I have completely new components with different IDs. Also the files-to install and the target directory are different. Another important thing is that the product name is also different in the new version. The only similarity between the two versions is the upgrade code. Thanks. Sudripta. Re: [WiX-users] Upgrading an older version of producthttp://sourceforge.net/mailarchive/message.php?msg_name=4D6A40C5D78E4071A707899CDDF5C782%40JIMDELL From: Jim Williams jimwilliam...@co... - 2009-04-01 23:19 Do you have a RemoveExistingProducts action defined in your execution sequence? Jim Williams -Original Message- From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...] Sent: Wednesday, April 01, 2009 4:03 PM To: wix-us...@li... Subject: [WiX-users] Upgrading an older version of product I have two versions of my MSI... one is version 1.0.0.0 and another is 2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many significant differences between version 1.0.0.0 and 2.0.1000.0, including different install directories and files-to-install. Version 1.0.0.0 installs under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0 except the upgrade code. But, even when the upgrade codes are same, version 2.0.1000.0 is unable to detect the previous version '1.0.0.0'. I have the following element defined within my wix file: Upgrade Id='B5521437-2271-4c41-9F5D-58D4F960874C' UpgradeVersion OnlyDetect='no' Property='PRODUCTOLDVERSIONFOUND' Maximum='2.0.1000.0' IncludeMaximum='no'/ /Upgrade But, seems the old version is not getting removed/replaced by the new version. The new version installs/uninstalls as a separate product. What am I doing wrong? Thanks. Sudripta. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an older version of product
The older version hadn't any ALLUSERS value set. The new version has ALLUSERS set to 1. But, I am installing both the versions from the same user account and it's still failing. One more important aspect is that the older version had 'ARPNOMODIFY' set to 1. But, it hadn't any 'ARPNOREMOVE' property. The new version hasn't got any of the property. Thanks. Sudripta. Re: [WiX-users] Upgrading an older version of producthttp://sourceforge.net/mailarchive/message.php?msg_name=5C889913FF236E4190093AF280AB4EC40167E7E22F%40wwlkfmail1.wonderware.com From: Wilson, Phil phil.wil...@wo... - 2009-04-01 23:38 . and are the ALLUSERS values the same? I believe there's a permachine / perUser choice but the MSI default is per user I believe. Phil Wilson -Original Message- From: Jim Williams [mailto:jimwilliam...@co...] Sent: Wednesday, April 01, 2009 4:21 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Upgrading an older version of product Do you have a RemoveExistingProducts action defined in your execution sequence? Jim Williams -Original Message- From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...] Sent: Wednesday, April 01, 2009 4:03 PM To: wix-us...@li... Subject: [WiX-users] Upgrading an older version of product I have two versions of my MSI... one is version 1.0.0.0 and another is 2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many significant differences between version 1.0.0.0 and 2.0.1000.0, including different install directories and files-to-install. Version 1.0.0.0 installs under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0 except the upgrade code. But, even when the upgrade codes are same, version 2.0.1000.0 is unable to detect the previous version '1.0.0.0'. I have the following element defined within my wix file: Upgrade Id='B5521437-2271-4c41-9F5D-58D4F960874C' UpgradeVersion OnlyDetect='no' Property='PRODUCTOLDVERSIONFOUND' Maximum='2.0.1000.0' IncludeMaximum='no'/ /Upgrade But, seems the old version is not getting removed/replaced by the new version. The new version installs/uninstalls as a separate product. What am I doing wrong? Thanks. Sudripta. -- ___ WiX-users mailing list wix-us...@li... https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list wix-us...@li... https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an older version of product
Hi Have you remembered to add SecureCustomProperties to your property table? (Or does candle/light do that for you??) K. Yes, I have the following element defined within InstallExecuteSequence of version 2.0.1000.0. Another thing is that in the new version of the product, I have completely new components with different IDs. Also the files-to install and the target directory are different. Another important thing is that the product name is also different in the new version. The only similarity between the two versions is the upgrade code. Thanks. Sudripta. -- View this message in context: http://n2.nabble.com/Upgrading-an-older-version-of-product-tp2572133p2572316.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading an older version of product
Thanks Phil. Your have hit the bullseye. You are right. I saw the log and it seemed the ALLUSERS property which was the reason. Using ORCA I added ALLUSERS as a new row in the property table and set its value to 1. After that the upgrade worked perfectly. So, now my next question is... Is there any way to remove the older version even if the ALLUSERS property is different for the two versions? The old MSI was created by some other guy and has been deployed to many machines. I have to use ALLUSERS as 1 in my new setup. Is there any way to uninstall the old product? Thanks. Sudripta. Re: [WiX-users] Upgrading an older version of producthttp://sourceforge.net/mailarchive/message.php?msg_name=5C889913FF236E4190093AF280AB4EC40167E7E295%40wwlkfmail1.wonderware.com From: Wilson, Phil phil.wil...@wo... - 2009-04-02 00:09 It's nothing to do with the same user account. It's about the value of the MSI's ALLUSERS property. If you didn't set it before then it defaulted to a per-user install. Your current setup is a per system install with ALLUSERS=1 that will not upgrade the other version. Produce a log while doing the upgrade and see what FindRelatedProducts reports. It's not important that ARPNOMDIFY is different. It is important that ALLUSERS is different. Phil Wilson -Original Message- From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...] Sent: Wednesday, April 01, 2009 4:53 PM To: wix-us...@li... Subject: Re: [WiX-users] Upgrading an older version of product The older version hadn't any ALLUSERS value set. The new version has ALLUSERS set to 1. But, I am installing both the versions from the same user account and it's still failing. One more important aspect is that the older version had 'ARPNOMODIFY' set to 1. But, it hadn't any 'ARPNOREMOVE' property. The new version hasn't got any of the property. Thanks. Sudripta. Re: [WiX-users] Upgrading an older version of producthttp://sourceforge.net/mailarchive/message.php?msg_name=5C889913FF236E4190093AF280AB4EC40167E7E22F%40wwlkfmail1.wonderware.com From: Wilson, Phil phil.wil...@wo... - 2009-04-01 23:38 . and are the ALLUSERS values the same? I believe there's a permachine / perUser choice but the MSI default is per user I believe. Phil Wilson -Original Message- From: Jim Williams [mailto:jimwilliam...@co...] Sent: Wednesday, April 01, 2009 4:21 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Upgrading an older version of product Do you have a RemoveExistingProducts action defined in your execution sequence? Jim Williams -Original Message- From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...] Sent: Wednesday, April 01, 2009 4:03 PM To: wix-us...@li... Subject: [WiX-users] Upgrading an older version of product I have two versions of my MSI... one is version 1.0.0.0 and another is 2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many significant differences between version 1.0.0.0 and 2.0.1000.0, including different install directories and files-to-install. Version 1.0.0.0 installs under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0 except the upgrade code. But, even when the upgrade codes are same, version 2.0.1000.0 is unable to detect the previous version '1.0.0.0'. I have the following element defined within my wix file: Upgrade Id='B5521437-2271-4c41-9F5D-58D4F960874C' UpgradeVersion OnlyDetect='no' Property='PRODUCTOLDVERSIONFOUND' Maximum='2.0.1000.0' IncludeMaximum='no'/ /Upgrade But, seems the old version is not getting removed/replaced by the new version. The new version installs/uninstalls as a separate product. What am I doing wrong? Thanks. Sudripta. -- ___ WiX-users mailing list wix-us...@li... https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list wix-us...@li... https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list wix-us...@li... https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading ...Not happening
Hi Thanks for reply. I refered the link send by you. first thing I don't want major upgrade. But still I tried with major upgrade also. But it didn't work. same error as Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs in Control Panel. I set all the property values also.But not worked. Please help. I just want to do minor upgrade. Thanks Regards, Hukum On Sat, Mar 21, 2009 at 2:18 PM, Neil Sleightholm n...@x2systems.comwrote: Are you changing Product/@Id on each build? There is an example of a major upgrade script here: http://neilsleightholm.blogspot.com/2009/01/wix-script-for-major-upgrade s.htmlhttp://neilsleightholm.blogspot.com/2009/01/wix-script-for-major-upgrade%0As.html Neil -Original Message- From: Hukumchand Shah [mailto:hukum.s...@gmail.com] Sent: 21 March 2009 07:27 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Upgrading ...Not happening Hi All, I want to do upgrade in my current WIX installer. I am changing the Version shown below. Product Id=1805F899-4BF7-49aa-860C-EE258C191D97 Language=1033 Manufacturer=ABC Name=ABCD Version=1.0.1.0UpgradeCode=$(var.UpgradeGUID) Package InstallerVersion=300 Compressed=yes / and also adding the upgrade element: Property Id=PRODUCT.UPGRADE Secure=yes / Property Id=PRODUCT.DOWNGRADE Secure=yes / Upgrade Id=$(var.UpgradeGUID) UpgradeVersion Maximum=1.0.1.0 Property=PRODUCT.UPGRADE IncludeMaximum=no OnlyDetect=no RemoveFeatures=all/ UpgradeVersion Minimum=1.0.0.0 Property=PRODUCT.DOWNGRADE IncludeMinimum=no OnlyDetect=no/ /Upgrade But when I make .msi and run it by double clicking then it shows error meaasge attached with mail. I also checked the log files, it's showing PRODUCT.UPGRADE and PRODUCT.DOWNGRADE properties empty or nothing. Also please tell me, when I will run upgrade msi then it will run same as without upgrade msi or what it will show while running? Please give me solution. I am waiting for solution. Thanks Regards, Hukum -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading ...Not happening
Hi All, I want to do upgrade in my current WIX installer. I am changing the Version shown below. Product Id=1805F899-4BF7-49aa-860C-EE258C191D97 Language=1033 Manufacturer=ABC Name=ABCD Version=1.0.1.0UpgradeCode=$(var.UpgradeGUID) Package InstallerVersion=300 Compressed=yes / and also adding the upgrade element: Property Id=PRODUCT.UPGRADE Secure=yes / Property Id=PRODUCT.DOWNGRADE Secure=yes / Upgrade Id=$(var.UpgradeGUID) UpgradeVersion Maximum=1.0.1.0 Property=PRODUCT.UPGRADE IncludeMaximum=no OnlyDetect=no RemoveFeatures=all/ UpgradeVersion Minimum=1.0.0.0 Property=PRODUCT.DOWNGRADE IncludeMinimum=no OnlyDetect=no/ /Upgrade But when I make .msi and run it by double clicking then it shows error meaasge attached with mail. I also checked the log files, it's showing PRODUCT.UPGRADE and PRODUCT.DOWNGRADE properties empty or nothing. Also please tell me, when I will run upgrade msi then it will run same as without upgrade msi or what it will show while running? Please give me solution. I am waiting for solution. Thanks Regards, Hukum -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading ...Not happening
Are you changing Product/@Id on each build? There is an example of a major upgrade script here: http://neilsleightholm.blogspot.com/2009/01/wix-script-for-major-upgrade s.html Neil -Original Message- From: Hukumchand Shah [mailto:hukum.s...@gmail.com] Sent: 21 March 2009 07:27 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Upgrading ...Not happening Hi All, I want to do upgrade in my current WIX installer. I am changing the Version shown below. Product Id=1805F899-4BF7-49aa-860C-EE258C191D97 Language=1033 Manufacturer=ABC Name=ABCD Version=1.0.1.0UpgradeCode=$(var.UpgradeGUID) Package InstallerVersion=300 Compressed=yes / and also adding the upgrade element: Property Id=PRODUCT.UPGRADE Secure=yes / Property Id=PRODUCT.DOWNGRADE Secure=yes / Upgrade Id=$(var.UpgradeGUID) UpgradeVersion Maximum=1.0.1.0 Property=PRODUCT.UPGRADE IncludeMaximum=no OnlyDetect=no RemoveFeatures=all/ UpgradeVersion Minimum=1.0.0.0 Property=PRODUCT.DOWNGRADE IncludeMinimum=no OnlyDetect=no/ /Upgrade But when I make .msi and run it by double clicking then it shows error meaasge attached with mail. I also checked the log files, it's showing PRODUCT.UPGRADE and PRODUCT.DOWNGRADE properties empty or nothing. Also please tell me, when I will run upgrade msi then it will run same as without upgrade msi or what it will show while running? Please give me solution. I am waiting for solution. Thanks Regards, Hukum -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading...
I am getting some very odd behaviour when trying to test upgrading my product. Up until now I've just uninstalled the previous version before installing the new version. But now I'm trying to actually upgrade, and what I'm getting is a little bit baffling. Just to test the upgrade, I'm only changing my .wxs file (and my executable's assembly version) and then remaking my msi. I have it so that I can install one version of my package, then change the version in the .wxs file, rebuild the msi and install that. All seemed well at first. Then I realized that I had BOTH versions of my package in the ARP list - and it seems that the install system was using reference counting on the files because they didn't disappear until both ARP versions were removed. What I WANT to happen is that the old version gets removed and the new version is installed in it's place. I realize that this is where UpgradeCode comes in, and also http://www.tramontana.co.hu/wix/lesson4.php . What I don't understand is the actual meaning of the upgrade code. Is the upgrade code meant to stay the same between versions, so that the installer knows what it's upgrading? Or is it supposed to be different, so it knows that there is some kind of change? I can't find documents actually explaining what these tags and attributes mean and how they relate, just a tutorial that talks about one particular use of them. And the tutorial actually makes it a little more confusing - I had assumed that if older versions of the same product existed I could say to remove those, but I have to list them explicitly? -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
MSI SDK about Major Upgrades (and others) has pretty much step by step instructions when the various GUIDs change. It is very terse reading, so it takes a few times to get all the pieces but that data is there. The way I think about it, Upgrade code is a family marker. The Upgrade code draws a line through the products so that the Upgrade table and FindExistingProducts action can associate them with each other. -Original Message- From: Colin Fox [mailto:greenene...@gmail.com] Sent: Tuesday, January 20, 2009 10:04 To: wix-users Subject: [WiX-users] Upgrading... I am getting some very odd behaviour when trying to test upgrading my product. Up until now I've just uninstalled the previous version before installing the new version. But now I'm trying to actually upgrade, and what I'm getting is a little bit baffling. Just to test the upgrade, I'm only changing my .wxs file (and my executable's assembly version) and then remaking my msi. I have it so that I can install one version of my package, then change the version in the .wxs file, rebuild the msi and install that. All seemed well at first. Then I realized that I had BOTH versions of my package in the ARP list - and it seems that the install system was using reference counting on the files because they didn't disappear until both ARP versions were removed. What I WANT to happen is that the old version gets removed and the new version is installed in it's place. I realize that this is where UpgradeCode comes in, and also http://www.tramontana.co.hu/wix/lesson4.php . What I don't understand is the actual meaning of the upgrade code. Is the upgrade code meant to stay the same between versions, so that the installer knows what it's upgrading? Or is it supposed to be different, so it knows that there is some kind of change? I can't find documents actually explaining what these tags and attributes mean and how they relate, just a tutorial that talks about one particular use of them. And the tutorial actually makes it a little more confusing - I had assumed that if older versions of the same product existed I could say to remove those, but I have to list them explicitly? -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading components marked as permanent
Our product includes a TAPI Service Provider (TSP) that requires that it be installed to System32. I have read that if a file is installed in System32 it should be marked as permanent. I have made updates to our TSP but the installer won't upgrade the version that is installed. Is there a way to upgrade my permanent TSP? John -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading components marked as permanent
The permanent setting should still allow updates based on file version. Hopefully you didn't set the never overwrite flag. Phil Wilson -Original Message- From: John Lalande [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2008 12:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading components marked as permanent Our product includes a TAPI Service Provider (TSP) that requires that it be installed to System32. I have read that if a file is installed in System32 it should be marked as permanent. I have made updates to our TSP but the installer won't upgrade the version that is installed. Is there a way to upgrade my permanent TSP? John -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading multiple versions of a product
Hi again, I'm running into trouble when I'm trying to install/remove/install a patch which applies to multiple versions of a product. Here's a snippet from the WXS for the patch in question: (Imagine I'm upgrading product Foo to version C. Version A and B exist in the wild.) UpgradeImage src=\Path\To\FooC.msi Id=UpdateFoo TargetImage src=\Path\To\FooA.msi Order=1 Id=FooA IgnoreMissingFiles=no Validation = 0x08A2 / TargetImage src=\Path\To\FooB.msi Order=2 Id=FooB IgnoreMissingFiles=no Validation = 0x08A2 / /UpgradeImage Now let's say I apply the patch to an installed copy of version B. The patch will apply and remove successfully, I can even reapply the patch. Next let's say I apply the patch to an installed copy of version A. The patch will apply and remove successfully again, but this time I cannot reapply the patch. (OK so it obviously doesn't look like it removed successfully.) Can anyone shed some light on why this is happening? I notice that if I change the order numbers then it changes which version can be correctly uninstalled, so I imagine that when I try to remove the changes from version A it is repealing the changes as though it were version B... if so how can I work around this? Thanks for any insight, Alex - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading
hmmm What about a component search, if it finds the product it fills the keypath?? Ive read this but am unsure on how to execute this my self thanks Bob Arnson-6 wrote: Craig0ss wrote: I need my MSI to check for an existing install of the software ie. 5.2.1, now it does this fine, however i also need it to check for the existing directory and then pass that information to a variable that the installer then sets the installer to install to. Basically i need the upgrade to install to the directory that the previous installation resides in? Write the directory to the registry so the upgraded version can find it using RegistrySearch. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/Upgrading-tf4751110.html#a13605528 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading
Craig0ss wrote: What about a component search, if it finds the product it fills the keypath?? Should work. I've never tried it. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading
Hi guys Ive read alot of other posts regarding upgrading but ive yet to find any information relavent to my situation, so if anyone knows of any threads and have the links to them then please post. Here is what i want to do I need my MSI to check for an existing install of the software ie. 5.2.1, now it does this fine, however i also need it to check for the existing directory and then pass that information to a variable that the installer then sets the installer to install to. Basically i need the upgrade to install to the directory that the previous installation resides in? Any ideas Thanks Craig0ss -- View this message in context: http://www.nabble.com/Upgrading-tf4751110.html#a13585390 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading
Craig0ss wrote: I need my MSI to check for an existing install of the software ie. 5.2.1, now it does this fine, however i also need it to check for the existing directory and then pass that information to a variable that the installer then sets the installer to install to. Basically i need the upgrade to install to the directory that the previous installation resides in? Write the directory to the registry so the upgraded version can find it using RegistrySearch. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading
From: Craig0ss Sent: Monday, November 05, 2007 12:01 PM Ive read alot of other posts regarding upgrading but ive yet to find any information relavent to my situation, so if anyone knows of any threads and have the links to them then please post. Here is what i want to do I need my MSI to check for an existing install of the software ie. 5.2.1, now it does this fine, however i also need it to check for the existing directory and then pass that information to a variable that the installer then sets the installer to install to. Basically i need the upgrade to install to the directory that the previous installation resides in? Any ideas Discussed here just the other day. See http://sourceforge.net/mailarchive/message.php?msg_name=OFF5E86288.1900F763-ON88257387.004CFDBD-88257387.004D795F%40milliman.com for a few ways to do this. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading Publisher Policy Files in Merge Modules
Is there any trick to this ... ? We've got a merge module that is used by a couple of other groups, and while the assemblies get installed to the GAC properly ... when upgraded assemblies policy files get shipped, the policy files don't seem to upgrade properly. Thanks in advance, -dmm -- View this message in context: http://www.nabble.com/Upgrading-Publisher-Policy-Files-in-Merge-Modules-tf3633507.html#a10146299 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading Publisher Policy Files in Merge Modules
Publisher policy assemblies are also versioned. You must increase the version number of the policy assembly for it to be added to the GAC in addition to the version already there. There are rules on the naming of the publisher policy assembly - if I recall correctly, the major.minor of the policy assembly must match the major.minor of the assembly you're trying to redirect. You're free to set build.revision to whatever you like IIRC. Publisher policy is a very blunt instrument and should only be used if your clients absolutely must be redirected to the latest version - perhaps your assemblies don't work properly if a mixed set are loaded in the same process, or even don't work properly if a mixed set are loaded in multiple processes at the same time. You might also do this if you were fixing a security bug. Generally, though, you're expected *not* to force clients to load a different version than they were built with. (An .exe.config file can still override publisher policy if required). If you want to upgrade a GAC assembly without changing the assembly version (only the file version number), you can do this by specifying FileVersion in the MsiAssemblyName table, which you do in WiX by passing the -fv switch to light. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DexterSinister Sent: 23 April 2007 19:45 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading Publisher Policy Files in Merge Modules Is there any trick to this ... ? We've got a merge module that is used by a couple of other groups, and while the assemblies get installed to the GAC properly ... when upgraded assemblies policy files get shipped, the policy files don't seem to upgrade properly. Thanks in advance, -dmm -- View this message in context: http://www.nabble.com/Upgrading-Publisher-Policy-Files-in-Merge-Modules-tf36 33507.html#a10146299 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading Publisher Policy Files in Merge Modules
The policy config file should have a file version entry pointing to the policy assembly Dll (companion files) to make sure that the config file piece of the assembly (it's a multi-file assembly) is also installed when the Dll is installed (updated in this case). (I assume you've got them both in the same component.) Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DexterSinister Sent: Monday, April 23, 2007 11:45 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading Publisher Policy Files in Merge Modules Is there any trick to this ... ? We've got a merge module that is used by a couple of other groups, and while the assemblies get installed to the GAC properly ... when upgraded assemblies policy files get shipped, the policy files don't seem to upgrade properly. Thanks in advance, -dmm -- View this message in context: http://www.nabble.com/Upgrading-Publisher-Policy-Files-in-Merge-Modules- tf3633507.html#a10146299 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading Publisher Policy Files in Merge Modules
Mike, Phil - Thanks for the quick responses ! After some more testing, it appears to be a problem with how InstallShield is consuming the merge modules ... not with how they're built. Insert shocked look here ... Now I just need to convince another development group to use WiX ... Regards, -dmm -- View this message in context: http://www.nabble.com/Upgrading-Publisher-Policy-Files-in-Merge-Modules-tf3633507.html#a10148968 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading to v3 and Vista...
Two answers: 1) use quot; in your xml, that should evauluate to at runtime. 4)you have to put in ICE64, not just 64. If you look at the build output, you can see the command lines that get generated for light and candle. If you look there, you'll see that the ICE you put in that field is being passed in as /sice:64 instead of /sice:ICE64, which is what you want. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Watts Sent: Sunday, January 28, 2007 12:28 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading to v3 and Vista... Hi there, First of all, Votive v3 and the error messages that come from v3 of light/etc. are fantastic. That and the mailing list archives allowed me to answer most of my questions. Kudos! A few issues/questions remain. 1) I'd like to convert the following to the new RegistryValue wix element, but I'm not sure how to deal with the double-quotes in my CDATA: Registry Action=write Id=TortCVSSHArgs Key=Software\TortoiseCVS Name=External SSH Params Type=string Root=HKLM RegistryValue![CDATA[-o StrictHostKeyChecking no -2 -l %u %h]]/RegistryValue /Registry Is there some obvious format, or a way to continue to use the CDATA specification? 2) This used to work on windows XP and v2 of WiX. I have a custom action which I schedule to run Before the InstalFinalize. This custom action (deferred) runs an executable that I've installed. When I run the installer it bombs because the file hasn't been copied to its final location. When I look at the verbose log file I see that, indeed, the FileCopy operation seems to be executed only after the InstallFinalize action is started. I want this guy to run deferred because it needs elevated privs, but if I do run it deferred then I have to run it before the InstallFinalize. I'm sensing a catch-22 here... So, what can I do to get around this? 3) In converting my wix source over to v3 I had the same problem lots of other people seem to have had with short cuts. I moved almost all my shortcuts over to be advertised. Much to my surprise, they just worked. Both in non-admin and admin worlds. Neat. We'll see if they survie deployment in a Terminal Server environment! But, there is one short cut I can't crack. This is a short cut to cmd.exe. It executes a script as an argument. So it isn't really associated with a file I install, and so (as far as I understand) can't be advertised. However, one of its command line arguments is a file that I do install. Originally that file and this shortcut were in the same component but I got the system and user profile items in same component: use registry value in HKCU as key path. There was a great email that explained to me (at least) why this should be avoided, so I moved it into a second component. Now, however..., I am getting the warning ICE69: cross component reference (bad because if a component isn't installed during upgrade the reference may evaluate to null -- that would be bad if the shortcut to cmd was made and didn't reference anything!). What is the proper method to fix this? Is there a way to advertise a shortcut like this? 4) At one point I experimented with ignoring warnings/errors in the IDE. Specifically, I wanted light to ignore ICE64 (which is an error). When I entered 64 in suppress warnings this didn't alter behavior. Is this expected behavior because this is an error? Thanks a lot in advance for any help! Cheers, Gordon. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Upgrading to v3 and Vista...
Hi there, First of all, Votive v3 and the error messages that come from v3 of light/etc. are fantastic. That and the mailing list archives allowed me to answer most of my questions. Kudos! A few issues/questions remain. 1) I'd like to convert the following to the new RegistryValue wix element, but I'm not sure how to deal with the double-quotes in my CDATA: Registry Action=write Id=TortCVSSHArgs Key=Software\TortoiseCVS Name=External SSH Params Type=string Root=HKLM RegistryValue![CDATA[-o StrictHostKeyChecking no -2 -l %u %h]]/RegistryValue /Registry Is there some obvious format, or a way to continue to use the CDATA specification? 2) This used to work on windows XP and v2 of WiX. I have a custom action which I schedule to run Before the InstalFinalize. This custom action (deferred) runs an executable that I've installed. When I run the installer it bombs because the file hasn't been copied to its final location. When I look at the verbose log file I see that, indeed, the FileCopy operation seems to be executed only after the InstallFinalize action is started. I want this guy to run deferred because it needs elevated privs, but if I do run it deferred then I have to run it before the InstallFinalize. I'm sensing a catch-22 here... So, what can I do to get around this? 3) In converting my wix source over to v3 I had the same problem lots of other people seem to have had with short cuts. I moved almost all my shortcuts over to be advertised. Much to my surprise, they just worked. Both in non-admin and admin worlds. Neat. We'll see if they survie deployment in a Terminal Server environment! But, there is one short cut I can't crack. This is a short cut to cmd.exe. It executes a script as an argument. So it isn't really associated with a file I install, and so (as far as I understand) can't be advertised. However, one of its command line arguments is a file that I do install. Originally that file and this shortcut were in the same component but I got the system and user profile items in same component: use registry value in HKCU as key path. There was a great email that explained to me (at least) why this should be avoided, so I moved it into a second component. Now, however..., I am getting the warning ICE69: cross component reference (bad because if a component isn't installed during upgrade the reference may evaluate to null -- that would be bad if the shortcut to cmd was made and didn't reference anything!). What is the proper method to fix this? Is there a way to advertise a shortcut like this? 4) At one point I experimented with ignoring warnings/errors in the IDE. Specifically, I wanted light to ignore ICE64 (which is an error). When I entered 64 in suppress warnings this didn't alter behavior. Is this expected behavior because this is an error? Thanks a lot in advance for any help! Cheers, Gordon. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading not doing anything
Aaron Feng wrote: MSI (s) (80:D4) [09:18:15:862]: Feature: Client; Installed: Advertise; Request: Reinstall; Action: Reinstall This indicates what is probably the root of the problem. Features marked as advertised aren't actually installed on the machine so an upgrade doesn't do anything. So the question becomes: Why is the feature advertised? A common cause is a feature that had components removed -- that's not supported except via a major upgrade. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading not doing anything
Bob, Just for my understanding, what does Featuring marked as advertised mean? Thanx, Aaron On 1/4/07, Bob Arnson [EMAIL PROTECTED] wrote: Aaron Feng wrote: MSI (s) (80:D4) [09:18:15:862]: Feature: Client; Installed: Advertise; Request: Reinstall; Action: Reinstall This indicates what is probably the root of the problem. Features marked as advertised aren't actually installed on the machine so an upgrade doesn't do anything. So the question becomes: Why is the feature advertised? A common cause is a feature that had components removed -- that's not supported except via a major upgrade. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
