Re: [WiX-users] Uninstall running very Slow....
Here is the download link to the uninstall logs: https://www.dropbox.com/s/5qivuotwbornc8t/UninstallLogs.zip?dl=0 -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812p7600828.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall running very Slow....
Nope the VM's are strictly captured snapshots and therefore no accumulative changes are applied to the images. Another thing to note is that we have our own uninstaller application that simply launch the uninstalls of our products that are selected by the user and the tester noticed that the slow down more often when doing an administration push of the uninstall in silent mode. If he pushes the uninstall in UI mode, or runs the same cmds on the local machines then the uninstalls do seem to go faster, at least that is how he sees it. I do not know how running the uninstaller in silent mode and being pushed by the admin would make much difference, that that is what he is seeing. I'll see about posting logs of the same uninstall were one is fast and the other slow to see if someone can see anything unusual. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812p7600826.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall running very Slow....
It may help to post the logs somewhere anyway, just in case someone here can see something unusual. IIRC, the VM may be one of those that does accumulative changes but keeps the original image intact, so each action requires checking the original image and then searching the list of changes to get the correct current state, as well as keeping the change cache up to date with that uninstall. So if the different timings were, for example, not both a fresh VM, install then uninstall, the timings could be inconsistent because of that kind of thing. Otherwise yes, you're right. if there's no change that you can make to the MSI to speed it up and it's all internal installer actions then get it looked at by Microsoft. As for detecting that the uninstall is slow, surely the progress bar already shows that. --- Phil Wilson On Tue, Jul 7, 2015 at 7:14 AM, TimM wrote: > Our testing department has been doing some install/uninstall testing with our > products and have reported that sometimes the uninstall can be very slow at > times and therefore wanted to know if we can fix these.I reviewed the logs > and there were no indication of any tasks taking an overall long time to do, > just consistently slow over all.I mentioned that there was not much that I > could do as it was probably that their machines were busy during uninstall > and therefore simply slowed down the uninstall. And I also mentioned that if > the slow down was in any of our custom actions that we could at least look > into them, but if any of the build in tasks were the cause of the slow down > then there was not much we could do about these. They basically stated if > there was any thing that we could do to detect this slow down and why as > they did not accept my response that it could have just been a busy > machine.So is there anything that I can do, or see in the log that would > explain the slow down so that I could report back as to why the slow downs > are taking place?I was given two logs of the same product being uninstalled > on 2 different VM machines and one completed within 1 min where as the other > completed after 45 mins.Again looking at the logs simply shows that each > step of the uninstall was just taking longer to perform, ie for the > FileRemove actions it took 22 seconds on the fast uninstall, where as on the > slow uninstall it took 24 mins.So if someone could better explain why the > uninstalls may be taking longer in some cases that I could then explain to > the testing department then maybe they will know that it is not something > that I can fix in the install project and therefore not report as a bug. > Sure having installs/uninstalls taking way longer than expected is not a > good user experience, but if there is nothing that I can actually do to fix > it then what else am I suppose to do???Thanks for any input. > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812.html > Sent from the wix-users mailing list archive at Nabble.com. > -- > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall running very Slow....
Our testing department has been doing some install/uninstall testing with our products and have reported that sometimes the uninstall can be very slow at times and therefore wanted to know if we can fix these.I reviewed the logs and there were no indication of any tasks taking an overall long time to do, just consistently slow over all.I mentioned that there was not much that I could do as it was probably that their machines were busy during uninstall and therefore simply slowed down the uninstall. And I also mentioned that if the slow down was in any of our custom actions that we could at least look into them, but if any of the build in tasks were the cause of the slow down then there was not much we could do about these. They basically stated if there was any thing that we could do to detect this slow down and why as they did not accept my response that it could have just been a busy machine.So is there anything that I can do, or see in the log that would explain the slow down so that I could report back as to why the slow downs are taking place?I was given two logs of the same product being uninstalled on 2 different VM machines and one completed within 1 min where as the other completed after 45 mins.Again looking at the logs simply shows that each step of the uninstall was just taking longer to perform, ie for the FileRemove actions it took 22 seconds on the fast uninstall, where as on the slow uninstall it took 24 mins.So if someone could better explain why the uninstalls may be taking longer in some cases that I could then explain to the testing department then maybe they will know that it is not something that I can fix in the install project and therefore not report as a bug. Sure having installs/uninstalls taking way longer than expected is not a good user experience, but if there is nothing that I can actually do to fix it then what else am I suppose to do???Thanks for any input. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
OK, problem solved, I had one file that was locked, that failed the deletion operation, Thanks for all your help! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600206.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
Sorry for that, SHOULDDELETEINSTALLATIONFOLDER = "TRUE" wrapped with CDATA.. where the property is set from burn -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600205.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
The inner text is: where SHOULDDELETEINSTALLATIONFOLDER is a property set from the bundle.. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600202.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
You'll need to escape it. It's not showing on this end. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Enterprise Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: ronif [mailto:ro...@microsoft.com] Sent: Wednesday, May 6, 2015 10:50 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working The inner text is: where SHOULDDELETEINSTALLATIONFOLDER is a property set from the bundle.. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600202.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
What's in the inner text of ? Note that, unless the Component is marked Transitive, that Condition gets evaluated only once. It looks like the Component was not selected, and that would point to the Component-Condition. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Enterprise Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: ronif [mailto:ro...@microsoft.com] Sent: Wednesday, May 6, 2015 10:00 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working Hi again, you were correct about the property but for some reason the folder is still not being delete.. Here are the relevant lines from the log: MSI (s) (A8:90) [07:55:51:893]: Doing action: SetInstallationPathProperty Action ended 7:55:51: ValidateProductID. Return value 1. MSI (s) (A8:90) [07:55:51:894]: PROPERTY CHANGE: Adding InstallationPathProperty property. Its value is 'C:\Program Files\Center'. Action start 7:55:51: SetInstallationPathProperty. MSI (s) (A8:90) [07:55:51:894]: Doing action: WixRemoveFoldersEx Action ended 7:55:51: SetInstallationPathProperty. Return value 1. . . . . MSI (s) (A8:90) [07:55:52:295]: Component: InstalladtionPathCleanup; Installed: Local; Request: Absent; Action: Null any idea why? The component from before is inside my only tag -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600197.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
Hi again, you were correct about the property but for some reason the folder is still not being delete.. Here are the relevant lines from the log: MSI (s) (A8:90) [07:55:51:893]: Doing action: SetInstallationPathProperty Action ended 7:55:51: ValidateProductID. Return value 1. MSI (s) (A8:90) [07:55:51:894]: PROPERTY CHANGE: Adding InstallationPathProperty property. Its value is 'C:\Program Files\Center'. Action start 7:55:51: SetInstallationPathProperty. MSI (s) (A8:90) [07:55:51:894]: Doing action: WixRemoveFoldersEx Action ended 7:55:51: SetInstallationPathProperty. Return value 1. . . . . MSI (s) (A8:90) [07:55:52:295]: Component: InstalladtionPathCleanup; Installed: Local; Request: Absent; Action: Null any idea why? The component from before is inside my only tag -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600197.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
Thanks for your help John! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600196.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
That is what SetProperty is for. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Enterprise Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: ronif [mailto:ro...@microsoft.com] Sent: Wednesday, May 6, 2015 9:12 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working Hi, thanks for your answer, so what is the best way to be able to reference an msiproperty i get from burn? If I can't use ? and how can I set it before CostInitialize? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600194.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
Hi, thanks for your answer, so what is the best way to be able to reference an msiproperty i get from burn? If I can't use ? and how can I set it before CostInitialize? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600194.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
>From the documentation: The folder must be specified in the Property attribute as the name of a property that will have a value that resolves to the full path of the folder before the CostInitialize action. Note that Directory ids cannot be used. For more details, see the Remarks. Before CostInitialize is critical. If it is defined only after CostInitialize, you will get exactly the behavior you are experiencing. Note also that: won't work. The Property element does not handle formatted entities. So, what you have done is set INSTALLATIONPATHPROPERTY literally to "[INSTALLATIONPATH]" which will never work. -- John Merryweather Cooper Senior Software Engineer | Integration Development Group | Enterprise Notification Service Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: ronif [mailto:ro...@microsoft.com] Sent: Wednesday, May 6, 2015 8:41 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Uninstall and util:RemoveFolderEx - not working Hi, util:RemoveFolderEx - doesn't seem to work.. I'm trying to delete the installation folder and its contents upon uninstall (the contents were created after installation by the app so they are left on the drive after uninstall). What am I doing wrong? code: .. remarks: 1. SHOULDDELETEINSTALLATIONFOLDER - is a parameter I pass inside from my managed bootstrapper application. 2. InstallationPath is defined like this: and is also passed from managed bootstrapper application anyone? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall and util:RemoveFolderEx - not working
Hi, util:RemoveFolderEx - doesn't seem to work.. I'm trying to delete the installation folder and its contents upon uninstall (the contents were created after installation by the app so they are left on the drive after uninstall). What am I doing wrong? code: .. remarks: 1. SHOULDDELETEINSTALLATIONFOLDER - is a parameter I pass inside from my managed bootstrapper application. 2. InstallationPath is defined like this: and is also passed from managed bootstrapper application anyone? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall Rollback not triggered with WIXFAILWHENDEFERRED
Where to include REMOVE=ALL using WIXFAILWHENDEFERRED -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-Rollback-not-triggered-with-WIXFAILWHENDEFERRED-tp7598874p7599202.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
[WiX-users] Uninstall another product
Is it possible for the default bundle behaviour to run an uninstall for an arbitrary ProductCode and UpgradeCode as part of its steps? I realize that ordinarily this would be rather rude, but ... This is because I've got a "related product" I need to remove ideally before installing a chain of MSIs. Unfortunately the related products are distinct - different UpgradeCodes - in the Windows Installer sense. Keith Douglas Programmer Analyst | Programmeur analyste Questionnaire Development Services - CAI Social | Services de développement de questionnaires - IAO Social Jean Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -- 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] Uninstall 'Lite' and/or 'Pro' version with RelatedBundle property
Ok I came across the method you prefer to chain several MSI packages. But, what I have now is 2 bundles (let's say Light and Pro) with their own MSI packages. I want the Pro version to uninstall the Light, and vice versa. With RelatedBundle you can detect if they are related but only the version which is higher will install, and uninstall the other. How can I solve this? Do I need to make a custom BA? Is there a helpful link how to accomplish this? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-Lite-and-or-Pro-version-with-RelatedBundle-property-tp7598930p7598937.html Sent from the wix-users mailing list archive at Nabble.com. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall 'Lite' and/or 'Pro' version with RelatedBundle property
You can use Wix XML to author MSI package project(s) or a Bundle (bootstrapper) project, but you do not have to author a bootstrapper. http://wixtoolset.org/documentation/manual/v3/bundle/ A Bundle includes a "Bootstraper Application" (BA) which is processed by the Wix Burn engine. The event handlers are used communication with the Burn engine in a bootstrapper application. You can use the WixStandardBootstrapperApplication and then you only use XML unless you want to customize it with a BAFunctions.dll. You may decide to write your own bootstrapper application, in either C# or C++ and then you need to implement certain event handlers. Personally I prefer the model of creating many, small focused MSI packages which have no UI, and then chaining them in a Bundle (bootstrapper) with a managed UI (mba), which installs the suite of applications. The wix source code includes the Setup folder which is the setup used to install the Wix Toolset and is an example of this approach. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-Lite-and-or-Pro-version-with-RelatedBundle-property-tp7598930p7598933.html Sent from the wix-users mailing list archive at Nabble.com. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall 'Lite' and/or 'Pro' version with RelatedBundle property
Hi, I want to have 2 different installers of a program, let's say lite and pro, like this: http://stackoverflow.com/questions/16429687/how-to-make-a-wix-burn-bundle-that-upgrade-a-lite-version-of-my-product Both have different versions and both have to uninstall each other. Now when I search a bit more I can find WiX has events. Here is as far as I know what I want: http://stackoverflow.com/questions/21612377/schedule-relatedbundle-action-before-primary-bundle The problem is, I'm so new with WiX, I thought you could only xml. But I see the events are in C#. Where are these events? Do I have to create them in a separate C# class? Where do I put this class. I've searched for hours, and cannot find the solution. Hope anyone can help me with this. Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-Lite-and-or-Pro-version-with-RelatedBundle-property-tp7598930.html Sent from the wix-users mailing list archive at Nabble.com. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall Rollback not triggered with WIXFAILWHENDEFERRED
I don't have WixFailWhenDeferred custom action in InstallExecuteSequence. Infact, when I opened the msi in ORCA, the CA was sequenced at 6599 (before InstallFinalize) with condition "WIXFAILWHENDEFERRED=1 AND VersionNT > 400" This I believe should trigger rollback for both Install and Uninstall. Apparently, I cannot get the msi to rollback on uninstall. I also edited the condition in ORCA to "WIXFAILWHENDEFERRED=1 AND VersionNT > 400 AND REMOVE=ALL" to at least rollback on uninstall (I wouldn't expect this condition to evaluate true for INSTALL). But the msi didn't rollback. The condition on the CA was false and was therefore being skipped. Any other places I could check? Could this be anything to do with Wix 3.8? I had the rollback working for both install and uninstall in one of my earlier projects that used Wix 3.5. Thanks for all suggestions! sangeeta -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-Rollback-not-triggered-with-WIXFAILWHENDEFERRED-tp7598874p7598907.html Sent from the wix-users mailing list archive at Nabble.com. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall Rollback not triggered with WIXFAILWHENDEFERRED
Include the condition in your execute sequence to include REMOVE=ALL On Fri, Jan 16, 2015 at 11:35 AM, wixtester wrote: > Hi, > >I am using the WIXFAILWHENDEFFERED customaction reference to test the > installer rollback sequence. > The Install rollback works fine with this property but the uninstall > rollback does not get triggered. > > Appreciate any help in getting the correct command for uninstall rollback > > Product.wxs has > --- > > > > Uninstall rollback commands I tried > --- > msiexec /qb- /x MSINAME.msi /l*v uninstall.log WIXFAILWHENDEFERRED=1 > msiexec /qr /x MSINAME.msi /l*v uninstall.log WIXFAILWHENDEFERRED=1 > msiexec /x MSINAME.msi /l*v uninstall.log WIXFAILWHENDEFERRED=1 > > The logs indicate > --- > skipping action: WixFailWhenDeferred (condition is false) > > > Thanks ! > > > > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-Rollback-not-triggered-with-WIXFAILWHENDEFERRED-tp7598874.html > Sent from the wix-users mailing list archive at Nabble.com. > > > -- > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > ___ > 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 -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall Rollback not triggered with WIXFAILWHENDEFERRED
Hi, I am using the WIXFAILWHENDEFFERED customaction reference to test the installer rollback sequence. The Install rollback works fine with this property but the uninstall rollback does not get triggered. Appreciate any help in getting the correct command for uninstall rollback Product.wxs has --- Uninstall rollback commands I tried --- msiexec /qb- /x MSINAME.msi /l*v uninstall.log WIXFAILWHENDEFERRED=1 msiexec /qr /x MSINAME.msi /l*v uninstall.log WIXFAILWHENDEFERRED=1 msiexec /x MSINAME.msi /l*v uninstall.log WIXFAILWHENDEFERRED=1 The logs indicate --- skipping action: WixFailWhenDeferred (condition is false) Thanks ! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-Rollback-not-triggered-with-WIXFAILWHENDEFERRED-tp7598874.html Sent from the wix-users mailing list archive at Nabble.com. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall previous version
By ProductCode, do you mean Product Id? I tried , but it seems like the installer will just install/overwrite and not remove the old application. By PackageCode, do you mean http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-previous-version-tp7596982p7596999.html Sent from the wix-users mailing list archive at Nabble.com. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall previous version
Nobody can know if your upgrade will work because it depends on the changes made to a set of properties between old and new MSI files. The UpgradeCode must be the same, ProductCode must have changed, PackageCode too (but WiX does that by default I think) and the ProductVersion must be incremented somewhere in the first three fields. In addition a perMachine will not upgrade a perUser product. --- Phil Wilson On Thu, Sep 25, 2014 at 8:33 AM, newuser2014 wrote: > I have the following: > > Language="1033" Version="$(var.VersionNumber)" > Manufacturer="!(loc.ManufacturerName)" UpgradeCode="$(var.UpgradeCode)"> > InstallScope="perMachine" > /> > > >IncludeMinimum="no" Property="NEWER_VERSION_FOUND" /> >Maximum="$(var.VersionNumber)" IncludeMaximum="no" > Property="OLDER_VERSION_FOUND" /> > > > Is that enough and should that be modified? > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-previous-version-tp7596982p7596985.html > Sent from the wix-users mailing list archive at Nabble.com. > > -- > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall previous version
I have the following: Is that enough and should that be modified? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-previous-version-tp7596982p7596985.html Sent from the wix-users mailing list archive at Nabble.com. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall previous version
2014-09-25 11:49 GMT-03:00 newuser2014 : > Hi, > I have the Product id as follows: > > And I have added the following: > > > > This seems to just overwrite the previous version and not uninstall it. > After installation of the newer version, I went into Add/Remove Programs > and saw that the previous version of the application still listed. > Any idea on what is wrong or how to do an uninstall of the previous version? > > Thank you very much for your help! Do you have an UpgradeCode attribute in both the new and old versions? Do you have an Upgrade or MajorUpgrade element? -- Nicolás -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall previous version
Hi, I have the Product id as follows: This seems to just overwrite the previous version and not uninstall it. After installation of the newer version, I went into Add/Remove Programs and saw that the previous version of the application still listed. Any idea on what is wrong or how to do an uninstall of the previous version? Thank you very much for your help! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-previous-version-tp7596982.html Sent from the wix-users mailing list archive at Nabble.com. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall with different Bundle
Hi, Someone please tell , why I am not able to uninstall my bundled packages using a newly build bundle (version and upgrade code is same) ? ie I have installed the package using a different build and tried to uninstall with a new build and there are no changes made in values. Thanks and Regards Amal VR -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-with-different-Bundle-tp7596225.html Sent from the wix-users mailing list archive at Nabble.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=153845071&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall then Reinstall Same Package
So it all comes down to multiple MSIs with the same version number causing problems. On Friday, May 30, 2014, John Cooper wrote: > 1) Because you lose control over the particular ProductCode that > represents your GA/RTM installer. Now ANY installer built by ANYONE can be > installed. This exponentially increases the number of combinations you'll > need to support in the field. Not good unto itself. Pretty easy scenario > too--one of you dev's "loans" a dev build with the same version to one of > your product support team to help a client with a problem. Happens all the > time. If you allow same version, you live with the consequences. > > 2) Because of 1), your patch authoring will be much more difficult. No > longer will you be able to target one ProductCode. Now, you must support > all of them. And test patches against all of them. > > 3) Because an install of the same version with different ProductCode > doesn't necessarily behave like you expect during an upgrade, repair, etc. > In one case, all the assemblies have the same AssemblyFIleVersion, but > there are code changes you want propagated. Not going to happen like you > think. In the other, the versions are different. Now you have different > combinations of assemblies in the same product release--and you must > support all combinations. Not good. > > Don’t believe me? Study the Component Rules carefully and think about the > consequences. > > -- > John Merryweather Cooper > Build & Install Engineer – ESA > Jack Henry & Associates, Inc.® > Shawnee Mission, KS 66227 > Office: 913-341-3434 x791011 > jocoo...@jackhenry.com > www.jackhenry.com > > > > -Original Message- > From: Walter Dexter [mailto:wfdex...@gmail.com ] > Sent: Friday, May 30, 2014 1:36 PM > To: General discussion about the WiX toolset. > Subject: Re: [WiX-users] Uninstall then Reinstall Same Package > > Why is doing this a bad idea? I know that's the common belief, but I don't > know the reason. > > > > On Fri, May 30, 2014 at 11:09 AM, John Cooper > > wrote: > > > Instead of using the old Upgrade authoring, use the MajorUpgrade > > authoring and take a look at the AllowSameVersionUpgrades attribute. > > Note that this is a really bad idea(tm) in the field. > > > > -- > > John Merryweather Cooper > > Build & Install Engineer - ESA > > Jack Henry & Associates, Inc.® > > Shawnee Mission, KS 66227 > > Office: 913-341-3434 x791011 > > jocoo...@jackhenry.com > > www.jackhenry.com > > > > > > > > -Original Message- > > From: Ben Metheny [mailto:benmeth...@gmail.com ] > > Sent: Friday, May 30, 2014 11:03 AM > > To: WiX-users@lists.sourceforge.net > > Subject: [WiX-users] Uninstall then Reinstall Same Package > > > > I have a requirement to allow 'overwrite' of same version. I've tried > > various combinations of , here is my current: > > > > > >> Minimum="1.0.0" IncludeMinimum="yes" > > Maximum="1.0.0" IncludeMaximum="yes" /> > >> Minimum="1.0.1" IncludeMinimum="no" /> > > > > > > and in InstallExecuteSequence I have: > > > > > > > > I think the 'right' thing to do is to require uninstall and then > > reinstall 'manually', but my requirement is to allow user to go > > through installer forms - using custom managed BA - and change values, > > including 'INSTALLLOCATION'. I've been able to handle a 'Modify' > > operation correctly in the BA, showing all required screen with values > > from previous install filled. Is there some way to force MSI to > > uninstall itself then install again? I suppose I could, from the BA, > > run the msi with /uninstall options then run it again with /install > > options but is this the best way to do something like that? > > > > -- > > Time is money. Stop wasting it! Get your web API in 5 > > minutes. > > www.restlet.com/download > > http://p.sf.net/sfu/restlet > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > NOTICE: This electronic mail message and any files transmitted with it > > are intended exclusively for the individual or entity to which it is > > addressed. The message, together with any at
Re: [WiX-users] Uninstall then Reinstall Same Package
1) Because you lose control over the particular ProductCode that represents your GA/RTM installer. Now ANY installer built by ANYONE can be installed. This exponentially increases the number of combinations you'll need to support in the field. Not good unto itself. Pretty easy scenario too--one of you dev's "loans" a dev build with the same version to one of your product support team to help a client with a problem. Happens all the time. If you allow same version, you live with the consequences. 2) Because of 1), your patch authoring will be much more difficult. No longer will you be able to target one ProductCode. Now, you must support all of them. And test patches against all of them. 3) Because an install of the same version with different ProductCode doesn't necessarily behave like you expect during an upgrade, repair, etc. In one case, all the assemblies have the same AssemblyFIleVersion, but there are code changes you want propagated. Not going to happen like you think. In the other, the versions are different. Now you have different combinations of assemblies in the same product release--and you must support all combinations. Not good. Don’t believe me? Study the Component Rules carefully and think about the consequences. -- John Merryweather Cooper Build & Install Engineer – ESA Jack Henry & Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Walter Dexter [mailto:wfdex...@gmail.com] Sent: Friday, May 30, 2014 1:36 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Uninstall then Reinstall Same Package Why is doing this a bad idea? I know that's the common belief, but I don't know the reason. On Fri, May 30, 2014 at 11:09 AM, John Cooper wrote: > Instead of using the old Upgrade authoring, use the MajorUpgrade > authoring and take a look at the AllowSameVersionUpgrades attribute. > Note that this is a really bad idea(tm) in the field. > > -- > John Merryweather Cooper > Build & Install Engineer - ESA > Jack Henry & Associates, Inc.® > Shawnee Mission, KS 66227 > Office: 913-341-3434 x791011 > jocoo...@jackhenry.com > www.jackhenry.com > > > > -Original Message- > From: Ben Metheny [mailto:benmeth...@gmail.com] > Sent: Friday, May 30, 2014 11:03 AM > To: WiX-users@lists.sourceforge.net > Subject: [WiX-users] Uninstall then Reinstall Same Package > > I have a requirement to allow 'overwrite' of same version. I've tried > various combinations of , here is my current: > > >Minimum="1.0.0" IncludeMinimum="yes" > Maximum="1.0.0" IncludeMaximum="yes" /> >Minimum="1.0.1" IncludeMinimum="no" /> > > > and in InstallExecuteSequence I have: > > > > I think the 'right' thing to do is to require uninstall and then > reinstall 'manually', but my requirement is to allow user to go > through installer forms - using custom managed BA - and change values, > including 'INSTALLLOCATION'. I've been able to handle a 'Modify' > operation correctly in the BA, showing all required screen with values > from previous install filled. Is there some way to force MSI to > uninstall itself then install again? I suppose I could, from the BA, > run the msi with /uninstall options then run it again with /install > options but is this the best way to do something like that? > > -- > Time is money. Stop wasting it! Get your web API in 5 > minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > NOTICE: This electronic mail message and any files transmitted with it > are intended exclusively for the individual or entity to which it is > addressed. The message, together with any attachment, may contain > confidential and/or privileged information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution is strictly prohibited. If you have received this message > in error, please immediately advise the sender by reply email and > delete all copies. > > > > -- > Time is money. Stop wasting it! Get your web API in 5 > minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > W
Re: [WiX-users] Uninstall then Reinstall Same Package
Why is doing this a bad idea? I know that's the common belief, but I don't know the reason. On Fri, May 30, 2014 at 11:09 AM, John Cooper wrote: > Instead of using the old Upgrade authoring, use the MajorUpgrade authoring > and take a look at the AllowSameVersionUpgrades attribute. Note that this > is a really bad idea(tm) in the field. > > -- > John Merryweather Cooper > Build & Install Engineer - ESA > Jack Henry & Associates, Inc.® > Shawnee Mission, KS 66227 > Office: 913-341-3434 x791011 > jocoo...@jackhenry.com > www.jackhenry.com > > > > -Original Message- > From: Ben Metheny [mailto:benmeth...@gmail.com] > Sent: Friday, May 30, 2014 11:03 AM > To: WiX-users@lists.sourceforge.net > Subject: [WiX-users] Uninstall then Reinstall Same Package > > I have a requirement to allow 'overwrite' of same version. I've tried > various combinations of , here is my current: > > >Minimum="1.0.0" IncludeMinimum="yes" > Maximum="1.0.0" IncludeMaximum="yes" /> >Minimum="1.0.1" IncludeMinimum="no" /> > > > and in InstallExecuteSequence I have: > > > > I think the 'right' thing to do is to require uninstall and then reinstall > 'manually', but my requirement is to allow user to go through installer > forms - using custom managed BA - and change values, including > 'INSTALLLOCATION'. I've been able to handle a 'Modify' operation correctly > in the BA, showing all required screen with values from previous install > filled. Is there some way to force MSI to uninstall itself then install > again? I suppose I could, from the BA, run the msi with /uninstall options > then run it again with /install options but is this the best way to do > something like that? > > -- > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > > > -- > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall Guidelines - What should be happening
Phil, Thanks for the info, it clarified my assumptions... Marc -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: May-30-2014 12:37 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Uninstall Guidelines - What should be happening My interpretation of using a file for user-specific data is that it's being contrasted with using the registry. It is next to impossible to remove HKCU-type registry data for a user that isn't currently logged on. Removing a file in some other user's data folder is much easier. We're talking about code here, not what Windows Installer does by itself. Regarding files generated by the application, it depends on the content and intent. Nobody would propose removing all the .doc files on a system just because the user uninstalled Word, but on the other hand files generated by the app for its own internal uses are candidates for removal. --- Phil Wilson On Fri, May 30, 2014 at 7:51 AM, Marc Beaudry wrote: > Hello All, > > > > I have a question concerning the uninstall of a package. What should > happen to the user application runtime generated files of several users? > > > > Here is what I got from the MS site for Best practices: > > http://msdn.microsoft.com/en-us/library/windows/desktop/bb204770%28v=v > s.85%2 > 9.aspx#uninstall_clean > > . User-specific customization information can be stored in a text > file on the computer. This has the advantage that the file can be > removed when the application is uninstalled, even if the user of this > customization is not currently logged on. > > > > I am not sure I understand what this means? Does this mean I need one > centralized file containing the info of several users or multiple > files each in its own user folder. > > > > >From what I can see, when I run an uninstall it only cleans the > >currently > logged in user and does not have access to the other users. Am I > mistaken in this understanding? > > > > Thanks for the clarifications, > > Marc > > > > -- > Time is money. Stop wasting it! Get your web API in 5 > minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall Guidelines - What should be happening
My interpretation of using a file for user-specific data is that it's being contrasted with using the registry. It is next to impossible to remove HKCU-type registry data for a user that isn't currently logged on. Removing a file in some other user's data folder is much easier. We're talking about code here, not what Windows Installer does by itself. Regarding files generated by the application, it depends on the content and intent. Nobody would propose removing all the .doc files on a system just because the user uninstalled Word, but on the other hand files generated by the app for its own internal uses are candidates for removal. --- Phil Wilson On Fri, May 30, 2014 at 7:51 AM, Marc Beaudry wrote: > Hello All, > > > > I have a question concerning the uninstall of a package. What should happen > to the user application runtime generated files of several users? > > > > Here is what I got from the MS site for Best practices: > > http://msdn.microsoft.com/en-us/library/windows/desktop/bb204770%28v=vs.85%2 > 9.aspx#uninstall_clean > > . User-specific customization information can be stored in a text > file on the computer. This has the advantage that the file can be removed > when the application is uninstalled, even if the user of this customization > is not currently logged on. > > > > I am not sure I understand what this means? Does this mean I need one > centralized file containing the info of several users or multiple files each > in its own user folder. > > > > >From what I can see, when I run an uninstall it only cleans the currently > logged in user and does not have access to the other users. Am I mistaken > in this understanding? > > > > Thanks for the clarifications, > > Marc > > > > -- > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall then Reinstall Same Package
Thanks, I'll take a look at that. I completely agree, this should not be done but people more important than myself decide such things. On Fri, May 30, 2014 at 12:09 PM, John Cooper wrote: > Instead of using the old Upgrade authoring, use the MajorUpgrade authoring > and take a look at the AllowSameVersionUpgrades attribute. Note that this > is a really bad idea(tm) in the field. > > -- > John Merryweather Cooper > Build & Install Engineer - ESA > Jack Henry & Associates, Inc.® > Shawnee Mission, KS 66227 > Office: 913-341-3434 x791011 > jocoo...@jackhenry.com > www.jackhenry.com > > > > -Original Message- > From: Ben Metheny [mailto:benmeth...@gmail.com] > Sent: Friday, May 30, 2014 11:03 AM > To: WiX-users@lists.sourceforge.net > Subject: [WiX-users] Uninstall then Reinstall Same Package > > I have a requirement to allow 'overwrite' of same version. I've tried > various combinations of , here is my current: > > >Minimum="1.0.0" IncludeMinimum="yes" > Maximum="1.0.0" IncludeMaximum="yes" /> >Minimum="1.0.1" IncludeMinimum="no" /> > > > and in InstallExecuteSequence I have: > > > > I think the 'right' thing to do is to require uninstall and then reinstall > 'manually', but my requirement is to allow user to go through installer > forms - using custom managed BA - and change values, including > 'INSTALLLOCATION'. I've been able to handle a 'Modify' operation correctly > in the BA, showing all required screen with values from previous install > filled. Is there some way to force MSI to uninstall itself then install > again? I suppose I could, from the BA, run the msi with /uninstall options > then run it again with /install options but is this the best way to do > something like that? > > -- > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > > > -- > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall then Reinstall Same Package
I do this in some MSIs that we deploy strictly silently via Microsoft system management stuff. My upgrade block looks like this: And also this, which I think matters: Then I have a wxi file that I include that contains: You don't really need the vars and the .wxi file - I just like having the version numbers, upgrade code and product name all together instead of scattered around. I'm pretty sure this is all the stuff that matters to make this work, but it's been months, and I pretty much just beat on it until it worked. On Fri, May 30, 2014 at 11:03 AM, Ben Metheny wrote: > I have a requirement to allow 'overwrite' of same version. I've tried > various combinations of , here is my current: > > >Minimum="1.0.0" IncludeMinimum="yes" > Maximum="1.0.0" IncludeMaximum="yes" /> >Minimum="1.0.1" IncludeMinimum="no" /> > > > and in InstallExecuteSequence I have: > > > > I think the 'right' thing to do is to require uninstall and then reinstall > 'manually', but my requirement is to allow user to go through installer > forms - using custom managed BA - and change values, including > 'INSTALLLOCATION'. I've been able to handle a 'Modify' operation correctly > in the BA, showing all required screen with values from previous install > filled. Is there some way to force MSI to uninstall itself then install > again? I suppose I could, from the BA, run the msi with /uninstall options > then run it again with /install options but is this the best way to do > something like that? > > -- > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall then Reinstall Same Package
Instead of using the old Upgrade authoring, use the MajorUpgrade authoring and take a look at the AllowSameVersionUpgrades attribute. Note that this is a really bad idea(tm) in the field. -- John Merryweather Cooper Build & Install Engineer - ESA Jack Henry & Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Ben Metheny [mailto:benmeth...@gmail.com] Sent: Friday, May 30, 2014 11:03 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Uninstall then Reinstall Same Package I have a requirement to allow 'overwrite' of same version. I've tried various combinations of , here is my current: and in InstallExecuteSequence I have: I think the 'right' thing to do is to require uninstall and then reinstall 'manually', but my requirement is to allow user to go through installer forms - using custom managed BA - and change values, including 'INSTALLLOCATION'. I've been able to handle a 'Modify' operation correctly in the BA, showing all required screen with values from previous install filled. Is there some way to force MSI to uninstall itself then install again? I suppose I could, from the BA, run the msi with /uninstall options then run it again with /install options but is this the best way to do something like that? -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall then Reinstall Same Package
I have a requirement to allow 'overwrite' of same version. I've tried various combinations of , here is my current: and in InstallExecuteSequence I have: I think the 'right' thing to do is to require uninstall and then reinstall 'manually', but my requirement is to allow user to go through installer forms - using custom managed BA - and change values, including 'INSTALLLOCATION'. I've been able to handle a 'Modify' operation correctly in the BA, showing all required screen with values from previous install filled. Is there some way to force MSI to uninstall itself then install again? I suppose I could, from the BA, run the msi with /uninstall options then run it again with /install options but is this the best way to do something like that? -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall Guidelines - What should be happening
Hello All, I have a question concerning the uninstall of a package. What should happen to the user application runtime generated files of several users? Here is what I got from the MS site for Best practices: http://msdn.microsoft.com/en-us/library/windows/desktop/bb204770%28v=vs.85%2 9.aspx#uninstall_clean . User-specific customization information can be stored in a text file on the computer. This has the advantage that the file can be removed when the application is uninstalled, even if the user of this customization is not currently logged on. I am not sure I understand what this means? Does this mean I need one centralized file containing the info of several users or multiple files each in its own user folder. >From what I can see, when I run an uninstall it only cleans the currently logged in user and does not have access to the other users. Am I mistaken in this understanding? Thanks for the clarifications, Marc -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall MSI from ARP doesn't remove installed files
I got the solution for my first problem (files not removed from installed location). I forgot to set the MSI property value on uninstallation. So the MSI feature is not get called and files not removed. Now the files are removed correctly. Could anyone please share example/way for removing selected MSI files on uninstallation? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-MSI-from-ARP-doesn-t-remove-installed-files-tp7593939p7594098.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] Uninstall MSI from ARP doesn't remove installed files
Great, Thanks Rob. In which event I need to handle this process? In DetectPackageComplete I can able to get the state of the packages. My bundle having "InstallCondition" in chain/MsiPackage element. Is this condition enough for handle selected MSI on Uninstallation? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-MSI-from-ARP-doesn-t-remove-installed-files-tp7593939p7593988.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall MSI from ARP doesn't remove installed files
Yes. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Saravan1109 [mailto:biggodannau...@gmail.com] Sent: Monday, April 7, 2014 3:17 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Uninstall MSI from ARP doesn't remove installed files Thanks for your reply. I need some clarifications in uninstalling MSI using burn. Is it possible to remove only the selected MSI files while uninstallation? Scenario : If launch the bundle uninstall from ARP, it shows the installed MSI packages list. I will select any of one MSI from that list and need to uninstall that MSI only. Is it possible using burn & custom bootstrapper? Need to maintain the bundle entry in ARP until uninstall the all the remaining MSI packages. Any idea on this? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-MSI-from-ARP-doesn-t-remove-installed-files-tp7593939p7593972.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall MSI from ARP doesn't remove installed files
Thanks for your reply. I need some clarifications in uninstalling MSI using burn. Is it possible to remove only the selected MSI files while uninstallation? Scenario : If launch the bundle uninstall from ARP, it shows the installed MSI packages list. I will select any of one MSI from that list and need to uninstall that MSI only. Is it possible using burn & custom bootstrapper? Need to maintain the bundle entry in ARP until uninstall the all the remaining MSI packages. Any idea on this? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-MSI-from-ARP-doesn-t-remove-installed-files-tp7593939p7593972.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall MSI from ARP doesn't remove installed files
If you're saying that you uninstall one of the MSIs from ARP and some files remain, but if you uninstall both MSIs via the bundle and no files remain, one explanation is there are some shared files in both MSIs and uninstalling one will leave them behind because they are used by the other. --- Phil Wilson On Fri, Apr 4, 2014 at 9:34 AM, Rob Mensching wrote: > Sounds like something is awry with your MSI. I would expect that to work. > Verbose log file should show you what's going on. > > ___ > FireGiant | Dedicated support for the WiX toolset | > http://www.firegiant.com/ > > -Original Message- > From: Saravan1109 [mailto:biggodannau...@gmail.com] > Sent: Friday, April 4, 2014 4:54 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Uninstall MSI from ARP doesn't remove installed files > > Hi, > > I have created a custom bootstrapper application and Bundle using wix 3.8. > The chain contains two MSI packages. > > > Compressed="no" EnableFeatureSelection ="yes" InstallCondition ="cbASPNET" > Visible="yes" ForcePerMachine="yes"/> > Compressed="no" EnableFeatureSelection ="yes" InstallCondition ="cbASPNET" > Visible="yes" ForcePerMachine="yes"/> > > > I have given Visible="yes" in msipackage element. So it shows the bundle > entry and two MSI files entry in ARP. > If I uninstall the bundle entry from ARP, it will uninstall two MSI packages > and also the shipped files in installed location are get removed. > > But if I do uninstall the MSI from ARP, it only removes the MSI from ARP. > Shipped files are present in installed location. > > My requirement is need to remove the files from installed location while > uninstalling MSI from ARP which is installed by bootstrapper. > > Could anyone please share any solution for this? What did I do wrong? > > Thanks, > Saravanan > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-MSI-from-ARP-doesn-t-remove-installed-files-tp7593939.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 > > -- > ___ > 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] Uninstall MSI from ARP doesn't remove installed files
Sounds like something is awry with your MSI. I would expect that to work. Verbose log file should show you what's going on. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Saravan1109 [mailto:biggodannau...@gmail.com] Sent: Friday, April 4, 2014 4:54 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Uninstall MSI from ARP doesn't remove installed files Hi, I have created a custom bootstrapper application and Bundle using wix 3.8. The chain contains two MSI packages. I have given Visible="yes" in msipackage element. So it shows the bundle entry and two MSI files entry in ARP. If I uninstall the bundle entry from ARP, it will uninstall two MSI packages and also the shipped files in installed location are get removed. But if I do uninstall the MSI from ARP, it only removes the MSI from ARP. Shipped files are present in installed location. My requirement is need to remove the files from installed location while uninstalling MSI from ARP which is installed by bootstrapper. Could anyone please share any solution for this? What did I do wrong? Thanks, Saravanan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-MSI-from-ARP-doesn-t-remove-installed-files-tp7593939.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 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall MSI from ARP doesn't remove installed files
Hi, I have created a custom bootstrapper application and Bundle using wix 3.8. The chain contains two MSI packages. I have given Visible="yes" in msipackage element. So it shows the bundle entry and two MSI files entry in ARP. If I uninstall the bundle entry from ARP, it will uninstall two MSI packages and also the shipped files in installed location are get removed. But if I do uninstall the MSI from ARP, it only removes the MSI from ARP. Shipped files are present in installed location. My requirement is need to remove the files from installed location while uninstalling MSI from ARP which is installed by bootstrapper. Could anyone please share any solution for this? What did I do wrong? Thanks, Saravanan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-MSI-from-ARP-doesn-t-remove-installed-files-tp7593939.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] Uninstall removing the default Virtual directory and not the one user created
Thanks David, I will try this and let you know
On 21-03-2014 19:48, David Watson wrote:
> You need to persist the VIRTUAL_DIR_VAL (store it in the registry) so the
> uninstaller knows it has changed otherwise it will use the default values.
>
> http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern
>
>
> -Original Message-
> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
> Sent: 21 March 2014 12:53
> To: General discussion about the WiX toolset.
> Subject: [WiX-users] Uninstall removing the default Virtual directory and not
> the one user created
>
> Hi All,
>
> I am creating virtual directory through WIX installer. The installer
> allows user to change the name of the virtual directory through a custom
> UI dialogue. The default virtual directory is PFWServiceApplication. If
> the user changes this to say PFWServiceApplication_Test then the correct
> virtual directory is created and installation works fine. But the
> uninstall removes the default virtual directory. For instance i had
> created the default virtual directory PFWServiceApplication manually for
> testing and then used the installer to create the
> PFWServiceApplication_Test virtual directory. On uninstalling the
> PFWServiceApplication gets fully removed and the for
> PFWServiceApplication_Test only the node is left under the default
> website. What i want is that on uninstall only that virtual directory
> that i installed through the installer should be removed. Below is my code.
>
>
>
>
>
>
>
>
>
>
>
>Guid="{9413B3CA-4CF1-4E3C-8F13-4E48291A8E22}" KeyPath="yes" Permanent="no">
>ManagedRuntimeVersion="v4.0" ManagedPipelineMode="Integrated" />
>
>
>
>Guid="{751DEB01-ECC1-48ff-869A-65BCEE9E0528}" KeyPath="yes" Permanent="no">
>Alias="[VIRTUAL_DIR_VAL]" Directory="MYWEBWEBSITE" WebSite="DefaultWebSite">
>AnonymousAccess="yes" BasicAuthentication="yes"
> WindowsAuthentication="yes" />
>Name="[VIRTUAL_DIR_VAL]" WebAppPool="MyWebAppPool" />
>
>
>
>
>
>
>
>
>
>
>
> The include file ConfigurationInitialize.wxi has below code:
> Secure="yes"/>
>
>
>Secure="yes"/>
>
> Please provide some help on this.
>
> Regards,
> Suvra Jyoti
>
> --
> 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/13534_NeoTech
> ___
> 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.
>
>
>
> This message has been scanned for malware by Websense. www.websense.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/13534_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/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall removing the default Virtual directory and not the one user created
You need to persist the VIRTUAL_DIR_VAL (store it in the registry) so the uninstaller knows it has changed otherwise it will use the default values. http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern -Original Message- From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in] Sent: 21 March 2014 12:53 To: General discussion about the WiX toolset. Subject: [WiX-users] Uninstall removing the default Virtual directory and not the one user created Hi All, I am creating virtual directory through WIX installer. The installer allows user to change the name of the virtual directory through a custom UI dialogue. The default virtual directory is PFWServiceApplication. If the user changes this to say PFWServiceApplication_Test then the correct virtual directory is created and installation works fine. But the uninstall removes the default virtual directory. For instance i had created the default virtual directory PFWServiceApplication manually for testing and then used the installer to create the PFWServiceApplication_Test virtual directory. On uninstalling the PFWServiceApplication gets fully removed and the for PFWServiceApplication_Test only the node is left under the default website. What i want is that on uninstall only that virtual directory that i installed through the installer should be removed. Below is my code. The include file ConfigurationInitialize.wxi has below code: Please provide some help on this. Regards, Suvra Jyoti -- 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/13534_NeoTech ___ 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. This message has been scanned for malware by Websense. www.websense.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/13534_NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall removing the default Virtual directory and not the one user created
Hi All, I am creating virtual directory through WIX installer. The installer allows user to change the name of the virtual directory through a custom UI dialogue. The default virtual directory is PFWServiceApplication. If the user changes this to say PFWServiceApplication_Test then the correct virtual directory is created and installation works fine. But the uninstall removes the default virtual directory. For instance i had created the default virtual directory PFWServiceApplication manually for testing and then used the installer to create the PFWServiceApplication_Test virtual directory. On uninstalling the PFWServiceApplication gets fully removed and the for PFWServiceApplication_Test only the node is left under the default website. What i want is that on uninstall only that virtual directory that i installed through the installer should be removed. Below is my code. The include file ConfigurationInitialize.wxi has below code: Please provide some help on this. Regards, Suvra Jyoti -- 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/13534_NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall condition for a MSI that dependency for other applications
Hello Wix-users, I have two independent applications (let's call them ProductB and ProductC) that has dependency on application ProductA. I am using two different managed bootstrapper exe to bundle: Exe1: ProductA and ProductB Exe2: ProductA and ProductC Because of independent release cycles, Exe1 and Exe2 may contain different versions of ProductA. How do I make sure of followings? I am not even sure whether they are possible. 1) Installing two different exe should always keep the latest version of ProductA installed. If user is trying to install a product that has bundle with lower version of ProductA, but he already has higher version in the machine, I would like to skip installation for ProductA and continue installation for the product that has not been installed yet. 2) If I uninstall a product (Exe1 or Exe2), how do I make sure that I don't uninstall ProductA if another dependent application is still present in the machine? With AllowDowngrades="no" for ProductA, uninstalling the bootstrapper that has higher version of ProductA is uninstalling ProductA regardless. Thank you Thank you -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-condition-for-a-MSI-that-dependency-for-other-applications-tp7593269.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/13534_NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall Patch Error 1706
These might help. It's possible the patched file was never cached in the baseline cache (or was removed) or it wasn't a >= MSI 3.0 patch: http://blogs.msdn.com/b/heaths/archive/2007/01/17/the-patch-cache-and-freeing-space.aspx and this may still be an issue: http://blogs.msdn.com/b/heaths/archive/2007/06/28/unchanged-files-break-patch-uninstall.aspx --- Phil Wilson On Fri, Feb 28, 2014 at 4:13 AM, Christoffel le Roux wrote: > Hi, I have two products that install from a cd. > > Both install and patch fine, but one of the products give ma a 1706 error > only in Windows 8 and asks for the original media source when I try to > uninstall an installed patch. > > Once I selected the original media source the source gets rejected and the > installation fails. > > The other product installs and uninstalls like a charm. > > Both the product definitions like follow: > > Name="$(var.ProductName)" > Language="1033" > Version="$(var.ProductVersion)" > Manufacturer="$(var.ProductManufacturer)" > UpgradeCode="$(var.UpgradeCode)"> > > Compressed="yes" > InstallScope="perMachine" > Description="$(var. Description)" > InstallPrivileges="elevated" AdminImage="yes"/> > > > > > > > And the Patch Properties : > > > > http://schemas.microsoft.com/wix/2006/wi";> > > > > > > > > > AllowRemoval="yes" > > Manufacturer="$(var.ProductManufacturer)" > > MoreInfoURL="$(var.ArpUrlInfoAbout)" > > Description="$(var. PatchDescriptionx64)" > > DisplayName="$(var. PatchDisplayNamex64)" > > Comments="$(var. PatchDescriptionx64)" > > MinorUpdateTargetRTM="yes" > > Classification="Update"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Version="$(var.ProductVersion)" Supersede="yes"> > > > > > > > > > I did read about the AllowMediaLockdown registry setting and adding the > setting to the registry solves the source resolution problem thus telling me > that for some reason the source of that one particular product cannot be save. > > > I have been on this for a while now and cannot crack the reason why this is > happening to only one of the products on the cd. > > Please help ! > Thanks in advanced. > > Christoffel le Roux > This information is intended only for the person or entity to which it is > addressed and may contain private, confidential, proprietary and/or > privileged material and may be subject to confidentiality agreements. Any > review, retransmission, dissemination, or any other use of or taking of any > action in reliance upon this information, by persons or entities other than > the intended recipient, is prohibited. If you received this in error, please > contact the sender and delete the material from all storage media. > FlowCentric is neither liable for proper, complete transmission of the > information contained in this communication, any delay in its receipt or that > the mail is virus-free. > -- > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall Patch Error 1706
Hi, I have two products that install from a cd. Both install and patch fine, but one of the products give ma a 1706 error only in Windows 8 and asks for the original media source when I try to uninstall an installed patch. Once I selected the original media source the source gets rejected and the installation fails. The other product installs and uninstalls like a charm. Both the product definitions like follow: And the Patch Properties : http://schemas.microsoft.com/wix/2006/wi";> I did read about the AllowMediaLockdown registry setting and adding the setting to the registry solves the source resolution problem thus telling me that for some reason the source of that one particular product cannot be save. I have been on this for a while now and cannot crack the reason why this is happening to only one of the products on the cd. Please help ! Thanks in advanced. Christoffel le Roux This information is intended only for the person or entity to which it is addressed and may contain private, confidential, proprietary and/or privileged material and may be subject to confidentiality agreements. Any review, retransmission, dissemination, or any other use of or taking of any action in reliance upon this information, by persons or entities other than the intended recipient, is prohibited. If you received this in error, please contact the sender and delete the material from all storage media. FlowCentric is neither liable for proper, complete transmission of the information contained in this communication, any delay in its receipt or that the mail is virus-free. -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Thanks for the clarification, that helps. On 19-12-2013 14:55, Blair Murri wrote: > It’s like I wrote: Windows Installer will first try to move files it intends > on either replacing or deleting. If that succeeds, then the directory can > then be removed (but only if empty). > > > Files that cannot be deleted (whether moved or not) are marked for deletion > upon the next reboot if the transaction was successful. The mechanism for > removing files either doesn’t support directories or Windows Installer > doesn’t use it that way, and directories that couldn’t be removed before the > reboot are orphaned by Windows Installer. It’s been that way for years, I’ve > never seen a fix for it. > > > The only workarounds are to either only open files in such a way as to allow > them to be either moved or deleted while they are open (executable binaries > [DLL, EXE, etc.] are usually opened that way) or block uninstall from > succeeding while the file is still in use, or simply accept that an empty > directory, while not ideal, usually isn’t the end of the world. It takes > essentially no disk space, for instance, and doesn’t generally prevent > reinstallation from succeeding. > > > > > > > -Blair > > > > > > From: Suvrajyoti Panda > Sent: Wednesday, December 18, 2013 8:40 PM > To: General discussion for Windows Installer XML toolset. > > > > > > Yes it does exist after reboot as well. > > On 18-12-2013 21:13, Hoover, Jacob wrote: >> Does it exist after a reboot? I seem to remember windows installer being >> smart enough to schedule some cleanup after reboot (if it couldn't do them >> during uninstall). >> >> -Original Message- >> From: David Connet [mailto:d...@agilityrecordbook.com] >> Sent: Wednesday, December 18, 2013 8:25 AM >> To: General discussion about the WiX toolset. >> Subject: Re: [WiX-users] Uninstall by Installer not removing the path >> created if that path is open on the system >> >> There is no way (that I know of) to delete a directory where something has >> an open handle on that. The only way is to make sure all programs have >> stopped and no open programs have that as their current directory. >> >> It's just like opening cmd.exe, cd'ing to a directory and trying to delete >> that directory from explorer. Can't be done. >> >> Dave >> >> On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote: >>> Hi Phil, >>> >>> I modified the structure in my main WIX file as below: >>> >>> >>> >>> >> Guid="22AD76A4-448E-41DB-85A0-A04E9774A466" KeyPath="yes"> >>> >>> >>> >>> After installing i traversed to "C:\Energy Solutions >>> International\PFWService\config\access" then uninstalled the path >>> "C:\Energy Solutions International\PFWService\" still exists, all the >>> files are deleted though. >>> >>> On 17-12-2013 21:32, Phil Wilson wrote: >>>> Why not just try a RemoveFolder and see if it solves the problem? It >>>> is the most likely solution, as suggested before. >>>> >>>> Phil Wilson >>>> >>>> >>>> On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda >>>> >>>> wrote: >>>>> I just thought i needed to reiterate the issue for better clarity: >>>>> >>>>> Below is the directory structure in my source .wxs file: >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Guid="5DAD9B46-43BB-42D2-91E9-F2248369AA68" Win64="no"> >>>>> >>>> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]" >>>>> Type="string" /> >>>>> >>>>> >>>> Guid="57240178-4A44-4C6F-A11C-B4DE99573DE0" Win64="yes"> >>>>> >>>> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]" >>>>> Type="string" /> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The heat harvests direct
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
It’s like I wrote: Windows Installer will first try to move files it intends on
either replacing or deleting. If that succeeds, then the directory can then be
removed (but only if empty).
Files that cannot be deleted (whether moved or not) are marked for deletion
upon the next reboot if the transaction was successful. The mechanism for
removing files either doesn’t support directories or Windows Installer doesn’t
use it that way, and directories that couldn’t be removed before the reboot are
orphaned by Windows Installer. It’s been that way for years, I’ve never seen a
fix for it.
The only workarounds are to either only open files in such a way as to allow
them to be either moved or deleted while they are open (executable binaries
[DLL, EXE, etc.] are usually opened that way) or block uninstall from
succeeding while the file is still in use, or simply accept that an empty
directory, while not ideal, usually isn’t the end of the world. It takes
essentially no disk space, for instance, and doesn’t generally prevent
reinstallation from succeeding.
-Blair
From: Suvrajyoti Panda
Sent: Wednesday, December 18, 2013 8:40 PM
To: General discussion for Windows Installer XML toolset.
Yes it does exist after reboot as well.
On 18-12-2013 21:13, Hoover, Jacob wrote:
> Does it exist after a reboot? I seem to remember windows installer being
> smart enough to schedule some cleanup after reboot (if it couldn't do them
> during uninstall).
>
> -Original Message-
> From: David Connet [mailto:d...@agilityrecordbook.com]
> Sent: Wednesday, December 18, 2013 8:25 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
> if that path is open on the system
>
> There is no way (that I know of) to delete a directory where something has an
> open handle on that. The only way is to make sure all programs have stopped
> and no open programs have that as their current directory.
>
> It's just like opening cmd.exe, cd'ing to a directory and trying to delete
> that directory from explorer. Can't be done.
>
> Dave
>
> On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
>> Hi Phil,
>>
>> I modified the structure in my main WIX file as below:
>>
>>
>>
>> > Guid="22AD76A4-448E-41DB-85A0-A04E9774A466" KeyPath="yes">
>>
>>
>>
>> After installing i traversed to "C:\Energy Solutions
>> International\PFWService\config\access" then uninstalled the path
>> "C:\Energy Solutions International\PFWService\" still exists, all the
>> files are deleted though.
>>
>> On 17-12-2013 21:32, Phil Wilson wrote:
>>> Why not just try a RemoveFolder and see if it solves the problem? It
>>> is the most likely solution, as suggested before.
>>>
>>> Phil Wilson
>>>
>>>
>>> On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda
>>> >>> wrote:
>>>> I just thought i needed to reiterate the issue for better clarity:
>>>>
>>>> Below is the directory structure in my source .wxs file:
>>>>
>>>>
>>>>
>>>>
>>>>>>> Guid="5DAD9B46-43BB-42D2-91E9-F2248369AA68" Win64="no">
>>>> >>> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>>>> Type="string" />
>>>>
>>>>>>> Guid="57240178-4A44-4C6F-A11C-B4DE99573DE0" Win64="yes">
>>>> >>> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>>>> Type="string" />
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The heat harvests directories from a location D:\Configrelease which
>>>> has directories such as "command_processors". The produces
>>>> config.wxs file that has below structure:
>>>>
>>>>
>>>> >>> Guid="{0EDAF860-B5C3-4C93-BDD7-EB1947D94749}">
>>>> >>> KeyPath="yes" Source="$(var.ConfigPath)\PFWConfiguration.xml" />
>>>>
>>>> >>> Name="archives&quo
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Yes it does exist after reboot as well.
On 18-12-2013 21:13, Hoover, Jacob wrote:
> Does it exist after a reboot? I seem to remember windows installer being
> smart enough to schedule some cleanup after reboot (if it couldn't do them
> during uninstall).
>
> -Original Message-
> From: David Connet [mailto:d...@agilityrecordbook.com]
> Sent: Wednesday, December 18, 2013 8:25 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
> if that path is open on the system
>
> There is no way (that I know of) to delete a directory where something has an
> open handle on that. The only way is to make sure all programs have stopped
> and no open programs have that as their current directory.
>
> It's just like opening cmd.exe, cd'ing to a directory and trying to delete
> that directory from explorer. Can't be done.
>
> Dave
>
> On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
>> Hi Phil,
>>
>> I modified the structure in my main WIX file as below:
>>
>>
>>
>> > Guid="22AD76A4-448E-41DB-85A0-A04E9774A466" KeyPath="yes">
>>
>>
>>
>> After installing i traversed to "C:\Energy Solutions
>> International\PFWService\config\access" then uninstalled the path
>> "C:\Energy Solutions International\PFWService\" still exists, all the
>> files are deleted though.
>>
>> On 17-12-2013 21:32, Phil Wilson wrote:
>>> Why not just try a RemoveFolder and see if it solves the problem? It
>>> is the most likely solution, as suggested before.
>>>
>>> Phil Wilson
>>>
>>>
>>> On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda
>>> >>> wrote:
>>>> I just thought i needed to reiterate the issue for better clarity:
>>>>
>>>> Below is the directory structure in my source .wxs file:
>>>>
>>>>
>>>>
>>>>
>>>>>>> Guid="5DAD9B46-43BB-42D2-91E9-F2248369AA68" Win64="no">
>>>> >>> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>>>> Type="string" />
>>>>
>>>>>>> Guid="57240178-4A44-4C6F-A11C-B4DE99573DE0" Win64="yes">
>>>> >>> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>>>> Type="string" />
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The heat harvests directories from a location D:\Configrelease which
>>>> has directories such as "command_processors". The produces
>>>> config.wxs file that has below structure:
>>>>
>>>>
>>>> >>> Guid="{0EDAF860-B5C3-4C93-BDD7-EB1947D94749}">
>>>> >>> KeyPath="yes" Source="$(var.ConfigPath)\PFWConfiguration.xml" />
>>>>
>>>> >>> Name="archives">
>>>>
>>>>
>>>> >>> Name="command_processors">
>>>> >>> Guid="{F2158D98-1DC2-4348-89FC-65A2115084B6}" KeyPath="yes">
>>>>
>>>>
>>>>
>>>> After i run the installer, i browse to "C:\Energy Solutions
>>>> International\PFWService\config\command_processors" and keep this
>>>> path open, and then uninstall the directory structure that does not
>>>> get removed is "C:\Energy Solutions International\PFWService".
>>>>
>>>> Is it because of the in the config.wxs(as Wesley had
>>>> suggest) file that heat creates that i am facing this issue. If so
>>>> what is the way out. Hope i have explained the situation better this
>>>> time, apologies if i created any confusion.
>>>>
>>>> Regards,
>>>> SuvraJyoti
>>>>
>>>> On 17-12-2013 14:27, Suvrajyoti Panda wrote:
>>>>> Hey Blair,
>>>>&
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
14:14, Blair Murri wrote:
>>>>>> If a file being removed can’t be moved, then it will be marked for
>>>> removal during reboot, and unfortunately the folder will then be left
>>>> behind (because only file delete records are placed into the reboot
>>>> sequence, not folders). After reboot there isn’t an installation left to
>>>> run to cleanup any further.
>>>>>> Most of the time, files still in use can be moved (even if they are
>>>> still loaded in other processes) and the folder is thus removed during the
>>>> installation transaction (before the reboot) and the moved file is then
>>>> removed as part of the reboot sequence.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Blair
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Suvrajyoti Panda
>>>>>> Sent: Monday, December 16, 2013 8:57 PM
>>>>>> To: General discussion for Windows Installer XML toolset.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> No Wesley, I have not used any create folder over here.
>>>>>>
>>>>>> Regards,
>>>>>> SuvraJyoti
>>>>>>
>>>>>> On 16-12-2013 20:03, Wesley Manning wrote:
>>>>>>> Did you use CreateFolder to create this directory? If so I think you
>>>> need to use RemoveFolder to remove the folder. Not sure about that though.
>>>>>>> -Original Message-
>>>>>>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>>>>>>> Sent: December-16-13 12:37 AM
>>>>>>> To: General discussion about the WiX toolset.
>>>>>>> Subject: Re: [WiX-users] Uninstall by Installer not removing the path
>>>> created if that path is open on the system
>>>>>>> Hey Wesley,
>>>>>>>
>>>>>>> checked it on a reboot, that does not work. The structure is still
>>>> there. Any others suggestions guys?
>>>>>>> Regards,
>>>>>>> SuvraJyoti
>>>>>>> On 13-12-2013 20:13, Wesley Manning wrote:
>>>>>>>> It might be removed on a reboot. If you had folder open, then
>>>> windows installer can't uninstall it. But I think it marks it for removal.
>>>> I know for sure files have this behaviour but I'm not sure about
>>>> folders.
>>>>>>>> -Original Message-
>>>>>>>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>>>>>>>> Sent: December-13-13 1:48 AM
>>>>>>>> To: General discussion about the WiX toolset.
>>>>>>>> Subject: [WiX-users] Uninstall by Installer not removing the path
>>>>>>>> created if that path is open on the system
>>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I just saw this behaviour. My installer creates the following
>>>> :"C:\Energy Solutions International\PFWService\config", if this path is
>>>> open and i run the uninstall from control panel, then the path
>>>> remains("C:\Energy Solutions International\PFWService\config") although
>>>> files under it is removed. Is it expected behavior or incorrect. If
>>>> incorrect what is the workaround for the same.
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Does it exist after a reboot? I seem to remember windows installer being smart
enough to schedule some cleanup after reboot (if it couldn't do them during
uninstall).
-Original Message-
From: David Connet [mailto:d...@agilityrecordbook.com]
Sent: Wednesday, December 18, 2013 8:25 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
if that path is open on the system
There is no way (that I know of) to delete a directory where something has an
open handle on that. The only way is to make sure all programs have stopped and
no open programs have that as their current directory.
It's just like opening cmd.exe, cd'ing to a directory and trying to delete that
directory from explorer. Can't be done.
Dave
On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
> Hi Phil,
>
> I modified the structure in my main WIX file as below:
>
>
>
> Guid="22AD76A4-448E-41DB-85A0-A04E9774A466" KeyPath="yes">
>
>
>
> After installing i traversed to "C:\Energy Solutions
> International\PFWService\config\access" then uninstalled the path
> "C:\Energy Solutions International\PFWService\" still exists, all the
> files are deleted though.
>
> On 17-12-2013 21:32, Phil Wilson wrote:
>> Why not just try a RemoveFolder and see if it solves the problem? It
>> is the most likely solution, as suggested before.
>>
>> Phil Wilson
>>
>>
>> On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda
>> >> wrote:
>>> I just thought i needed to reiterate the issue for better clarity:
>>>
>>> Below is the directory structure in my source .wxs file:
>>>
>>>
>>>
>>>
>>> >> Guid="5DAD9B46-43BB-42D2-91E9-F2248369AA68" Win64="no">
>>> >> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>>>Type="string" />
>>>
>>> >> Guid="57240178-4A44-4C6F-A11C-B4DE99573DE0" Win64="yes">
>>> >> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>>>Type="string" />
>>>
>>>
>>>
>>>
>>>
>>>
>>> The heat harvests directories from a location D:\Configrelease which
>>> has directories such as "command_processors". The produces
>>> config.wxs file that has below structure:
>>>
>>>
>>>>> Guid="{0EDAF860-B5C3-4C93-BDD7-EB1947D94749}">
>>>>> KeyPath="yes" Source="$(var.ConfigPath)\PFWConfiguration.xml" />
>>>
>>>>> Name="archives">
>>>
>>>
>>>>> Name="command_processors">
>>>>> Guid="{F2158D98-1DC2-4348-89FC-65A2115084B6}" KeyPath="yes">
>>>
>>>
>>>
>>> After i run the installer, i browse to "C:\Energy Solutions
>>> International\PFWService\config\command_processors" and keep this
>>> path open, and then uninstall the directory structure that does not
>>> get removed is "C:\Energy Solutions International\PFWService".
>>>
>>> Is it because of the in the config.wxs(as Wesley had
>>> suggest) file that heat creates that i am facing this issue. If so
>>> what is the way out. Hope i have explained the situation better this
>>> time, apologies if i created any confusion.
>>>
>>> Regards,
>>> SuvraJyoti
>>>
>>> On 17-12-2013 14:27, Suvrajyoti Panda wrote:
>>>> Hey Blair,
>>>>
>>>> The scenario you have mentioned in the first para of your response
>>>> is exactly what is happening. So is there no way that we can handle
>>>> the folder removal on uninstall even if that path is open, or this
>>>> is a known issue?
>>>>
>>>> Regards,
>>>> SuvraJyoti
>>>> On 17-12-2013 14:14, Blair Murri wrote:
>>>>> If a file being removed can't be moved, then it will be marked for
>>> removal during rebo
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
There is no way (that I know of) to delete a directory where something
has an open handle on that. The only way is to make sure all programs
have stopped and no open programs have that as their current directory.
It's just like opening cmd.exe, cd'ing to a directory and trying to
delete that directory from explorer. Can't be done.
Dave
On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
> Hi Phil,
>
> I modified the structure in my main WIX file as below:
>
>
>
> Guid="22AD76A4-448E-41DB-85A0-A04E9774A466" KeyPath="yes">
>
>
>
> After installing i traversed to "C:\Energy Solutions
> International\PFWService\config\access" then uninstalled the path
> "C:\Energy Solutions International\PFWService\" still exists, all the
> files are deleted though.
>
> On 17-12-2013 21:32, Phil Wilson wrote:
>> Why not just try a RemoveFolder and see if it solves the problem? It is
>> the most likely solution, as suggested before.
>>
>> Phil Wilson
>>
>>
>> On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda >> wrote:
>>> I just thought i needed to reiterate the issue for better clarity:
>>>
>>> Below is the directory structure in my source .wxs file:
>>>
>>>
>>>
>>>
>>> >> Guid="5DAD9B46-43BB-42D2-91E9-F2248369AA68" Win64="no">
>>> >> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>>>Type="string" />
>>>
>>> >> Guid="57240178-4A44-4C6F-A11C-B4DE99573DE0" Win64="yes">
>>> >> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>>>Type="string" />
>>>
>>>
>>>
>>>
>>>
>>>
>>> The heat harvests directories from a location D:\Configrelease which has
>>> directories such as "command_processors". The produces config.wxs file
>>> that has below structure:
>>>
>>>
>>>>> Guid="{0EDAF860-B5C3-4C93-BDD7-EB1947D94749}">
>>>>> KeyPath="yes" Source="$(var.ConfigPath)\PFWConfiguration.xml" />
>>>
>>>>> Name="archives">
>>>
>>>
>>>>> Name="command_processors">
>>>>> Guid="{F2158D98-1DC2-4348-89FC-65A2115084B6}" KeyPath="yes">
>>>
>>>
>>>
>>> After i run the installer, i browse to "C:\Energy Solutions
>>> International\PFWService\config\command_processors" and keep this path
>>> open, and then uninstall the directory structure that does not get
>>> removed is "C:\Energy Solutions International\PFWService".
>>>
>>> Is it because of the in the config.wxs(as Wesley had
>>> suggest) file that heat creates that i am facing this issue. If so what
>>> is the way out. Hope i have explained the situation better this time,
>>> apologies if i created any confusion.
>>>
>>> Regards,
>>> SuvraJyoti
>>>
>>> On 17-12-2013 14:27, Suvrajyoti Panda wrote:
>>>> Hey Blair,
>>>>
>>>> The scenario you have mentioned in the first para of your response is
>>>> exactly what is happening. So is there no way that we can handle the
>>>> folder removal on uninstall even if that path is open, or this is a
>>>> known issue?
>>>>
>>>> Regards,
>>>> SuvraJyoti
>>>> On 17-12-2013 14:14, Blair Murri wrote:
>>>>> If a file being removed can’t be moved, then it will be marked for
>>> removal during reboot, and unfortunately the folder will then be left
>>> behind (because only file delete records are placed into the reboot
>>> sequence, not folders). After reboot there isn’t an installation left to
>>> run to cleanup any further.
>>>>>
>>>>> Most of the time, files still in use can be moved (even if they are
>>> still loaded in other processes) and the folder is thus removed during the
>>> installation
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Hi Phil,
I modified the structure in my main WIX file as below:
After installing i traversed to "C:\Energy Solutions
International\PFWService\config\access" then uninstalled the path
"C:\Energy Solutions International\PFWService\" still exists, all the
files are deleted though.
On 17-12-2013 21:32, Phil Wilson wrote:
> Why not just try a RemoveFolder and see if it solves the problem? It is
> the most likely solution, as suggested before.
>
> Phil Wilson
>
>
> On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda > wrote:
>> I just thought i needed to reiterate the issue for better clarity:
>>
>> Below is the directory structure in my source .wxs file:
>>
>>
>>
>>
>> > Guid="5DAD9B46-43BB-42D2-91E9-F2248369AA68" Win64="no">
>>> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>> Type="string" />
>>
>> > Guid="57240178-4A44-4C6F-A11C-B4DE99573DE0" Win64="yes">
>>> Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
>> Type="string" />
>>
>>
>>
>>
>>
>>
>> The heat harvests directories from a location D:\Configrelease which has
>> directories such as "command_processors". The produces config.wxs file
>> that has below structure:
>>
>>
>> > Guid="{0EDAF860-B5C3-4C93-BDD7-EB1947D94749}">
>> > KeyPath="yes" Source="$(var.ConfigPath)\PFWConfiguration.xml" />
>>
>> > Name="archives">
>>
>>
>> > Name="command_processors">
>> > Guid="{F2158D98-1DC2-4348-89FC-65A2115084B6}" KeyPath="yes">
>>
>>
>>
>> After i run the installer, i browse to "C:\Energy Solutions
>> International\PFWService\config\command_processors" and keep this path
>> open, and then uninstall the directory structure that does not get
>> removed is "C:\Energy Solutions International\PFWService".
>>
>> Is it because of the in the config.wxs(as Wesley had
>> suggest) file that heat creates that i am facing this issue. If so what
>> is the way out. Hope i have explained the situation better this time,
>> apologies if i created any confusion.
>>
>> Regards,
>> SuvraJyoti
>>
>> On 17-12-2013 14:27, Suvrajyoti Panda wrote:
>>> Hey Blair,
>>>
>>> The scenario you have mentioned in the first para of your response is
>>> exactly what is happening. So is there no way that we can handle the
>>> folder removal on uninstall even if that path is open, or this is a
>>> known issue?
>>>
>>> Regards,
>>> SuvraJyoti
>>> On 17-12-2013 14:14, Blair Murri wrote:
>>>> If a file being removed can’t be moved, then it will be marked for
>> removal during reboot, and unfortunately the folder will then be left
>> behind (because only file delete records are placed into the reboot
>> sequence, not folders). After reboot there isn’t an installation left to
>> run to cleanup any further.
>>>>
>>>> Most of the time, files still in use can be moved (even if they are
>> still loaded in other processes) and the folder is thus removed during the
>> installation transaction (before the reboot) and the moved file is then
>> removed as part of the reboot sequence.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -Blair
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: Suvrajyoti Panda
>>>> Sent: Monday, December 16, 2013 8:57 PM
>>>> To: General discussion for Windows Installer XML toolset.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> No Wesley, I have not used any create folder over here.
>>>>
>>>> Regards,
>>>> SuvraJyoti
>>>>
>>>> On 16-12-2013 20:03, Wesley Manning wrote:
>>>>> Did you use CreateFolder to create this directory? If so I think you
>> need to use RemoveFolder to remove the folder. Not
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Why not just try a RemoveFolder and see if it solves the problem? It is
the most likely solution, as suggested before.
Phil Wilson
On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda wrote:
> I just thought i needed to reiterate the issue for better clarity:
>
> Below is the directory structure in my source .wxs file:
>
>
>
>
> Guid="5DAD9B46-43BB-42D2-91E9-F2248369AA68" Win64="no">
>Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
> Type="string" />
>
> Guid="57240178-4A44-4C6F-A11C-B4DE99573DE0" Win64="yes">
>Key="SOFTWARE\[Manufacturer]" Name="ConfigPath" Value="[CONFIG]"
> Type="string" />
>
>
>
>
>
>
> The heat harvests directories from a location D:\Configrelease which has
> directories such as "command_processors". The produces config.wxs file
> that has below structure:
>
>
> Guid="{0EDAF860-B5C3-4C93-BDD7-EB1947D94749}">
> KeyPath="yes" Source="$(var.ConfigPath)\PFWConfiguration.xml" />
>
> Name="archives">
>
>
> Name="command_processors">
> Guid="{F2158D98-1DC2-4348-89FC-65A2115084B6}" KeyPath="yes">
>
>
>
> After i run the installer, i browse to "C:\Energy Solutions
> International\PFWService\config\command_processors" and keep this path
> open, and then uninstall the directory structure that does not get
> removed is "C:\Energy Solutions International\PFWService".
>
> Is it because of the in the config.wxs(as Wesley had
> suggest) file that heat creates that i am facing this issue. If so what
> is the way out. Hope i have explained the situation better this time,
> apologies if i created any confusion.
>
> Regards,
> SuvraJyoti
>
> On 17-12-2013 14:27, Suvrajyoti Panda wrote:
> > Hey Blair,
> >
> > The scenario you have mentioned in the first para of your response is
> > exactly what is happening. So is there no way that we can handle the
> > folder removal on uninstall even if that path is open, or this is a
> > known issue?
> >
> > Regards,
> > SuvraJyoti
> > On 17-12-2013 14:14, Blair Murri wrote:
> >> If a file being removed can’t be moved, then it will be marked for
> removal during reboot, and unfortunately the folder will then be left
> behind (because only file delete records are placed into the reboot
> sequence, not folders). After reboot there isn’t an installation left to
> run to cleanup any further.
> >>
> >>
> >> Most of the time, files still in use can be moved (even if they are
> still loaded in other processes) and the folder is thus removed during the
> installation transaction (before the reboot) and the moved file is then
> removed as part of the reboot sequence.
> >>
> >>
> >>
> >>
> >>
> >>
> >> -Blair
> >>
> >>
> >>
> >>
> >>
> >> From: Suvrajyoti Panda
> >> Sent: Monday, December 16, 2013 8:57 PM
> >> To: General discussion for Windows Installer XML toolset.
> >>
> >>
> >>
> >>
> >>
> >> No Wesley, I have not used any create folder over here.
> >>
> >> Regards,
> >> SuvraJyoti
> >>
> >> On 16-12-2013 20:03, Wesley Manning wrote:
> >>> Did you use CreateFolder to create this directory? If so I think you
> need to use RemoveFolder to remove the folder. Not sure about that though.
> >>>
> >>> -Original Message-
> >>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
> >>> Sent: December-16-13 12:37 AM
> >>> To: General discussion about the WiX toolset.
> >>> Subject: Re: [WiX-users] Uninstall by Installer not removing the path
> created if that path is open on the system
> >>>
> >>> Hey Wesley,
> >>>
> >>> checked it on a reboot, that does not work. The structure is still
> there. Any others suggestions guys?
> >>>
> >>> Regards,
> >>> SuvraJyoti
> >>> On 13-12-2013 20:13, Wesley Manning wrote:
> >>>> It might be removed on a reboot. If you had folder op
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
I just thought i needed to reiterate the issue for better clarity:
Below is the directory structure in my source .wxs file:
The heat harvests directories from a location D:\Configrelease which has
directories such as "command_processors". The produces config.wxs file
that has below structure:
After i run the installer, i browse to "C:\Energy Solutions
International\PFWService\config\command_processors" and keep this path
open, and then uninstall the directory structure that does not get
removed is "C:\Energy Solutions International\PFWService".
Is it because of the in the config.wxs(as Wesley had
suggest) file that heat creates that i am facing this issue. If so what
is the way out. Hope i have explained the situation better this time,
apologies if i created any confusion.
Regards,
SuvraJyoti
On 17-12-2013 14:27, Suvrajyoti Panda wrote:
> Hey Blair,
>
> The scenario you have mentioned in the first para of your response is
> exactly what is happening. So is there no way that we can handle the
> folder removal on uninstall even if that path is open, or this is a
> known issue?
>
> Regards,
> SuvraJyoti
> On 17-12-2013 14:14, Blair Murri wrote:
>> If a file being removed can’t be moved, then it will be marked for removal
>> during reboot, and unfortunately the folder will then be left behind
>> (because only file delete records are placed into the reboot sequence, not
>> folders). After reboot there isn’t an installation left to run to cleanup
>> any further.
>>
>>
>> Most of the time, files still in use can be moved (even if they are still
>> loaded in other processes) and the folder is thus removed during the
>> installation transaction (before the reboot) and the moved file is then
>> removed as part of the reboot sequence.
>>
>>
>>
>>
>>
>>
>> -Blair
>>
>>
>>
>>
>>
>> From: Suvrajyoti Panda
>> Sent: Monday, December 16, 2013 8:57 PM
>> To: General discussion for Windows Installer XML toolset.
>>
>>
>>
>>
>>
>> No Wesley, I have not used any create folder over here.
>>
>> Regards,
>> SuvraJyoti
>>
>> On 16-12-2013 20:03, Wesley Manning wrote:
>>> Did you use CreateFolder to create this directory? If so I think you need
>>> to use RemoveFolder to remove the folder. Not sure about that though.
>>>
>>> -Original Message-
>>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>>> Sent: December-16-13 12:37 AM
>>> To: General discussion about the WiX toolset.
>>> Subject: Re: [WiX-users] Uninstall by Installer not removing the path
>>> created if that path is open on the system
>>>
>>> Hey Wesley,
>>>
>>> checked it on a reboot, that does not work. The structure is still there.
>>> Any others suggestions guys?
>>>
>>> Regards,
>>> SuvraJyoti
>>> On 13-12-2013 20:13, Wesley Manning wrote:
>>>> It might be removed on a reboot. If you had folder open, then windows
>>>> installer can't uninstall it. But I think it marks it for removal. I
>>>> know for sure files have this behaviour but I'm not sure about folders.
>>>>
>>>> -Original Message-
>>>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>>>> Sent: December-13-13 1:48 AM
>>>> To: General discussion about the WiX toolset.
>>>> Subject: [WiX-users] Uninstall by Installer not removing the path
>>>> created if that path is open on the system
>>>>
>>>> Hi All,
>>>>
>>>> I just saw this behaviour. My installer creates the following :"C:\Energy
>>>> Solutions International\PFWService\config", if this path is open and i run
>>>> the uninstall from control panel, then the path remains("C:\Energy
>>>> Solutions International\PFWService\config") although files under it is
>>>> removed. Is it expected behavior or incorrect. If incorrect what is the
>>>> workaround for the same.
>>>>
>>>> Regards,
>>>> SuvraJyoti
>>>>
>>>> --
>>>> Rapidly troubleshoot p
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Hey Blair,
The scenario you have mentioned in the first para of your response is
exactly what is happening. So is there no way that we can handle the
folder removal on uninstall even if that path is open, or this is a
known issue?
Regards,
SuvraJyoti
On 17-12-2013 14:14, Blair Murri wrote:
> If a file being removed can’t be moved, then it will be marked for removal
> during reboot, and unfortunately the folder will then be left behind (because
> only file delete records are placed into the reboot sequence, not folders).
> After reboot there isn’t an installation left to run to cleanup any further.
>
>
> Most of the time, files still in use can be moved (even if they are still
> loaded in other processes) and the folder is thus removed during the
> installation transaction (before the reboot) and the moved file is then
> removed as part of the reboot sequence.
>
>
>
>
>
>
> -Blair
>
>
>
>
>
> From: Suvrajyoti Panda
> Sent: Monday, December 16, 2013 8:57 PM
> To: General discussion for Windows Installer XML toolset.
>
>
>
>
>
> No Wesley, I have not used any create folder over here.
>
> Regards,
> SuvraJyoti
>
> On 16-12-2013 20:03, Wesley Manning wrote:
>> Did you use CreateFolder to create this directory? If so I think you need
>> to use RemoveFolder to remove the folder. Not sure about that though.
>>
>> -Original Message-
>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>> Sent: December-16-13 12:37 AM
>> To: General discussion about the WiX toolset.
>> Subject: Re: [WiX-users] Uninstall by Installer not removing the path
>> created if that path is open on the system
>>
>> Hey Wesley,
>>
>> checked it on a reboot, that does not work. The structure is still there.
>> Any others suggestions guys?
>>
>> Regards,
>> SuvraJyoti
>> On 13-12-2013 20:13, Wesley Manning wrote:
>>> It might be removed on a reboot. If you had folder open, then windows
>>> installer can't uninstall it. But I think it marks it for removal. I know
>>> for sure files have this behaviour but I'm not sure about folders.
>>>
>>> -Original Message-
>>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>>> Sent: December-13-13 1:48 AM
>>> To: General discussion about the WiX toolset.
>>> Subject: [WiX-users] Uninstall by Installer not removing the path
>>> created if that path is open on the system
>>>
>>> Hi All,
>>>
>>> I just saw this behaviour. My installer creates the following :"C:\Energy
>>> Solutions International\PFWService\config", if this path is open and i run
>>> the uninstall from control panel, then the path remains("C:\Energy
>>> Solutions International\PFWService\config") although files under it is
>>> removed. Is it expected behavior or incorrect. If incorrect what is the
>>> workaround for the same.
>>>
>>> Regards,
>>> SuvraJyoti
>>>
>>> --
>>> Rapidly troubleshoot problems before they affect your
>>> business. Most IT organizations don't have a clear picture of how
>>> application performance affects their revenue. With AppDynamics, you get
>>> 100% visibility into your Java,.NET, & PHP application. Start your 15-day
>>> FREE TRIAL of AppDynamics Pro!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c
>>> lktrk ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>> --
>>> Rapidly troubleshoot problems before they affect your
>>> business. Most IT organizations don't have a clear picture of how
>>> application performance affects their revenue. With AppDynamics, you
>>> get 100% visibility into your Java,.NET, & PHP application. Start your
>>> 15-day FREE TRIAL of AppDynamics Pro!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c
>>> lktrk ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>> --
>> Rapidly troubleshoot problems before t
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
If a file being removed can’t be moved, then it will be marked for removal
during reboot, and unfortunately the folder will then be left behind (because
only file delete records are placed into the reboot sequence, not folders).
After reboot there isn’t an installation left to run to cleanup any further.
Most of the time, files still in use can be moved (even if they are still
loaded in other processes) and the folder is thus removed during the
installation transaction (before the reboot) and the moved file is then removed
as part of the reboot sequence.
-Blair
From: Suvrajyoti Panda
Sent: Monday, December 16, 2013 8:57 PM
To: General discussion for Windows Installer XML toolset.
No Wesley, I have not used any create folder over here.
Regards,
SuvraJyoti
On 16-12-2013 20:03, Wesley Manning wrote:
> Did you use CreateFolder to create this directory? If so I think you need to
> use RemoveFolder to remove the folder. Not sure about that though.
>
> -Original Message-
> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
> Sent: December-16-13 12:37 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
> if that path is open on the system
>
> Hey Wesley,
>
> checked it on a reboot, that does not work. The structure is still there. Any
> others suggestions guys?
>
> Regards,
> SuvraJyoti
> On 13-12-2013 20:13, Wesley Manning wrote:
>> It might be removed on a reboot. If you had folder open, then windows
>> installer can't uninstall it. But I think it marks it for removal. I know
>> for sure files have this behaviour but I'm not sure about folders.
>>
>> -Original Message-
>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>> Sent: December-13-13 1:48 AM
>> To: General discussion about the WiX toolset.
>> Subject: [WiX-users] Uninstall by Installer not removing the path
>> created if that path is open on the system
>>
>> Hi All,
>>
>> I just saw this behaviour. My installer creates the following :"C:\Energy
>> Solutions International\PFWService\config", if this path is open and i run
>> the uninstall from control panel, then the path remains("C:\Energy Solutions
>> International\PFWService\config") although files under it is removed. Is it
>> expected behavior or incorrect. If incorrect what is the workaround for the
>> same.
>>
>> Regards,
>> SuvraJyoti
>>
>> --
>> Rapidly troubleshoot problems before they affect your
>> business. Most IT organizations don't have a clear picture of how
>> application performance affects their revenue. With AppDynamics, you get
>> 100% visibility into your Java,.NET, & PHP application. Start your 15-day
>> FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c
>> lktrk ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> --
>> Rapidly troubleshoot problems before they affect your
>> business. Most IT organizations don't have a clear picture of how
>> application performance affects their revenue. With AppDynamics, you
>> get 100% visibility into your Java,.NET, & PHP application. Start your
>> 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c
>> lktrk ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
>
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
No Wesley, I have not used any create folder over here.
Regards,
SuvraJyoti
On 16-12-2013 20:03, Wesley Manning wrote:
> Did you use CreateFolder to create this directory? If so I think you need to
> use RemoveFolder to remove the folder. Not sure about that though.
>
> -Original Message-
> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
> Sent: December-16-13 12:37 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
> if that path is open on the system
>
> Hey Wesley,
>
> checked it on a reboot, that does not work. The structure is still there. Any
> others suggestions guys?
>
> Regards,
> SuvraJyoti
> On 13-12-2013 20:13, Wesley Manning wrote:
>> It might be removed on a reboot. If you had folder open, then windows
>> installer can't uninstall it. But I think it marks it for removal. I know
>> for sure files have this behaviour but I'm not sure about folders.
>>
>> -Original Message-
>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>> Sent: December-13-13 1:48 AM
>> To: General discussion about the WiX toolset.
>> Subject: [WiX-users] Uninstall by Installer not removing the path
>> created if that path is open on the system
>>
>> Hi All,
>>
>> I just saw this behaviour. My installer creates the following :"C:\Energy
>> Solutions International\PFWService\config", if this path is open and i run
>> the uninstall from control panel, then the path remains("C:\Energy Solutions
>> International\PFWService\config") although files under it is removed. Is it
>> expected behavior or incorrect. If incorrect what is the workaround for the
>> same.
>>
>> Regards,
>> SuvraJyoti
>>
>> --
>> Rapidly troubleshoot problems before they affect your
>> business. Most IT organizations don't have a clear picture of how
>> application performance affects their revenue. With AppDynamics, you get
>> 100% visibility into your Java,.NET, & PHP application. Start your 15-day
>> FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c
>> lktrk ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> --
>> Rapidly troubleshoot problems before they affect your
>> business. Most IT organizations don't have a clear picture of how
>> application performance affects their revenue. With AppDynamics, you
>> get 100% visibility into your Java,.NET, & PHP application. Start your
>> 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c
>> lktrk ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
mNo
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Did you use CreateFolder to create this directory? If so I think you need to
use RemoveFolder to remove the folder. Not sure about that though.
-Original Message-
From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
Sent: December-16-13 12:37 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
if that path is open on the system
Hey Wesley,
checked it on a reboot, that does not work. The structure is still there. Any
others suggestions guys?
Regards,
SuvraJyoti
On 13-12-2013 20:13, Wesley Manning wrote:
> It might be removed on a reboot. If you had folder open, then windows
> installer can't uninstall it. But I think it marks it for removal. I know
> for sure files have this behaviour but I'm not sure about folders.
>
> -Original Message-
> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
> Sent: December-13-13 1:48 AM
> To: General discussion about the WiX toolset.
> Subject: [WiX-users] Uninstall by Installer not removing the path
> created if that path is open on the system
>
> Hi All,
>
> I just saw this behaviour. My installer creates the following :"C:\Energy
> Solutions International\PFWService\config", if this path is open and i run
> the uninstall from control panel, then the path remains("C:\Energy Solutions
> International\PFWService\config") although files under it is removed. Is it
> expected behavior or incorrect. If incorrect what is the workaround for the
> same.
>
> Regards,
> SuvraJyoti
>
> --
> Rapidly troubleshoot problems before they affect your
> business. Most IT organizations don't have a clear picture of how application
> performance affects their revenue. With AppDynamics, you get 100% visibility
> into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c
> lktrk ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> --
> Rapidly troubleshoot problems before they affect your
> business. Most IT organizations don't have a clear picture of how
> application performance affects their revenue. With AppDynamics, you
> get 100% visibility into your Java,.NET, & PHP application. Start your
> 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.c
> lktrk ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance affects
their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, &
PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Hey Wesley,
checked it on a reboot, that does not work. The structure is still
there. Any others suggestions guys?
Regards,
SuvraJyoti
On 13-12-2013 20:13, Wesley Manning wrote:
> It might be removed on a reboot. If you had folder open, then windows
> installer can't uninstall it. But I think it marks it for removal. I know
> for sure files have this behaviour but I'm not sure about folders.
>
> -Original Message-
> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
> Sent: December-13-13 1:48 AM
> To: General discussion about the WiX toolset.
> Subject: [WiX-users] Uninstall by Installer not removing the path created if
> that path is open on the system
>
> Hi All,
>
> I just saw this behaviour. My installer creates the following :"C:\Energy
> Solutions International\PFWService\config", if this path is open and i run
> the uninstall from control panel, then the path remains("C:\Energy Solutions
> International\PFWService\config") although files under it is removed. Is it
> expected behavior or incorrect. If incorrect what is the workaround for the
> same.
>
> Regards,
> SuvraJyoti
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
It might be removed on a reboot. If you had folder open, then windows
installer can't uninstall it. But I think it marks it for removal. I know for
sure files have this behaviour but I'm not sure about folders.
-Original Message-
From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
Sent: December-13-13 1:48 AM
To: General discussion about the WiX toolset.
Subject: [WiX-users] Uninstall by Installer not removing the path created if
that path is open on the system
Hi All,
I just saw this behaviour. My installer creates the following :"C:\Energy
Solutions International\PFWService\config", if this path is open and i run the
uninstall from control panel, then the path remains("C:\Energy Solutions
International\PFWService\config") although files under it is removed. Is it
expected behavior or incorrect. If incorrect what is the workaround for the
same.
Regards,
SuvraJyoti
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance affects
their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, &
PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Hi All,
I just saw this behaviour. My installer creates the following
:"C:\Energy Solutions International\PFWService\config", if this path is
open and i run the uninstall from control panel, then the path
remains("C:\Energy Solutions International\PFWService\config") although
files under it is removed. Is it expected behavior or incorrect. If
incorrect what is the workaround for the same.
Regards,
SuvraJyoti
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall previous version with new version
Product\@Id = ProductCode property Product\@Version = ProductVersion property Correct. I believe both of these are documented in the CHM file. If not, please raise a bug. > From: mri...@realtyim.com > To: wix-users@lists.sourceforge.net > Date: Fri, 20 Sep 2013 17:12:09 + > Subject: Re: [WiX-users] Uninstall previous version with new version > > Thank you Blair. In my wxs file I see a Product element with an Id attribute > - I found a webpage that says that this is the ProductCode. Can you confirm? > That appears to be static in my case so I suspect the problem is with the > version number which is also static at "1.0.0.0" - I will need to find out > how to update that within TFS. > > Cheers! > .Mark > > > -Original Message- > From: Blair Murri [mailto:os...@live.com] > Sent: Thursday, September 19, 2013 10:43 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Uninstall previous version with new version > > They have to be minor upgrades of each other (i.e. share the same > ProductCode). The three downsides that immediately come to mind are that you > cannot double-click version 2.msi and succeed at installing it (you have to > supply a special command-line), if the version 2.msi isn't identically named > the same as version 1 was then you can't ever even install it, and if you > (re)move any components or otherwise break any component rules you orphan all > of your resources and leave the entire product "advertised and not installed" > without any of the resources actually removed (which can be fixed by > immediately repairing, but that is very counter-intuitive). Also the upgrades > do not use the Upgrade table (which is ignored during minor upgrades). > > > From: mri...@realtyim.com > > To: wix-users@lists.sourceforge.net > > Date: Fri, 20 Sep 2013 01:03:36 + > > Subject: [WiX-users] Uninstall previous version with new version > > > > I remember using this feature from the past. I would have an .msi that is > > version 1 and another being version 2. I install version 1 on my machine > > and then I am able to right click the version 2 .msi and select "uninstall" > > and have it succeed. > > > > Does anyone know how to do this? It's quite convenient. > > -- > > LIMITED TIME SALE - Full Year of Microsoft Training For Just > > $49.99! > > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > > SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library > > Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! > > Ends 9/20/13. > > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.c > > lktrk ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall removing user data
Thanks Phil. I'm not sure why I was thinking that a version of the create/modified check also applied to uninstalls. I turned 40 this week so I guess it's all downhill from here... From: "Phil Wilson" Sent: Sunday, September 22, 2013 12:08 PM To: chr...@iswix.com, "General discussion for Windows Installer XML toolset." Subject: Re: [WiX-users] Uninstall removing user data The rule is that if MSI installs it, then an uninstall will uninstall it. The modify/creation date difference is what determines whether to overwrite it, not uninstall it. User data is created by the app, not installed with the app, in this context that's the way I look at it.(Unless I'm having a senior moment too) Phil Wilson On Sat, Sep 21, 2013 at 10:50 AM, Christopher Painter wrote: I'm having a senior moment with what seemed like a pretty simple and well established concept in windows installer: don't uninstall user data. I created a very simple installer with a single component / file ( test.txt ). I tested with test.txt as the key file and with no key file ( directory). In the test (on a clean VM of course ) I wanted to see if uninstall would leave the file behind after I had modified the file to contain user data. Despite the creation data and modification date of the file being different, MSI always uninstalled the file. I'm a little puzzled as I didn't expect this. Am I forgetting something? -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall removing user data
The rule is that if MSI installs it, then an uninstall will uninstall it. The modify/creation date difference is what determines whether to overwrite it, not uninstall it. User data is created by the app, not installed with the app, in this context that's the way I look at it. (Unless I'm having a senior moment too) Phil Wilson On Sat, Sep 21, 2013 at 10:50 AM, Christopher Painter wrote: > I'm having a senior moment with what seemed like a pretty simple and well > established concept in windows installer: don't uninstall user data. > > I created a very simple installer with a single component / file ( > test.txt ). I tested with test.txt as the key file and with no key file ( > directory). In the test (on a clean VM of course ) I wanted to see if > uninstall would leave the file behind after I had modified the file to > contain user data. > > Despite the creation data and modification date of the file being > different, MSI always uninstalled the file. > > I'm a little puzzled as I didn't expect this. Am I forgetting something? > > > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. > http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall removing user data
I'm having a senior moment with what seemed like a pretty simple and well established concept in windows installer: don't uninstall user data. I created a very simple installer with a single component / file ( test.txt ). I tested with test.txt as the key file and with no key file ( directory). In the test (on a clean VM of course ) I wanted to see if uninstall would leave the file behind after I had modified the file to contain user data. Despite the creation data and modification date of the file being different, MSI always uninstalled the file. I'm a little puzzled as I didn't expect this. Am I forgetting something? -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall previous version with new version
Thank you Blair. In my wxs file I see a Product element with an Id attribute - I found a webpage that says that this is the ProductCode. Can you confirm? That appears to be static in my case so I suspect the problem is with the version number which is also static at "1.0.0.0" - I will need to find out how to update that within TFS. Cheers! .Mark -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: Thursday, September 19, 2013 10:43 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Uninstall previous version with new version They have to be minor upgrades of each other (i.e. share the same ProductCode). The three downsides that immediately come to mind are that you cannot double-click version 2.msi and succeed at installing it (you have to supply a special command-line), if the version 2.msi isn't identically named the same as version 1 was then you can't ever even install it, and if you (re)move any components or otherwise break any component rules you orphan all of your resources and leave the entire product "advertised and not installed" without any of the resources actually removed (which can be fixed by immediately repairing, but that is very counter-intuitive). Also the upgrades do not use the Upgrade table (which is ignored during minor upgrades). > From: mri...@realtyim.com > To: wix-users@lists.sourceforge.net > Date: Fri, 20 Sep 2013 01:03:36 + > Subject: [WiX-users] Uninstall previous version with new version > > I remember using this feature from the past. I would have an .msi that is > version 1 and another being version 2. I install version 1 on my machine and > then I am able to right click the version 2 .msi and select "uninstall" and > have it succeed. > > Does anyone know how to do this? It's quite convenient. > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just > $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library > Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! > Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.c > lktrk ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall previous version with new version
They have to be minor upgrades of each other (i.e. share the same ProductCode). The three downsides that immediately come to mind are that you cannot double-click version 2.msi and succeed at installing it (you have to supply a special command-line), if the version 2.msi isn't identically named the same as version 1 was then you can't ever even install it, and if you (re)move any components or otherwise break any component rules you orphan all of your resources and leave the entire product "advertised and not installed" without any of the resources actually removed (which can be fixed by immediately repairing, but that is very counter-intuitive). Also the upgrades do not use the Upgrade table (which is ignored during minor upgrades). > From: mri...@realtyim.com > To: wix-users@lists.sourceforge.net > Date: Fri, 20 Sep 2013 01:03:36 + > Subject: [WiX-users] Uninstall previous version with new version > > I remember using this feature from the past. I would have an .msi that is > version 1 and another being version 2. I install version 1 on my machine and > then I am able to right click the version 2 .msi and select "uninstall" and > have it succeed. > > Does anyone know how to do this? It's quite convenient. > -- > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall previous version with new version
I remember using this feature from the past. I would have an .msi that is version 1 and another being version 2. I install version 1 on my machine and then I am able to right click the version 2 .msi and select "uninstall" and have it succeed. Does anyone know how to do this? It's quite convenient. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall bundle by name ?
This is just a wild idea, but could you create a bundle (with a product search), which you use to stage your test project (uninstall the old and install the new)? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-bundle-by-name-tp7588776p7588826.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall bundle by name ?
Hi,
What we did is build a front end that builds an "uninstall message" when the
package is built (again by the front end, but you could use a build script or
something maybe) and uses our install-and-monitor software to parse it when it
arrives. You'd need SCCM or Afaria or other tools like that to make use of
this, in all likelihood. (Maybe Task Scheduler and some Powershell would be
sufficient.)
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-951-4405
Facsimile | Télécopieur 613-951-1966
Government of Canada | Gouvernement du Canada
-Original Message-
From: robert_y...@agilent.com [mailto:robert_y...@agilent.com]
Sent: September-04-13 6:57 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Uninstall bundle by name ?
Hi all - I've managed to upgrade some of our installs to Wix 3.7 with the burn
bootstrapper, hooray !
One thing I haven't quite anticipated is this: after our automated build we
need to push a newly-built installer to a test machine for an automated
smoke/sanity test. First we need to uninstall the old build and install the
new one (silently, can't just use control panel). I know it's possible to run
the old Setup.exe with the "/quiet /uninstall" command-line params, but is that
the only way ?
With MSI's we could run "msiexec /x {product ID}" to do the uninstall. Is
there some way to silently run the uninstall by product name or some other ID
which doesn't change from build to build ? It would be nice not to have to
keep the old bundle around for the uninstall.
Thanks for any info !
-Rob
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies and
advance your career. Get an incredible 1,500+ hours of step-by-step tutorial
videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall bundle by name ?
Nothing that is documented today.
On Wed, Sep 4, 2013 at 3:57 PM, wrote:
> Hi all - I've managed to upgrade some of our installs to Wix 3.7 with the
> burn bootstrapper, hooray !
>
> One thing I haven't quite anticipated is this: after our automated build
> we need to push a newly-built installer to a test machine for an automated
> smoke/sanity test. First we need to uninstall the old build and install
> the new one (silently, can't just use control panel). I know it's possible
> to run the old Setup.exe with the "/quiet /uninstall" command-line params,
> but is that the only way ?
>
> With MSI's we could run "msiexec /x {product ID}" to do the uninstall. Is
> there some way to silently run the uninstall by product name or some other
> ID which doesn't change from build to build ? It would be nice not to have
> to keep the old bundle around for the uninstall.
>
> Thanks for any info !
> -Rob
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall bundle by name ?
Hi all - I've managed to upgrade some of our installs to Wix 3.7 with the burn
bootstrapper, hooray !
One thing I haven't quite anticipated is this: after our automated build we
need to push a newly-built installer to a test machine for an automated
smoke/sanity test. First we need to uninstall the old build and install the
new one (silently, can't just use control panel). I know it's possible to run
the old Setup.exe with the "/quiet /uninstall" command-line params, but is that
the only way ?
With MSI's we could run "msiexec /x {product ID}" to do the uninstall. Is
there some way to silently run the uninstall by product name or some other ID
which doesn't change from build to build ? It would be nice not to have to
keep the old bundle around for the uninstall.
Thanks for any info !
-Rob
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall ApplyComplete status
The engine always returns an HRESULT in the ApplyComplete event. Converted to hex, you're getting 0x8007015E. 0x015E, or 350, is ERROR_FAIL_NOACTION_REBOOT (from WinError.h). I also see the engine raising the Error event in this case, where it sends the error code 350. I think the only thing you can do at that point is ask the user to reboot. Hope that helps, Sean > From: hanspett...@prediktor.no > To: wix-users@lists.sourceforge.net > Date: Tue, 3 Sep 2013 11:09:01 +0000 > Subject: [WiX-users] uninstall ApplyComplete status > > Hello, > I am trying to uninstall a installed program while there is a pending system > restart. > We have used Burn to create the BA, and the ApplyComplete event sends > ApplyCompleteEventArgs with status -2147024546. > I have problems to interpret the status code and handle this properly. > Is there an overview of what the different values means? > Any idea how to handle and interpret this? > > > Regards > Hans Petter > > > > > -- > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] uninstall ApplyComplete status
Hello, I am trying to uninstall a installed program while there is a pending system restart. We have used Burn to create the BA, and the ApplyComplete event sends ApplyCompleteEventArgs with status -2147024546. I have problems to interpret the status code and handle this properly. Is there an overview of what the different values means? Any idea how to handle and interpret this? Regards Hans Petter -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall on W7 with activated UAC from ARP: No UAC elevation prompt
It's ARP being magical. Never quite tracked down how they did it. Fortunately, Burn is smart enough to recognize that it is already elevated and doesn't ask again. On Thu, Jul 25, 2013 at 3:55 AM, Tobias S wrote: > Any idea on that behavior? Feedback highly appreciated. > > Best regards, > Tobias > > > 2013/7/16 Tobias S > > > Hi, > > > > Didn't find any answer related to this on the mailing list yet. > > > > Have following behavior on Win7 VMs with Custom BAL as well as when using > > BootstrapperApplicationRef Id=" > > WixStandardBootstrapperApplication.RtfLicense". There is no UAC prompt > > when uninstalling a bundle from ARP. When doing the same with a > standalone > > MSI deployed with the bundle there is one as expected. > > > > Mean as the installation is working properly I don't care about that > > behavior but I definitely would expect an UAC prompt here. Any clue why > > this is not show here? Is the OS doing here something like "Ah this user > > installed the package so I don't need to ask him again whether it is ok > to > > uninstall it" ? > > > > Thanks and best regards, > > Tobias > > > > -- > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall on W7 with activated UAC from ARP: No UAC elevation prompt
Any idea on that behavior? Feedback highly appreciated. Best regards, Tobias 2013/7/16 Tobias S > Hi, > > Didn't find any answer related to this on the mailing list yet. > > Have following behavior on Win7 VMs with Custom BAL as well as when using > BootstrapperApplicationRef Id=" > WixStandardBootstrapperApplication.RtfLicense". There is no UAC prompt > when uninstalling a bundle from ARP. When doing the same with a standalone > MSI deployed with the bundle there is one as expected. > > Mean as the installation is working properly I don't care about that > behavior but I definitely would expect an UAC prompt here. Any clue why > this is not show here? Is the OS doing here something like "Ah this user > installed the package so I don't need to ask him again whether it is ok to > uninstall it" ? > > Thanks and best regards, > Tobias > -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall on W7 with activated UAC from ARP: No UAC elevation prompt
Hi, Didn't find any answer related to this on the mailing list yet. Have following behavior on Win7 VMs with Custom BAL as well as when using BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense ". There is no UAC prompt when uninstalling a bundle from ARP. When doing the same with a standalone MSI deployed with the bundle there is one as expected. Mean as the installation is working properly I don't care about that behavior but I definitely would expect an UAC prompt here. Any clue why this is not show here? Is the OS doing here something like "Ah this user installed the package so I don't need to ask him again whether it is ok to uninstall it" ? Thanks and best regards, Tobias -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall restart issue
Just tested that and no change, unfortunately. I'll also note that when the
services were correctly uninstalling in the past, I would have the Services
window open, and I could refresh it to see that the services were completely
removed.
But in debugging, we stumbled upon the reason for this Disabled behaviour, and
Phil was right all along: I had recently started using Sysinternal's Process
Explorer to watch detailed information about the services and processes
starting and stopping, which was useful in seeing the cmd.exe/batch file
problem. However, Process Explorer, a process itself, must hook into the
services to monitor them more closely than the Task Manager or the Services
window, because the result is quite clear: When Process Explorer is open, the
services are Disabled, but not removed, but if Process Explorer is not open, I
can see our services being removed in the Services window.
I'm guessing the Services window used to do the same thing, but perhaps it's
been fixed in Windows 7.
To think our own debugging tools can turn against us and sabotage our
efforts...et tu, Brute?
Thank you for your help everyone! If anyone has any other ideas on the
cmd.exe/batch file execution that's errorneously triggering the RestartManager,
or a better way to interact with services in Java than with
Runtime.getRuntime().exec("net stop MyService"), please do let me know.
However, I think this is a sufficient workaround in the meantime.
Alain
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: June 28, 2013 16:07
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] Uninstall restart issue
Do you still have the computer management console open when doing the uninstall
(but after stopping the service)? I seem to remember bugs in the snap in that
either leaked handles or maintained an exclusive lock on the SCM that would
exhibit this behavior.
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 2:38 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I'll open by saying that I don't think this is why the services are being
disabled, because I'm not even using this part of our client yet. All I'm doing
right now to test this is installing our software, manually (in Services)
stopping our services (to "simulate" what our software would do before trying
to upgrade), and then uninstall. For some reason, this disables all the
services, but doesn't remove them until a restart. I can't imagine what process
would be interacting with our services that would lock them as you've described
though...especially since this used to work just fine before I started
debugging the other problem. Arg.
Ah, I understand what you mean. Well, Runtime.getRuntime().exec("net stop " +
serviceName) returns a Process object that can be used to monitor the process,
get the output, return values, and so on. someProcessObject.waitFor() stops the
execution of the current program until someProcessObject is done and returns.
Regarding what net stop does, whenever I open a command line, and type "net
stop MyService1", the command window sits and waits until the service stops,
and only then (or after longer than I've ever waited) does it actually give me
a command prompt again once the service has stopped.
So this seems pretty synchronous to me, although not as useful and interactive
as the ServiceController class you've described. I would prefer to use Java API
to interact with services, no such thing exists, hence net stop. I could
capture the output of net stop to confirm whether or not it was successful to
get at least some info. But yes, it's a suboptimal solution.
Had I known getting a Java application to work as a service would be such a
nightmare, I might have pushed harder to redo everything in .NET.
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:55
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Any process that wants to do something with a service (such as stop it) has a
Windows handle open to it. In managed code you'd use a ServiceController class,
and the Dispose() method in that class is explicitly there to release unmanaged
resources like that service handle. By "managed" I mean Microsoft .NET
"managed" - I don't know what your java is.
In C++ it's a bit more exposed - you'd do a Win32 OpenService() call, this
returns a handle that must be closed or you have a handle leak and a service
that can't be deleted.
On the net stop thing my cmd-style/old dos style knowledge is long gone but:
I don't
Re: [WiX-users] Uninstall restart issue
Do you still have the computer management console open when doing the uninstall
(but after stopping the service)? I seem to remember bugs in the snap in that
either leaked handles or maintained an exclusive lock on the SCM that would
exhibit this behavior.
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 2:38 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I'll open by saying that I don't think this is why the services are being
disabled, because I'm not even using this part of our client yet. All I'm doing
right now to test this is installing our software, manually (in Services)
stopping our services (to "simulate" what our software would do before trying
to upgrade), and then uninstall. For some reason, this disables all the
services, but doesn't remove them until a restart. I can't imagine what process
would be interacting with our services that would lock them as you've described
though...especially since this used to work just fine before I started
debugging the other problem. Arg.
Ah, I understand what you mean. Well, Runtime.getRuntime().exec("net stop " +
serviceName) returns a Process object that can be used to monitor the process,
get the output, return values, and so on. someProcessObject.waitFor() stops the
execution of the current program until someProcessObject is done and returns.
Regarding what net stop does, whenever I open a command line, and type "net
stop MyService1", the command window sits and waits until the service stops,
and only then (or after longer than I've ever waited) does it actually give me
a command prompt again once the service has stopped.
So this seems pretty synchronous to me, although not as useful and interactive
as the ServiceController class you've described. I would prefer to use Java API
to interact with services, no such thing exists, hence net stop. I could
capture the output of net stop to confirm whether or not it was successful to
get at least some info. But yes, it's a suboptimal solution.
Had I known getting a Java application to work as a service would be such a
nightmare, I might have pushed harder to redo everything in .NET.
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:55
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Any process that wants to do something with a service (such as stop it) has a
Windows handle open to it. In managed code you'd use a ServiceController class,
and the Dispose() method in that class is explicitly there to release unmanaged
resources like that service handle. By "managed" I mean Microsoft .NET
"managed" - I don't know what your java is.
In C++ it's a bit more exposed - you'd do a Win32 OpenService() call, this
returns a handle that must be closed or you have a handle leak and a service
that can't be deleted.
On the net stop thing my cmd-style/old dos style knowledge is long gone but:
I don't know for a fact that your net stop is synchronous. It might be that it
actually fires off a process to host the net stop, and it runs while you return
and you're in a timing race with the rest of what you're doing. It's also
possible that internally net stop just tells the service to stop but doesn't
wait for it to actually finish, in which case it's also asynchronous and you're
in a timing race. That's because stopping a service is message based. An actual
synchronous API call will tell you what's really going on, such as whether the
service asked for more time to shut down, and will return a result saying
whether it worked or not, and you can really wait for it to finish. The other
issue is that you don't actually know that your net stop worked - you're
trusting that it will be ok and the service will stop.
If your java runtime has an explicit way to stop a Windows service and wait for
it to actually finish, use that.
Phil
-----Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 11:14 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Can you clarify what you mean by "If any process has a handle open to a
service"? Isn't it the service that runs/spawns/opens a handle to a process,
and not the other way around? And isn't it the service that tries to stop the
process when the service is told to stop?
Our code is all in Java (so it's managed, as far as I know), and I use the
following to stop the services:
Runtime.getRuntime().exec("net stop " + serviceName).waitFor();
So our client stops and wait
Re: [WiX-users] Uninstall restart issue
I'll open by saying that I don't think this is why the services are being
disabled, because I'm not even using this part of our client yet. All I'm doing
right now to test this is installing our software, manually (in Services)
stopping our services (to "simulate" what our software would do before trying
to upgrade), and then uninstall. For some reason, this disables all the
services, but doesn't remove them until a restart. I can't imagine what process
would be interacting with our services that would lock them as you've described
though...especially since this used to work just fine before I started
debugging the other problem. Arg.
Ah, I understand what you mean. Well, Runtime.getRuntime().exec("net stop " +
serviceName) returns a Process object that can be used to monitor the process,
get the output, return values, and so on. someProcessObject.waitFor() stops the
execution of the current program until someProcessObject is done and returns.
Regarding what net stop does, whenever I open a command line, and type "net
stop MyService1", the command window sits and waits until the service stops,
and only then (or after longer than I've ever waited) does it actually give me
a command prompt again once the service has stopped.
So this seems pretty synchronous to me, although not as useful and interactive
as the ServiceController class you've described. I would prefer to use Java API
to interact with services, no such thing exists, hence net stop. I could
capture the output of net stop to confirm whether or not it was successful to
get at least some info. But yes, it's a suboptimal solution.
Had I known getting a Java application to work as a service would be such a
nightmare, I might have pushed harder to redo everything in .NET.
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:55
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Any process that wants to do something with a service (such as stop it) has a
Windows handle open to it. In managed code you'd use a ServiceController class,
and the Dispose() method in that class is explicitly there to release unmanaged
resources like that service handle. By "managed" I mean Microsoft .NET
"managed" - I don't know what your java is.
In C++ it's a bit more exposed - you'd do a Win32 OpenService() call, this
returns a handle that must be closed or you have a handle leak and a service
that can't be deleted.
On the net stop thing my cmd-style/old dos style knowledge is long gone but:
I don't know for a fact that your net stop is synchronous. It might be that it
actually fires off a process to host the net stop, and it runs while you return
and you're in a timing race with the rest of what you're doing. It's also
possible that internally net stop just tells the service to stop but doesn't
wait for it to actually finish, in which case it's also asynchronous and you're
in a timing race. That's because stopping a service is message based. An actual
synchronous API call will tell you what's really going on, such as whether the
service asked for more time to shut down, and will return a result saying
whether it worked or not, and you can really wait for it to finish. The other
issue is that you don't actually know that your net stop worked - you're
trusting that it will be ok and the service will stop.
If your java runtime has an explicit way to stop a Windows service and wait for
it to actually finish, use that.
Phil
-----Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 11:14 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Can you clarify what you mean by "If any process has a handle open to a
service"? Isn't it the service that runs/spawns/opens a handle to a process,
and not the other way around? And isn't it the service that tries to stop the
process when the service is told to stop?
Our code is all in Java (so it's managed, as far as I know), and I use the
following to stop the services:
Runtime.getRuntime().exec("net stop " + serviceName).waitFor();
So our client stops and waits until our service is stopped. This waiting of
indeterminate length makes me jumpy as well, but I don't know of any other
solution to this problem (of a running service that called a batch file causes
the RestartManager to think a restart is needed when it really won't
be) that we've been trying to figure out and fix for weeks.
I'm definitely open to any suggestions.
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June
Re: [WiX-users] Uninstall restart issue
Any process that wants to do something with a service (such as stop it) has
a Windows handle open to it. In managed code you'd use a ServiceController
class, and the Dispose() method in that class is explicitly there to release
unmanaged resources like that service handle. By "managed" I mean Microsoft
.NET "managed" - I don't know what your java is.
In C++ it's a bit more exposed - you'd do a Win32 OpenService() call, this
returns a handle that must be closed or you have a handle leak and a service
that can't be deleted.
On the net stop thing my cmd-style/old dos style knowledge is long gone but:
I don't know for a fact that your net stop is synchronous. It might be that
it actually fires off a process to host the net stop, and it runs while you
return and you're in a timing race with the rest of what you're doing. It's
also possible that internally net stop just tells the service to stop but
doesn't wait for it to actually finish, in which case it's also asynchronous
and you're in a timing race. That's because stopping a service is message
based. An actual synchronous API call will tell you what's really going on,
such as whether the service asked for more time to shut down, and will
return a result saying whether it worked or not, and you can really wait for
it to finish. The other issue is that you don't actually know that your net
stop worked - you're trusting that it will be ok and the service will stop.
If your java runtime has an explicit way to stop a Windows service and wait
for it to actually finish, use that.
Phil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 11:14 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Can you clarify what you mean by "If any process has a handle open to a
service"? Isn't it the service that runs/spawns/opens a handle to a process,
and not the other way around? And isn't it the service that tries to stop
the process when the service is told to stop?
Our code is all in Java (so it's managed, as far as I know), and I use the
following to stop the services:
Runtime.getRuntime().exec("net stop " + serviceName).waitFor();
So our client stops and waits until our service is stopped. This waiting of
indeterminate length makes me jumpy as well, but I don't know of any other
solution to this problem (of a running service that called a batch file
causes the RestartManager to think a restart is needed when it really won't
be) that we've been trying to figure out and fix for weeks.
I'm definitely open to any suggestions.
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:03
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I've mentioned this before, but I don't recall if it was in connection with
this thread...
If any process has a handle open to a service, then Windows can't delete it
so it gets marked disabled. In code this tends to be code that doesn't close
handles , whether explicitly in C++ or in managed code ServiceControllers by
failure to Dispose().
Personally I wouldn't use anything asynchronous or of indeterminate length
such as net stop in a cmd shell. If you're seeing something timing-related,
that may be where the issue is. Even in C++ the code to stop a service is
not complicated and is much more manageable than a command shell.
Phil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 7:07 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Yes, the cmd.exe is from a .bat file the service executes. Making it
read-only did give the uninstaller pause as it took longer before finally
deciding to still request a restart.
One of my team members pointed something out that I should have realised:
Since this problem is mainly causing problems when our software was
auto-updating itself, we can run "net stop MyServiceX" from our own client
before it runs the downloaded installer. Although this doesn't "solve" the
problem, I think it sufficiently circumvents the problem for our purposes
(especially given the ridiculous amount of time and effort we've sunken into
it, including everyone here who has so graciously helped!).
However, we now have a new problem where, during uninstall, the services are
sometimes only disabled but not removed (although other times they are
removed without problem, and I haven't figured out why it's intermittent).
This new problem seems to have begun since we started using the
ServiceInstall, and relying on the ServiceControl element to
Re: [WiX-users] Uninstall restart issue
Can you clarify what you mean by "If any process has a handle open to a
service"? Isn't it the service that runs/spawns/opens a handle to a process,
and not the other way around? And isn't it the service that tries to stop the
process when the service is told to stop?
Our code is all in Java (so it's managed, as far as I know), and I use the
following to stop the services:
Runtime.getRuntime().exec("net stop " + serviceName).waitFor();
So our client stops and waits until our service is stopped. This waiting of
indeterminate length makes me jumpy as well, but I don't know of any other
solution to this problem (of a running service that called a batch file causes
the RestartManager to think a restart is needed when it really won't be) that
we've been trying to figure out and fix for weeks.
I'm definitely open to any suggestions.
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:03
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I've mentioned this before, but I don't recall if it was in connection with
this thread...
If any process has a handle open to a service, then Windows can't delete it so
it gets marked disabled. In code this tends to be code that doesn't close
handles , whether explicitly in C++ or in managed code ServiceControllers by
failure to Dispose().
Personally I wouldn't use anything asynchronous or of indeterminate length such
as net stop in a cmd shell. If you're seeing something timing-related, that may
be where the issue is. Even in C++ the code to stop a service is not
complicated and is much more manageable than a command shell.
Phil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 7:07 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Yes, the cmd.exe is from a .bat file the service executes. Making it read-only
did give the uninstaller pause as it took longer before finally deciding to
still request a restart.
One of my team members pointed something out that I should have realised:
Since this problem is mainly causing problems when our software was
auto-updating itself, we can run "net stop MyServiceX" from our own client
before it runs the downloaded installer. Although this doesn't "solve" the
problem, I think it sufficiently circumvents the problem for our purposes
(especially given the ridiculous amount of time and effort we've sunken into
it, including everyone here who has so graciously helped!).
However, we now have a new problem where, during uninstall, the services are
sometimes only disabled but not removed (although other times they are removed
without problem, and I haven't figured out why it's intermittent).
This new problem seems to have begun since we started using the ServiceInstall,
and relying on the ServiceControl element to remove our
service:
Before this, we used a CA to run "jsl.exe -remove MySensor1JSLConfig.ini",
which seemed to reliably remove the services every time.
Now that we've stopped using it, any running services (i.e. ones that aren't
using batch files or cmd.exe) still stop correctly, and the services are
"disabled" and do disappear if I restart the computer, but this isn't
sufficient, since when doing a silent upgrade, there is no opportunity to
restart (and "reboots are evil" anyway).
The verbose uninstall log file of when the services are not removed by the
uninstaller doesn't show much:
MSI (s) (5C:BC) [09:41:50:273]: Doing action: StopServices Action ended
09:41:50: UnpublishFeatures. Return value 1.
Action start 09:41:50: StopServices.
MSI (s) (5C:BC) [09:41:50:273]: Doing action: DeleteServices Action ended
09:41:50: StopServices. Return value 1.
Action start 09:41:50: DeleteServices.
MSI (s) (5C:BC) [09:41:50:273]: Doing action: RemoveRegistryValues Action ended
09:41:50: DeleteServices. Return value 1.
Action start 09:41:50: RemoveRegistryValues.
Looking in the .msi with Orca, there doesn't seem to be a column in the
ServiceControl table for the WiX attributes of "Start", "Stop", and
"Remove":
ServiceControl NameEvent ArgumentWaitComponent_
svcMyClient MyClient163 1 compMyClient
svcMySensor1MySensor1 163 1
compMySensor1JslExe
svcMySensor2MySensor2 163 1
compMySensor2JslExe
svcMySensor3MySensor3 163 1
compMySensor3JslExe
I didn't see anywhere else in the tables in Orca that tells the uninstaller to
remove the services, but maybe it's not stored/shown there.
Anyw
Re: [WiX-users] Uninstall restart issue
I've mentioned this before, but I don't recall if it was in connection with this thread... If any process has a handle open to a service, then Windows can't delete it so it gets marked disabled. In code this tends to be code that doesn't close handles , whether explicitly in C++ or in managed code ServiceControllers by failure to Dispose(). Personally I wouldn't use anything asynchronous or of indeterminate length such as net stop in a cmd shell. If you're seeing something timing-related, that may be where the issue is. Even in C++ the code to stop a service is not complicated and is much more manageable than a command shell. Phil -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: Friday, June 28, 2013 7:07 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue Yes, the cmd.exe is from a .bat file the service executes. Making it read-only did give the uninstaller pause as it took longer before finally deciding to still request a restart. One of my team members pointed something out that I should have realised: Since this problem is mainly causing problems when our software was auto-updating itself, we can run "net stop MyServiceX" from our own client before it runs the downloaded installer. Although this doesn't "solve" the problem, I think it sufficiently circumvents the problem for our purposes (especially given the ridiculous amount of time and effort we've sunken into it, including everyone here who has so graciously helped!). However, we now have a new problem where, during uninstall, the services are sometimes only disabled but not removed (although other times they are removed without problem, and I haven't figured out why it's intermittent). This new problem seems to have begun since we started using the ServiceInstall, and relying on the ServiceControl element to remove our service: Before this, we used a CA to run "jsl.exe -remove MySensor1JSLConfig.ini", which seemed to reliably remove the services every time. Now that we've stopped using it, any running services (i.e. ones that aren't using batch files or cmd.exe) still stop correctly, and the services are "disabled" and do disappear if I restart the computer, but this isn't sufficient, since when doing a silent upgrade, there is no opportunity to restart (and "reboots are evil" anyway). The verbose uninstall log file of when the services are not removed by the uninstaller doesn't show much: MSI (s) (5C:BC) [09:41:50:273]: Doing action: StopServices Action ended 09:41:50: UnpublishFeatures. Return value 1. Action start 09:41:50: StopServices. MSI (s) (5C:BC) [09:41:50:273]: Doing action: DeleteServices Action ended 09:41:50: StopServices. Return value 1. Action start 09:41:50: DeleteServices. MSI (s) (5C:BC) [09:41:50:273]: Doing action: RemoveRegistryValues Action ended 09:41:50: DeleteServices. Return value 1. Action start 09:41:50: RemoveRegistryValues. Looking in the .msi with Orca, there doesn't seem to be a column in the ServiceControl table for the WiX attributes of "Start", "Stop", and "Remove": ServiceControl NameEvent ArgumentWaitComponent_ svcMyClient MyClient163 1 compMyClient svcMySensor1MySensor1 163 1 compMySensor1JslExe svcMySensor2MySensor2 163 1 compMySensor2JslExe svcMySensor3MySensor3 163 1 compMySensor3JslExe I didn't see anywhere else in the tables in Orca that tells the uninstaller to remove the services, but maybe it's not stored/shown there. Anyway, any idea why the services aren't being completely removed immediately at uninstall, even though I have specified that they should be removed at uninstall in the ServiceControl tags? Alain -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: June 27, 2013 19:06 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue Very plausible. My understanding is that basically Restart Manager sorts processes into three groups: services (which it can see either have explicit stop commands in the MSI or not), applications in the same desktop that have a visible window with a title (to which it can send messages to shut it down), and everything else. It never looks at the parentage of a process because there is never any guarantee that a process will kill its children when it is stopped. Its plausible that if the cmd.exe process using your files were to register with Restart Manager for what MSFT has called "freeze dry" it wouldn't be treated the way it is. One other possible workaround for your scenario: if the files that are in use are mark
Re: [WiX-users] Uninstall restart issue
Yes, the cmd.exe is from a .bat file the service executes. Making it read-only did give the uninstaller pause as it took longer before finally deciding to still request a restart. One of my team members pointed something out that I should have realised: Since this problem is mainly causing problems when our software was auto-updating itself, we can run "net stop MyServiceX" from our own client before it runs the downloaded installer. Although this doesn't "solve" the problem, I think it sufficiently circumvents the problem for our purposes (especially given the ridiculous amount of time and effort we've sunken into it, including everyone here who has so graciously helped!). However, we now have a new problem where, during uninstall, the services are sometimes only disabled but not removed (although other times they are removed without problem, and I haven't figured out why it's intermittent). This new problem seems to have begun since we started using the ServiceInstall, and relying on the ServiceControl element to remove our service: Before this, we used a CA to run "jsl.exe -remove MySensor1JSLConfig.ini", which seemed to reliably remove the services every time. Now that we've stopped using it, any running services (i.e. ones that aren't using batch files or cmd.exe) still stop correctly, and the services are "disabled" and do disappear if I restart the computer, but this isn't sufficient, since when doing a silent upgrade, there is no opportunity to restart (and "reboots are evil" anyway). The verbose uninstall log file of when the services are not removed by the uninstaller doesn't show much: MSI (s) (5C:BC) [09:41:50:273]: Doing action: StopServices Action ended 09:41:50: UnpublishFeatures. Return value 1. Action start 09:41:50: StopServices. MSI (s) (5C:BC) [09:41:50:273]: Doing action: DeleteServices Action ended 09:41:50: StopServices. Return value 1. Action start 09:41:50: DeleteServices. MSI (s) (5C:BC) [09:41:50:273]: Doing action: RemoveRegistryValues Action ended 09:41:50: DeleteServices. Return value 1. Action start 09:41:50: RemoveRegistryValues. Looking in the .msi with Orca, there doesn't seem to be a column in the ServiceControl table for the WiX attributes of "Start", "Stop", and "Remove": ServiceControl NameEvent ArgumentWaitComponent_ svcMyClient MyClient163 1 compMyClient svcMySensor1MySensor1 163 1 compMySensor1JslExe svcMySensor2MySensor2 163 1 compMySensor2JslExe svcMySensor3MySensor3 163 1 compMySensor3JslExe I didn't see anywhere else in the tables in Orca that tells the uninstaller to remove the services, but maybe it's not stored/shown there. Anyway, any idea why the services aren't being completely removed immediately at uninstall, even though I have specified that they should be removed at uninstall in the ServiceControl tags? Alain -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: June 27, 2013 19:06 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue Very plausible. My understanding is that basically Restart Manager sorts processes into three groups: services (which it can see either have explicit stop commands in the MSI or not), applications in the same desktop that have a visible window with a title (to which it can send messages to shut it down), and everything else. It never looks at the parentage of a process because there is never any guarantee that a process will kill its children when it is stopped. Its plausible that if the cmd.exe process using your files were to register with Restart Manager for what MSFT has called "freeze dry" it wouldn't be treated the way it is. One other possible workaround for your scenario: if the files that are in use are marked in the filesystem as "read only" they MAY be ignored by Restart Manager. Is cmd.exe used because your service calls a batch script file? Try making that batch script file read-only and see if cmd.exe at least is removed from the list of "critical applications". Regarding the question on CAs: All CAs should never expose their own UI, instead using the message processing APIs that MSI provides. Deferred actions may not run on the same desktop as the user and thus will never even be seen (and can't be acted up) by the user, which is why it is critical that they be "silent". The only actions that cannot use MSIs messaging apis are actions called directly by MSI's UI (dialogs), but even they run in a sandbox that makes it very difficult to properly interact with the MSI UI. There is no reason that
Re: [WiX-users] Uninstall restart issue
Very plausible. My understanding is that basically Restart Manager sorts processes into three groups: services (which it can see either have explicit stop commands in the MSI or not), applications in the same desktop that have a visible window with a title (to which it can send messages to shut it down), and everything else. It never looks at the parentage of a process because there is never any guarantee that a process will kill its children when it is stopped. Its plausible that if the cmd.exe process using your files were to register with Restart Manager for what MSFT has called "freeze dry" it wouldn't be treated the way it is. One other possible workaround for your scenario: if the files that are in use are marked in the filesystem as "read only" they MAY be ignored by Restart Manager. Is cmd.exe used because your service calls a batch script file? Try making that batch script file read-only and see if cmd.exe at least is removed from the list of "critical applications". Regarding the question on CAs: All CAs should never expose their own UI, instead using the message processing APIs that MSI provides. Deferred actions may not run on the same desktop as the user and thus will never even be seen (and can't be acted up) by the user, which is why it is critical that they be "silent". The only actions that cannot use MSIs messaging apis are actions called directly by MSI's UI (dialogs), but even they run in a sandbox that makes it very difficult to properly interact with the MSI UI. There is no reason that an action has to be deferred to be "silent" (most immediate actions never show any UI) but non-deferred actions are never assumed to alter machine state (which is why they cannot ever be rolled back, are never given elevated privileges, and can potentially cause several unexpected side effects if they ever do alter machine state, which is why they are discouraged for any installer that intends to be reliable). Blair Murri > From: afor...@cmu.edu > To: wix-users@lists.sourceforge.net > Date: Thu, 27 Jun 2013 16:12:04 -0400 > Subject: Re: [WiX-users] Uninstall restart issue > > I have just confirmed that, when my service is running the cmd.exe process, > the RestartManager requests the restart, while otherwise, it does not. > > My service would immediately kill the cmd.exe process the moment the service > is asked to stop, but for whatever reason, I'm guessing the RestartManager > seems to think that the cmd.exe process is a "critical application" and it > doesn't realise that it's entirely under the control of my service, which > will stop it when requested. > > Does this sound plausible, given what you know about the RestartManager? Do > you know why it would just assume that cmd.exe won't be stopped by the > uninstaller (maybe because it wasn't installed by our installer)? > > Alain > > -Original Message- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: June 27, 2013 14:12 > To: 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > Sorry for the delay. I'm not sure I want non-elevated privileges to be able > to stop my service, but I suppose that might be a last-ditch solution. Also, > I thought for that CAs had to be marked as deferred (rather than immediate) > for them to be quietly/silently executed in the background...is that not so? > See this for more information: > > Below is what the Event Viewer\Windows Logs\Application -> Source: Restart > Manager says. What I find most interesting is the fourth entry, where the > description is "Machine restart is required.", and it points out the > following applications: > > xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events"; > xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> > 0 > 5 > > cmd.exe > My Client > My Sensor 1 > My Sensor 2 > My Sensor 3 > > 3 > > > I don't know what a "RebootReasons" of 3 is, but it's clearly identified my > programs (but not the fact that they're actually services), as well as > cmd.exe, which is something one of my sensors has executed. I will do further > tests to see if it's actually what the cmd.exe is doing that's triggering the > request to reboot, but let me know if you have any other thoughts. > > Event Viewer Log follows: > > Log Name: Application > Source:Microsoft-Windows-RestartManager > Date: 2013-06-27 13:50:05 > Event ID: 1 > Task Category: N
Re: [WiX-users] Uninstall restart issue
I have just confirmed that, when my service is running the cmd.exe process, the RestartManager requests the restart, while otherwise, it does not. My service would immediately kill the cmd.exe process the moment the service is asked to stop, but for whatever reason, I'm guessing the RestartManager seems to think that the cmd.exe process is a "critical application" and it doesn't realise that it's entirely under the control of my service, which will stop it when requested. Does this sound plausible, given what you know about the RestartManager? Do you know why it would just assume that cmd.exe won't be stopped by the uninstaller (maybe because it wasn't installed by our installer)? Alain -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: June 27, 2013 14:12 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Uninstall restart issue Sorry for the delay. I'm not sure I want non-elevated privileges to be able to stop my service, but I suppose that might be a last-ditch solution. Also, I thought for that CAs had to be marked as deferred (rather than immediate) for them to be quietly/silently executed in the background...is that not so? See this for more information: Below is what the Event Viewer\Windows Logs\Application -> Source: Restart Manager says. What I find most interesting is the fourth entry, where the description is "Machine restart is required.", and it points out the following applications: http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 5 cmd.exe My Client My Sensor 1 My Sensor 2 My Sensor 3 3 I don't know what a "RebootReasons" of 3 is, but it's clearly identified my programs (but not the fact that they're actually services), as well as cmd.exe, which is something one of my sensors has executed. I will do further tests to see if it's actually what the cmd.exe is doing that's triggering the request to reboot, but let me know if you have any other thoughts. Event Viewer Log follows: Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:05 Event ID: 1 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Starting session 0 - ?2013?-?06?-?27T17:50:05.048184800Z. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 1 0 4 0 0 0x8000 9756 Application aforget http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 2013-06-27T17:50:05.048184800Z Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:15 Event ID: 10001 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Ending session 0 started ?2013?-?06?-?27T17:50:05.048184800Z. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 10001 0 4 0 0 0x8000 9758 Application aforget http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 2013-06-27T17:50:05.048184800Z Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:24 Event ID: 1 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Starting session 0 - ?2013?-?06?-?27T17:50:24.860219600Z. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 1 0 4 0 0 0x8000 9762 Application aforget http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 2013-06-27T17:50:24.860219600Z Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:25 Event ID: 10005 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Machine restart is required. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 10005 0 4 0 0 0x8000 9763 Application aforget http://schemas.microsoft.com/win/200
Re: [WiX-users] Uninstall restart issue
Sorry for the delay. I'm not sure I want non-elevated privileges to be able to stop my service, but I suppose that might be a last-ditch solution. Also, I thought for that CAs had to be marked as deferred (rather than immediate) for them to be quietly/silently executed in the background...is that not so? See this for more information: Below is what the Event Viewer\Windows Logs\Application -> Source: Restart Manager says. What I find most interesting is the fourth entry, where the description is "Machine restart is required.", and it points out the following applications: http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 5 cmd.exe My Client My Sensor 1 My Sensor 2 My Sensor 3 3 I don't know what a "RebootReasons" of 3 is, but it's clearly identified my programs (but not the fact that they're actually services), as well as cmd.exe, which is something one of my sensors has executed. I will do further tests to see if it's actually what the cmd.exe is doing that's triggering the request to reboot, but let me know if you have any other thoughts. Event Viewer Log follows: Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:05 Event ID: 1 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Starting session 0 - ?2013?-?06?-?27T17:50:05.048184800Z. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 1 0 4 0 0 0x8000 9756 Application aforget http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 2013-06-27T17:50:05.048184800Z Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:15 Event ID: 10001 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Ending session 0 started ?2013?-?06?-?27T17:50:05.048184800Z. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 10001 0 4 0 0 0x8000 9758 Application aforget http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 2013-06-27T17:50:05.048184800Z Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:24 Event ID: 1 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Starting session 0 - ?2013?-?06?-?27T17:50:24.860219600Z. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 1 0 4 0 0 0x8000 9762 Application aforget http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 2013-06-27T17:50:24.860219600Z Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:25 Event ID: 10005 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Machine restart is required. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 10005 0 4 0 0 0x8000 9763 Application aforget http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 5 cmd.exe My Client My Sensor 1 My Sensor 2 My Sensor 3 3 Log Name: Application Source:Microsoft-Windows-RestartManager Date: 2013-06-27 13:50:34 Event ID: 10001 Task Category: None Level: Information Keywords: User: aforget Computer: aforget Description: Ending session 0 started ?2013?-?06?-?27T17:50:24.860219600Z. Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 10001 0 4 0 0 0x8000 9767 Application aforget http://schemas.microsoft.com/win/2004/08/events"; xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";> 0 2013-06-27T17:50:24.860
Re: [WiX-users] Uninstall restart issue
It also requires that the service is setup to allow non-elevated privileges to stop it. Event Viewer\Windows Logs\Application Source: RestartManager -Original Message- From: Joel Budreau Sent: Tuesday, June 25, 2013 6:22 PM To: afor...@cmu.edu ; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Uninstall restart issue Hey Alain, Take a look at my answer to this problem on stackoverflow - http://stackoverflow.com/questions/6913332/wix-installer-problem-why-does-restartmanager-mark-service-as-rmcritical-and-no/8147540#8147540 Basically, you can 'lie' about the custom action and mark it as immediate instead of deferred. The drawback is that if your install fails and rollsback, the service you've shut down will still be shut down. Up to you whether or not that's an appropriate risk for your product. - Joel On Sat, Jun 15, 2013 at 11:11 AM, Alain Forget wrote: > I'm still wrestling with this request to restart on uninstall. To recap, I > have an MSI that when I install it, and then try to uninstall it, it > usually tells the user that some of the files to be uninstalled are in use > and will require a reboot. However, this should not be, because the > services that are using the files will stop immediately upon request. > > The problem seems to be that the installer is making the determination > that the files are in use before even trying to stop services. Looking at > the uninstall log, during FileCost, the installer determines that multiple > "folder had been blocked by the 1 mask argument (the folder pair's > iSwapAttrib member = 0)", which I think means it's in use? Furthermore, at > InstallValidate, "RESTART MANAGER: Did detect that a critical application > holds file[s] in use, so a reboot will be necessary." Note that both > InstallValidate and FileCost come before StopServices (see > http://msdn.microsoft.com/en-us/library/aa372038). > > It had been suggested that I should stop the services myself with "net > stop". So I attempted to do so with this in my .wxs: > > > Property="cmdStopClientCommModuleService" Value="net stop [#myService]" /> > DllEntry="CAQuietExec" Return="check" Impersonate="no" /> > > > > > > > > > However, candle / light don't allow it: > > error LGHT0204 : ICE77: cmdStopMyService is a in-script custom action. It > must be sequenced in between the InstallInitialize action and the > InstallFinalize action in the InstallExecuteSequence table > > Following Light's recommendation wouldn't solve my problem, because > InstallInitialze happens long after the uninstaller has decided that the > files are in use. > > So I'm completely stumped and would appreciate some suggestions. > > Alain > > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall restart issue
Hey Alain, Take a look at my answer to this problem on stackoverflow - http://stackoverflow.com/questions/6913332/wix-installer-problem-why-does-restartmanager-mark-service-as-rmcritical-and-no/8147540#8147540 Basically, you can 'lie' about the custom action and mark it as immediate instead of deferred. The drawback is that if your install fails and rollsback, the service you've shut down will still be shut down. Up to you whether or not that's an appropriate risk for your product. - Joel On Sat, Jun 15, 2013 at 11:11 AM, Alain Forget wrote: > I'm still wrestling with this request to restart on uninstall. To recap, I > have an MSI that when I install it, and then try to uninstall it, it usually > tells the user that some of the files to be uninstalled are in use and will > require a reboot. However, this should not be, because the services that are > using the files will stop immediately upon request. > > The problem seems to be that the installer is making the determination that > the files are in use before even trying to stop services. Looking at the > uninstall log, during FileCost, the installer determines that multiple > "folder had been blocked by the 1 mask argument (the folder pair's > iSwapAttrib member = 0)", which I think means it's in use? Furthermore, at > InstallValidate, "RESTART MANAGER: Did detect that a critical application > holds file[s] in use, so a reboot will be necessary." Note that both > InstallValidate and FileCost come before StopServices (see > http://msdn.microsoft.com/en-us/library/aa372038). > > It had been suggested that I should stop the services myself with "net stop". > So I attempted to do so with this in my .wxs: > > > Property="cmdStopClientCommModuleService" Value="net stop [#myService]" /> > DllEntry="CAQuietExec" Return="check" Impersonate="no" /> > > > > > > > > However, candle / light don't allow it: > > error LGHT0204 : ICE77: cmdStopMyService is a in-script custom action. It > must be sequenced in between the InstallInitialize action and the > InstallFinalize action in the InstallExecuteSequence table > > Following Light's recommendation wouldn't solve my problem, because > InstallInitialze happens long after the uninstaller has decided that the > files are in use. > > So I'm completely stumped and would appreciate some suggestions. > > Alain > > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall restart issue
My apologies for the multiple posts, but I've found some more information that might tell some of you something, even if I don't know what it implies. One thing I might not have previously mentioned is that the restart request does NOT appear if I wait for a few minutes after install before trying to uninstall the software. Comparing the logs between the two uninstalls of when the restart request does and does not appear, the only difference (aside from timestamps) is this: With restart request: MSI (s) (A4:18) [11:17:44:613]: Note: 1: 2727 2: MSI (s) (A4:18) [11:17:44:660]: RESTART MANAGER: Did detect that a critical application holds file[s] in use, so a reboot will be necessary. MSI (s) (A4:18) [11:17:44:660]: Note: 1: 1610 MSI (s) (A4:18) [11:17:55:299]: RESTART MANAGER: The user chose to go on with the installation, although a reboot will be required. MSI (c) (3C:88) [11:17:44:676]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup. MSI (s) (A4:18) [11:17:55:299]: Note: 1: 2727 2: MSI (s) (A4:18) [11:17:55:299]: Doing action: InstallInitialize Action ended 11:17:55: InstallValidate. Return value 1. With no restart request: MSI (s) (E4:B0) [15:32:00:536]: Note: 1: 2727 2: MSI (s) (E4:B0) [15:32:00:583]: RESTART MANAGER: Detected that the service MyClientCommModule will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager MSI (s) (E4:B0) [15:32:00:583]: RESTART MANAGER: Detected that the service MySensor1 will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager MSI (s) (E4:B0) [15:32:00:583]: RESTART MANAGER: Detected that the service MySensor2 will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager MSI (s) (E4:B0) [15:32:00:583]: RESTART MANAGER: Detected that the service MySensor3 will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager MSI (s) (E4:B0) [15:32:00:583]: Note: 1: 2727 2: MSI (s) (E4:B0) [15:32:00:583]: Doing action: InstallInitialize Action ended 15:32:00: InstallValidate. Return value 1. So there are two things I've noted: 1) The only thing different I can tell between the two uninstall procedures is the difference in time between the install and uninstall. For example, if I wait 5 seconds, then I see the restart request, but if I wait a minute or two after installing before uninstalling, then there is no restart reqest. Some of the sensors do periodically run cmd.exe or third-party exes that I install, but the services are designed to drop everything and stop if they are asked to. Furthermore, in Process Explorer, I can see that they are child processes of the service's process, so...I wouldn't think this would be a problem for the Windows Installer? 2) My previous hypothesis that the uninstaller was choking on "WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\SomeFile.class' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0)" was flat out wrong, since the exact same log lines show up in both uninstallers' logs. So why would it sometimes think that some "critical application holds file[s]", and other times, it can tell exactly which processes/services hold the services? Does any of this point to some source for the problem (and hopefully a solution)? Alain -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: June 21, 2013 12:14 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Uninstall restart issue I've found a number of Restart Manager posts similar to this: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-the-Restart-Manager-td3162984.html Since our services' JSL exes basically use Java, maybe it's Java that's locking our files, and the uninstaller doesn't/can't dig deeper into what's controlling what to realise the files are locked by java, which is run by our services' exes? Even if that's the case, I have yet to see a reply on how to solve the problem. Alain -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: June 21, 2013 11:42 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Uninstall restart issue Blair (and anyone else interested), You were bang on abou
Re: [WiX-users] Uninstall does not uninstall my driver package
I've had to deal with this in the past. DIFX just unloads the driver from the device. DIF_REMOVE is only called when removing the entire device as happens in device manager when using the Remove option. I got around this with a CA that sent the DIF_REMOVE directly to the device class using the SetupDI* API's. If the OS does not contain a driver for the device in-box then it usually gets moved the "Unknown devices" in device manager so appears to be a complete install. It's usually fine unless you've got code that must run during uninstall. JohnG -Original Message- From: shane_cor...@selinc.com [mailto:shane_cor...@selinc.com] Sent: Thursday, June 20, 2013 5:35 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Uninstall does not uninstall my driver package I'm using difx to install a handful of drivers in a single msi. The installation works great. However, when I uninstall the msi it appears to only remove my driver package and not issue a proper uninstall. I can tell because my class installer that complements my driver is not getting called with a DIF_REMOVE install function the same way it does when I right-click on the device in device manager and uninstall. What do I need to do in order to get my driver packages to actually uninstall rather than simply remove? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall restart issue
I've found a number of Restart Manager posts similar to this: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-the-Restart-Manager-td3162984.html Since our services' JSL exes basically use Java, maybe it's Java that's locking our files, and the uninstaller doesn't/can't dig deeper into what's controlling what to realise the files are locked by java, which is run by our services' exes? Even if that's the case, I have yet to see a reply on how to solve the problem. Alain -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: June 21, 2013 11:42 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Uninstall restart issue Blair (and anyone else interested), You were bang on about both manually trying to launch the service to test it and using " around the formatted string. Sometimes when I've been working at something for too long, I don't think of things like that and can't see the forest for the trees. :-s Unfortunately, the uninstaller is *still* requesting a restart just as before. However, without actually manually restarting the computer, our software does completely uninstall anyway, so the uninstaller's concerns are for naught. The verbose logs still look very similar to before, with many entries just before CostFinalize like this which is what I think is what leads to the request to restart: MSI (s) (A4:18) [11:17:44:582]: WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\MyClient\OneOfManyFiles.ini' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0). Maybe those lines have nothing to do with the request to restart, but a file or folder being "blocked" seems to be the only thing I can see that could be related to the problem. I do think it is better that the Windows Installer creates/registers the services from independent exes now (instead of doing it with CAs like before), but somehow, it's still not understanding that these files are locked by the services that are going to be stopped. Arg, why not? Hopefully you have some other insights on what might be going on? Alain -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: June 21, 2013 04:31 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue Alain, Temporarily remove the ServiceControl\@Start and install. Then use the service control manager and start. See what errors are reported, diagnose, and tweak the installation. Once your service starts when installed, replace the @Start attribute. I didn't see anything special done when jsl.exe was passed an "install" switch, but I didn't walk the code in a debugger either. If you have spaces in your installation directory path (such as the space between Program and Files) you may need to update your ServiceInstall\@Arguments to be Arguments="-ini "[#fileClientCommModuleJslConfig]"" Blair Murri > From: afor...@cmu.edu > To: jacob.hoo...@greenheck.com; wix-users@lists.sourceforge.net > Date: Thu, 20 Jun 2013 17:09:30 -0400 > Subject: Re: [WiX-users] Uninstall restart issue > > Anyone out there have any ideas about our problem below? > > I'm thinking anyone with experience using WiX or the Windows Installer with > JSL or a Java-based service are best positioned to know how to solve this. > > Alain > > -----Original Message- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: June 19, 2013 19:12 > To: 'Hoover, Jacob'; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > I've implemented Blair's 2nd suggestion, and the services do seem to get > installed, but I don't think they're being installed correctly, because the > services then cannot start and the installer fails. > > I think the -install argument of jsl.exe does some other special things to > wrap the Java program and install it as a service than the ServiceInstall > does, which is why it worked when I was installing the service using jsl.exe > directly, instead of trying to do it with ServiceInstall. > > Any ideas are welcome, and I can provide any logs you think would help. > Here's a snippet of what my service-related WiX looks like now: > > >Name='jsl_ClientCommModuleServiceConfig.ini' DiskId='1' > Source='jsl_ClientCommModuleServiceConfig.ini' KeyPath='yes' /> > >Name='MyClientCommModuleService.exe' DiskId='1' Source='jsl.exe' > KeyPath='yes' /> > Id="servInstClientCom
Re: [WiX-users] Uninstall restart issue
Blair (and anyone else interested), You were bang on about both manually trying to launch the service to test it and using " around the formatted string. Sometimes when I've been working at something for too long, I don't think of things like that and can't see the forest for the trees. :-s Unfortunately, the uninstaller is *still* requesting a restart just as before. However, without actually manually restarting the computer, our software does completely uninstall anyway, so the uninstaller's concerns are for naught. The verbose logs still look very similar to before, with many entries just before CostFinalize like this which is what I think is what leads to the request to restart: MSI (s) (A4:18) [11:17:44:582]: WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\MyClient\OneOfManyFiles.ini' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0). Maybe those lines have nothing to do with the request to restart, but a file or folder being "blocked" seems to be the only thing I can see that could be related to the problem. I do think it is better that the Windows Installer creates/registers the services from independent exes now (instead of doing it with CAs like before), but somehow, it's still not understanding that these files are locked by the services that are going to be stopped. Arg, why not? Hopefully you have some other insights on what might be going on? Alain -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: June 21, 2013 04:31 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue Alain, Temporarily remove the ServiceControl\@Start and install. Then use the service control manager and start. See what errors are reported, diagnose, and tweak the installation. Once your service starts when installed, replace the @Start attribute. I didn't see anything special done when jsl.exe was passed an "install" switch, but I didn't walk the code in a debugger either. If you have spaces in your installation directory path (such as the space between Program and Files) you may need to update your ServiceInstall\@Arguments to be Arguments="-ini "[#fileClientCommModuleJslConfig]"" Blair Murri > From: afor...@cmu.edu > To: jacob.hoo...@greenheck.com; wix-users@lists.sourceforge.net > Date: Thu, 20 Jun 2013 17:09:30 -0400 > Subject: Re: [WiX-users] Uninstall restart issue > > Anyone out there have any ideas about our problem below? > > I'm thinking anyone with experience using WiX or the Windows Installer with > JSL or a Java-based service are best positioned to know how to solve this. > > Alain > > -Original Message- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: June 19, 2013 19:12 > To: 'Hoover, Jacob'; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > I've implemented Blair's 2nd suggestion, and the services do seem to get > installed, but I don't think they're being installed correctly, because the > services then cannot start and the installer fails. > > I think the -install argument of jsl.exe does some other special things to > wrap the Java program and install it as a service than the ServiceInstall > does, which is why it worked when I was installing the service using jsl.exe > directly, instead of trying to do it with ServiceInstall. > > Any ideas are welcome, and I can provide any logs you think would help. > Here's a snippet of what my service-related WiX looks like now: > > >Name='jsl_ClientCommModuleServiceConfig.ini' DiskId='1' > Source='jsl_ClientCommModuleServiceConfig.ini' KeyPath='yes' /> > >Name='MyClientCommModuleService.exe' DiskId='1' Source='jsl.exe' > KeyPath='yes' /> > Id="servInstClientCommModule" > Name="MyClientCommModule" > Arguments="-ini [#fileClientCommModuleJslConfig]" > Description="My Client Communication Module" > DisplayName="My Client Communication Module" > ErrorControl="normal" > Start="auto" > Type="ownProcess" > Vital="yes" > > > > Id="servClientCommModule" > Name="MyClientCommModule" > Remove="uninstall" > Start="install" > Stop="both" >
