Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades
Hi Rob, On Thu, Mar 26, 2015 at 12:27 AM, Rob Mensching r...@firegiant.com wrote: Schedule your upgrade late and carefully adhere to the Component Rules. Thanks for the hint. I googled a bit and read up things on MajorUpgrade scheduling [0] and Component Rules, including [1] and [2]. So I've tried scheduling the upgrade later. Specifically I've added Schedule=afterInstallExecute to the MajorUpgrade, see [4]. Now it seems to first overwrite the existing installation and then runs the uninstall process. The shortcut and pinned task bar icons are retained. However the uninstall progress removes the overwritten files so that the shortcut points to a broken installation. Why does it remove the now newer version installation files during uninstall? I expected MSI to know that the files in the program folder are of a newer installation when it starts the uninstall process and only deletes files which haven't been replaced during installation. Thanks in advance for any pointers and hints. Cheers, Tobias [0] http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html [1] http://robmensching.com/blog/posts/2003/10/4/windows-installer-components-introduction/ [2] http://robmensching.com/blog/posts/2003/10/18/component-rules-101/ [3] https://dl.dropboxusercontent.com/u/14672346/tmp/swift/swift_wix_install_msi_log.txt [4] https://github.com/swift/swift/blob/master/Swift/Packaging/WiX/Swift.wxs#L13 -- 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] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades
Hi Phil, On Thu, Mar 26, 2015 at 4:22 PM, Phil Wilson phildgwil...@gmail.com wrote: An early sequencing of the upgrade (such as after InstallIntialize) is more or less the same as uninstalling the old product then installing the new one. Guids don't really matter much. After InstallExecute isn't like that. As an example: say every file has a guid and a version or hash. The guid is reference counted up at install time. Installing the new product after InstallExecute means installing new files over old files following file replacement rules (versions, hashes etc) and incrementing the ref count for the guids being installed (which matters only for files in the same location). Then uninstall the old product, counting down its guid ref counts. If all the files are the same and have matching guids then they all ref count down to one and the files stay behind. If you don't follow component rules then you install different guids even though they have the same file name. When the old product is uninstalled those guids count down to zero and the files are removed even though you just installed them. Sometimes it helps to think of it all as installing ref counted guids, not files, registry entries etc. This may be what you're seeing. So in this case there is no newer installation, there are only file replacement rules, and guids that are no longer in use being deleted, so the same guids must be used for the same files for this type of upgrade to be successful. The same is true of patches, minor upgrades. Thanks for this hint. I've opened the old version .msi and the new version .msi in Orca and indeed, the GUIDs were different for most files. As it happens our WiX code uses Heat to gather the list of files to install, which happens to generate the WiX XML for the components. We happen to use the options -nologo -gg -sfrag -suid -template fragment -dr ProgramFilesFolder when calling heat.exe, and according to documentation -gg generates new GUIDs. This at least explains the current behavior. Should I remove the -gg option parameter? Is there a way to have the GUID based on hash(project_name + filename_)? Cheers, Tobias -- 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] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades
If you just leave them alone WiX should generate stable GUID's for you assuming you don't rename them/change the paths( see -ag). I would not advise using heat for anything other than an initial generation of the WXS file. -Original Message- From: Tobias Markmann [mailto:tmarkm...@googlemail.com] Sent: Thursday, March 26, 2015 11:25 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades Hi Phil, On Thu, Mar 26, 2015 at 4:22 PM, Phil Wilson phildgwil...@gmail.com wrote: An early sequencing of the upgrade (such as after InstallIntialize) is more or less the same as uninstalling the old product then installing the new one. Guids don't really matter much. After InstallExecute isn't like that. As an example: say every file has a guid and a version or hash. The guid is reference counted up at install time. Installing the new product after InstallExecute means installing new files over old files following file replacement rules (versions, hashes etc) and incrementing the ref count for the guids being installed (which matters only for files in the same location). Then uninstall the old product, counting down its guid ref counts. If all the files are the same and have matching guids then they all ref count down to one and the files stay behind. If you don't follow component rules then you install different guids even though they have the same file name. When the old product is uninstalled those guids count down to zero and the files are removed even though you just installed them. Sometimes it helps to think of it all as installing ref counted guids, not files, registry entries etc. This may be what you're seeing. So in this case there is no newer installation, there are only file replacement rules, and guids that are no longer in use being deleted, so the same guids must be used for the same files for this type of upgrade to be successful. The same is true of patches, minor upgrades. Thanks for this hint. I've opened the old version .msi and the new version .msi in Orca and indeed, the GUIDs were different for most files. As it happens our WiX code uses Heat to gather the list of files to install, which happens to generate the WiX XML for the components. We happen to use the options -nologo -gg -sfrag -suid -template fragment -dr ProgramFilesFolder when calling heat.exe, and according to documentation -gg generates new GUIDs. This at least explains the current behavior. Should I remove the -gg option parameter? Is there a way to have the GUID based on hash(project_name + filename_)? Cheers, Tobias -- 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] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades
Sounds like you broke component rules somewhere... Are your component ID's identical for the same files across MSI's? Are you using version info on the files in question, or is it falling back to timestamp and hash checking? -Original Message- From: Tobias Markmann [mailto:tmarkm...@googlemail.com] Sent: Thursday, March 26, 2015 7:08 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades Hi Rob, On Thu, Mar 26, 2015 at 12:27 AM, Rob Mensching r...@firegiant.com wrote: Schedule your upgrade late and carefully adhere to the Component Rules. Thanks for the hint. I googled a bit and read up things on MajorUpgrade scheduling [0] and Component Rules, including [1] and [2]. So I've tried scheduling the upgrade later. Specifically I've added Schedule=afterInstallExecute to the MajorUpgrade, see [4]. Now it seems to first overwrite the existing installation and then runs the uninstall process. The shortcut and pinned task bar icons are retained. However the uninstall progress removes the overwritten files so that the shortcut points to a broken installation. Why does it remove the now newer version installation files during uninstall? I expected MSI to know that the files in the program folder are of a newer installation when it starts the uninstall process and only deletes files which haven't been replaced during installation. Thanks in advance for any pointers and hints. Cheers, Tobias [0] http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html [1] http://robmensching.com/blog/posts/2003/10/4/windows-installer-components-introduction/ [2] http://robmensching.com/blog/posts/2003/10/18/component-rules-101/ [3] https://dl.dropboxusercontent.com/u/14672346/tmp/swift/swift_wix_install_msi_log.txt [4] https://github.com/swift/swift/blob/master/Swift/Packaging/WiX/Swift.wxs#L13 -- 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] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades
An early sequencing of the upgrade (such as after InstallIntialize) is more or less the same as uninstalling the old product then installing the new one. Guids don't really matter much. After InstallExecute isn't like that. As an example: say every file has a guid and a version or hash. The guid is reference counted up at install time. Installing the new product after InstallExecute means installing new files over old files following file replacement rules (versions, hashes etc) and incrementing the ref count for the guids being installed (which matters only for files in the same location). Then uninstall the old product, counting down its guid ref counts. If all the files are the same and have matching guids then they all ref count down to one and the files stay behind. If you don't follow component rules then you install different guids even though they have the same file name. When the old product is uninstalled those guids count down to zero and the files are removed even though you just installed them. Sometimes it helps to think of it all as installing ref counted guids, not files, registry entries etc. This may be what you're seeing. So in this case there is no newer installation, there are only file replacement rules, and guids that are no longer in use being deleted, so the same guids must be used for the same files for this type of upgrade to be successful. The same is true of patches, minor upgrades. --- Phil Wilson On Thu, Mar 26, 2015 at 7:47 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Sounds like you broke component rules somewhere... Are your component ID's identical for the same files across MSI's? Are you using version info on the files in question, or is it falling back to timestamp and hash checking? -Original Message- From: Tobias Markmann [mailto:tmarkm...@googlemail.com] Sent: Thursday, March 26, 2015 7:08 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades Hi Rob, On Thu, Mar 26, 2015 at 12:27 AM, Rob Mensching r...@firegiant.com wrote: Schedule your upgrade late and carefully adhere to the Component Rules. Thanks for the hint. I googled a bit and read up things on MajorUpgrade scheduling [0] and Component Rules, including [1] and [2]. So I've tried scheduling the upgrade later. Specifically I've added Schedule=afterInstallExecute to the MajorUpgrade, see [4]. Now it seems to first overwrite the existing installation and then runs the uninstall process. The shortcut and pinned task bar icons are retained. However the uninstall progress removes the overwritten files so that the shortcut points to a broken installation. Why does it remove the now newer version installation files during uninstall? I expected MSI to know that the files in the program folder are of a newer installation when it starts the uninstall process and only deletes files which haven't been replaced during installation. Thanks in advance for any pointers and hints. Cheers, Tobias [0] http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html [1] http://robmensching.com/blog/posts/2003/10/4/windows-installer-components-introduction/ [2] http://robmensching.com/blog/posts/2003/10/18/component-rules-101/ [3] https://dl.dropboxusercontent.com/u/14672346/tmp/swift/swift_wix_install_msi_log.txt [4] https://github.com/swift/swift/blob/master/Swift/Packaging/WiX/Swift.wxs#L13 -- 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 -- 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
Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades
Schedule your upgrade late and carefully adhere to the Component Rules. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Tobias Markmann [mailto:tmarkm...@googlemail.com] Sent: Wednesday, March 25, 2015 4:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades Hi, I'm currently trying to fix remaining issues in our WiX-based installer. The current issue I'm trying to fix is WiX/MSI behavior when upgrading an installation. Upgrading mostly does an uninstallation of the previous version and installs the new version. This automatically means that shortcuts of the old version are deleted and new shortcuts installed. This process has two issues: 1. If the user has pinned an application to the task bar, the deinstallation will result in a broken shortcut in the task bar. 2. The position of desktop shortcuts is lost because the desktop shortcut is deleted and a new one is installed. (I don't use desktop shortcuts yet.) I've tried some hacks/workarounds found on the internet. None of them worked for me. Last change I tried is using MajorUpgrade RemoveFeatures=Core ... /, with 'Core' describing all features except the shortcuts. This basically worked, pinned shortcuts still worked. However, there is the ugly side effect that the old version is still registered under Programs Features, probably because I told to keep the shortcuts. How do you handle this issue? Is there a way to migrate the old version Shortcuts to the newer version Shortcuts? Is there some diff method, so MSI detects that the upgrade will basically setup the same shortcuts so that it won't remove them in the first place. Thanks for any pointers and cheers, Tobias -- 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
