[WiX-users] Shortcut Element Run as administrator
I want to create a shortcut to point to my executable. The shortcut will be used in cases where the .exe needs to run with elevate privileges. I don't see any attribute(s) in the schema that can allow me to create the shortcut with this flag. So, is it up to me to deliver the .LNK file myself? Need to take care of delivering the appropriate shortcut depending on OS architecture (i.e. Program Files versus Program Files (x86)) since my product is WOW64. Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcut Element Run as administrator
For this application, no I cannot. I know that is preferred (by me too) but some of the necessary use cases for this application kills that approach. On Tue, Sep 25, 2012 at 1:35 PM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Could you include a manifest with the application to require elevation/run as admin privileges ? -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 25 September 2012 18:23 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Shortcut Element Run as administrator I want to create a shortcut to point to my executable. The shortcut will be used in cases where the .exe needs to run with elevate privileges. I don't see any attribute(s) in the schema that can allow me to create the shortcut with this flag. So, is it up to me to deliver the .LNK file myself? Need to take care of delivering the appropriate shortcut depending on OS architecture (i.e. Program Files versus Program Files (x86)) since my product is WOW64. Thanks. - - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcut Element Run as administrator
I am packaging a short cut for each architecture and using an install time condition to install the appropriate file. Sent from mobile. On Sep 25, 2012 2:32 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: A dirty trick would be to have a simple AsAdmin.exe with a manifest that blindly executes the source app (same folder). -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Tuesday, September 25, 2012 12:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Shortcut Element Run as administrator For this application, no I cannot. I know that is preferred (by me too) but some of the necessary use cases for this application kills that approach. On Tue, Sep 25, 2012 at 1:35 PM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: Could you include a manifest with the application to require elevation/run as admin privileges ? -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 25 September 2012 18:23 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Shortcut Element Run as administrator I want to create a shortcut to point to my executable. The shortcut will be used in cases where the .exe needs to run with elevate privileges. I don't see any attribute(s) in the schema that can allow me to create the shortcut with this flag. So, is it up to me to deliver the .LNK file myself? Need to take care of delivering the appropriate shortcut depending on OS architecture (i.e. Program Files versus Program Files (x86)) since my product is WOW64. Thanks. -- --- - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Replacing Cached MSI DB
Due to an issue with the IISExtension and how it handles certs in WiX 3.0 we are unable to uninstall/upgrade our product (see other recent issues I have been asking about). I have attempted to create a substitute MSI DB to replace the cached DB file per Rob's recommendations here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-to-force-an-uninstall-and-ignore-errors-td6029032.html The substitute DB is built with WiX 3.5, the original was built with WiX 3.0. The thought here was that since the cert uninstall issue seems to be resolved in 3.5, this would allow the product to be uninstalled. The cache is updated, and the product can then be uninstalled. However, when running the uninstall although it cleans itself out of ARP, all of the components appear to be left on the system. The new DB file has the same product GUID, Upgrade GUID, version, and product/MSI name, however the package GUID is different (which I don't think matters). For component GUID generation, I am using * (where applicable), not sure if this matters in this case, just wanted to mention it. When I then attempt to install a major upgrade release of a later version of the product, the install fails (1603). The only thing that I see in the (non-verbose) log is RemoveFiles. Return value 0, otherwise it looks okay. I am going to rerun the test with verbose logging. So, two questions, is the way I regenerated the updated cache DB accurate, and if so, why does it not uninstall the components? Second, even with the components left on the system, should the new major version release install not just overwrite everything and install successfully? Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Replacing Cached MSI DB
Well, like I said I am using * for the components that allow for it for better automation. My impression (I did a lot of research before using * to make sure I would not have any issues in the future, asked on the mailing list, etc.) was that * should work in all cases as long as the component paths (however WiX determines this) did not change. So, in this case the MSI is identical other than it being built with 3.0 versus 3.5. Is this a corner case that no one considered? My issue with the install after the removal is due to the components being left on the system. I can see this from the verbose log. Thanks. On Thu, Aug 30, 2012 at 9:23 AM, Pally Sandher pally.sand...@iesve.comwrote: Sounds like your Component GUIDs are different thus you've broken the Component Rules - http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101 Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 30 August 2012 12:57 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Replacing Cached MSI DB Due to an issue with the IISExtension and how it handles certs in WiX 3.0 we are unable to uninstall/upgrade our product (see other recent issues I have been asking about). I have attempted to create a substitute MSI DB to replace the cached DB file per Rob's recommendations here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-to-force-an-uninstall-and-ignore-errors-td6029032.html The substitute DB is built with WiX 3.5, the original was built with WiX 3.0. The thought here was that since the cert uninstall issue seems to be resolved in 3.5, this would allow the product to be uninstalled. The cache is updated, and the product can then be uninstalled. However, when running the uninstall although it cleans itself out of ARP, all of the components appear to be left on the system. The new DB file has the same product GUID, Upgrade GUID, version, and product/MSI name, however the package GUID is different (which I don't think matters). For component GUID generation, I am using * (where applicable), not sure if this matters in this case, just wanted to mention it. When I then attempt to install a major upgrade release of a later version of the product, the install fails (1603). The only thing that I see in the (non-verbose) log is RemoveFiles. Return value 0, otherwise it looks okay. I am going to rerun the test with verbose logging. So, two questions, is the way I regenerated the updated cache DB accurate, and if so, why does it not uninstall the components? Second, even with the components left on the system, should the new major version release install not just overwrite everything and install successfully? Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Replacing Cached MSI DB
Comparing the component GUIDs in the original (broken 3.0 MSI) against the same version MSI built with 3.5 shows that the hard-coded GUIDs are the same, no surprise there. Now, the heat generated component GUIDs are different, these use the *. I am not sure why this would be? I am building the MSI at my desk versus our build server so the build paths might be different, however the component paths (where the files go on the system) are identical. Either way, these are just file components and although messy, should not be causing me any problems when I attempt to install my new version of the product after the uninstall. However, when performing the uninstall against the updated cache DB, even the components with the *same* GUID are not being removed either. I don't understand why this would be, unless the package GUID somehow plays a role here? I don't see the package GUID defined in any of the tables. Where do I find this so that I can make the package GUID in my replacement MSI the same? This is all assuming the package GUID has anything to do with the issue I am seeing. Thanks. On Thu, Aug 30, 2012 at 10:09 AM, Andy Clugston clug...@gmail.com wrote: Well, like I said I am using * for the components that allow for it for better automation. My impression (I did a lot of research before using * to make sure I would not have any issues in the future, asked on the mailing list, etc.) was that * should work in all cases as long as the component paths (however WiX determines this) did not change. So, in this case the MSI is identical other than it being built with 3.0 versus 3.5. Is this a corner case that no one considered? My issue with the install after the removal is due to the components being left on the system. I can see this from the verbose log. Thanks. On Thu, Aug 30, 2012 at 9:23 AM, Pally Sandher pally.sand...@iesve.comwrote: Sounds like your Component GUIDs are different thus you've broken the Component Rules - http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101 Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 30 August 2012 12:57 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Replacing Cached MSI DB Due to an issue with the IISExtension and how it handles certs in WiX 3.0 we are unable to uninstall/upgrade our product (see other recent issues I have been asking about). I have attempted to create a substitute MSI DB to replace the cached DB file per Rob's recommendations here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-to-force-an-uninstall-and-ignore-errors-td6029032.html The substitute DB is built with WiX 3.5, the original was built with WiX 3.0. The thought here was that since the cert uninstall issue seems to be resolved in 3.5, this would allow the product to be uninstalled. The cache is updated, and the product can then be uninstalled. However, when running the uninstall although it cleans itself out of ARP, all of the components appear to be left on the system. The new DB file has the same product GUID, Upgrade GUID, version, and product/MSI name, however the package GUID is different (which I don't think matters). For component GUID generation, I am using * (where applicable), not sure if this matters in this case, just wanted to mention it. When I then attempt to install a major upgrade release of a later version of the product, the install fails (1603). The only thing that I see in the (non-verbose) log is RemoveFiles. Return value 0, otherwise it looks okay. I am going to rerun the test with verbose logging. So, two questions, is the way I regenerated the updated cache DB accurate, and if so, why does it not uninstall the components? Second, even with the components left on the system, should the new major version release install not just overwrite everything and install successfully? Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual
Re: [WiX-users] Replacing Cached MSI DB
Rob, I am not doing a minor upgrade, this product follows a major upgrade life cycle. Ultimately, I want to do a major upgrade, however from the original WiX 3.0 MSI the upgrade fails because of the bug with the IISExtension. The uninstall also fails. Hence, my attempt to replace the cached DB with an MSI built against WiX 3.5 (which seems to have fixed the IISExtension issue). I compared some test builds of 3.0 against 3.5 and the GUIDs are the same, however they are different than the GUIDs from the original 3.0 MSIs generated on our build server. Not sure why this is... historically, I have compared the 3.0 builds from our build server and all the GUIDs match. My next step was to try the hack of using the IISExtension from 3.5 with a 3.0 generated cache-replacement MSI. In general, what might the reason be that the replacement MSI is not uninstalling the components with properly maintained GUIDs? Is this some sublety between WiX 3.0 and 3.5 that might be causing issues? There are no other changes. Thanks. On Thu, Aug 30, 2012 at 11:23 AM, Rob Mensching r...@robmensching.comwrote: First try this: http://robmensching.com/blog/posts/2007/1/4/Doing-a-small-update-or-minor-upgrade-in-MSI-Use That will point out if your minor upgrade is breaking component rules. * GUIDs in Components are supposed to make stable GUIDs. However, it is posible (I forget, it was a long time ago) that there was a fix in the GUID generation across WiX v3.0 to WiX v3.5. In general, when you upgrade WiX toolset versions, you need to do major upgrade MSIs. There are too many subtle things that must stay the same that are not always possible to keep static when fixing bugs. I know that's not what you want to hear but at least we'll understand the problem. The next best thing may be to try to build your MSI using WiX v3.0 but with the WiX v3.5 IIS extension. That's not technically supported either but it *may* work out. On Thu, Aug 30, 2012 at 7:09 AM, Andy Clugston clug...@gmail.com wrote: Well, like I said I am using * for the components that allow for it for better automation. My impression (I did a lot of research before using * to make sure I would not have any issues in the future, asked on the mailing list, etc.) was that * should work in all cases as long as the component paths (however WiX determines this) did not change. So, in this case the MSI is identical other than it being built with 3.0 versus 3.5. Is this a corner case that no one considered? My issue with the install after the removal is due to the components being left on the system. I can see this from the verbose log. Thanks. On Thu, Aug 30, 2012 at 9:23 AM, Pally Sandher pally.sand...@iesve.com wrote: Sounds like your Component GUIDs are different thus you've broken the Component Rules - http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101 Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 30 August 2012 12:57 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Replacing Cached MSI DB Due to an issue with the IISExtension and how it handles certs in WiX 3.0 we are unable to uninstall/upgrade our product (see other recent issues I have been asking about). I have attempted to create a substitute MSI DB to replace the cached DB file per Rob's recommendations here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-to-force-an-uninstall-and-ignore-errors-td6029032.html The substitute DB is built with WiX 3.5, the original was built with WiX 3.0. The thought here was that since the cert uninstall issue seems to be resolved in 3.5, this would allow the product to be uninstalled. The cache is updated, and the product can then be uninstalled. However, when running the uninstall although it cleans itself out of ARP, all of the components appear to be left on the system. The new DB file has the same product GUID, Upgrade GUID, version, and product/MSI name, however the package GUID is different (which I don't think matters). For component GUID generation, I am using * (where applicable), not sure if this matters in this case, just wanted to mention it. When I then attempt to install a major upgrade release of a later version of the product, the install fails (1603). The only thing that I see in the (non-verbose) log is RemoveFiles. Return value 0, otherwise it looks okay. I am going to rerun the test
Re: [WiX-users] Problems with UninstallCertificates custom action
Dario, did you ever find a resolution to this issue? On Wed, Sep 22, 2010 at 8:52 PM, Bob Arnson b...@joyofsetup.com wrote: On 22-Sep-10 20:15, Dario Amiri wrote: So it looks like no one has any advice for this issue. Is there any way I can submit this as a bug? The WiX home page has links to the bug database: https://wix.codeplex.com/ -- sig://boB http://joyofsetup.com/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs
I'm not having a whole lot of luck with anything I am trying. No matter what the certificate uninstall action keeps running (and breaking). One thing that I don't understand is that I created an MSI built with 3.5 and then did a /fv to replace the cached MSI . This allows the uninstall to occur, but leaves all of the files/changes/etc. on the system. Then after this, I am still having issues installing a new package. Having more certificate issues during the install. Not sure if it is more issues with the IIS cert extension or what. I am losing comfort with this extension/feature. We are to the point of looking into drastic measures, like replacing the cached msi on the system, adjusting the registry, etc. to make Windows think the replaced msi is the original. I am not looking forward to this as I have a feeling it is going to be very messy. Any other suggestions are welcome. On Tue, Aug 28, 2012 at 10:24 PM, Andy Clugston clug...@gmail.com wrote: So I created a new version (major upgrade) of the product. I adjusted RemoveExistingProducts to run after InstallFinalize. This didn't seem to help at all. It still attempts to remove the cert, and I have the same errors. Thanks. On Tue, Aug 28, 2012 at 3:26 PM, Andy Clugston clug...@gmail.com wrote: I assume when you say take the original installer you mean bump one of the three version digits and generate a new product version installer, i.e. 1.1.0 to 1.1.1, generate new product GUID, etc. Where this all started was trying to get a newer version of the product on the system. If I can make the RemoveExistingProducts changes to it and that actually works, then we should not need to figure out how to uninstall it first. On Tue, Aug 28, 2012 at 12:42 PM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: Correct. Having thought about it a bit more, this might be a better idea: Take the original installer (or whatever is the current release). Make a major upgrade out of it in the normal way. Schedule RemoveExistingProducts in one of the latter two places mentioned in http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29 .aspx Build it with WiX 3.5 That'll create a major upgrade that shouldn't touch the certificate component. Being built with WiX 3.5, removal might then succeed. I'm not sure what the WiX team would say about mixing toolset versions like that but I'd guess there are risks, so you'd have to test thoroughly. You'd have to do the same thing with the second product too since you don't know which one will be removed last and will perform the actual certificate uninstallation. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 28 August 2012 17:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs Okay, so what you are saying is that I cannot skip individual components during uninstall, correct? I am not sure if these would work or not. We don't have minor installs, we use the third digit, but it is a full install. This product installs the certificate, and another product re-installs the identical certificate. For some reason WiX 3.0 does not like this. I would have to dig up the bug report, but I did run across it. During our tests with WiX 3.5 this issue seems to be resolved. Now, we could get into a conversation about cross product dependencies, etc. but I was not involved with any of those decisions so I am just trying to dig us out of the hole we are in. I am not sure the extra installer is going to help. It appears that anything touching the original certificate on the system causes the original WiX 3.0 MSI to fail. Yes, the install would ensure the cert is on the system, but the uninstall for the original WiX 3.0 MSI package would still fail. Thanks for the help. On Tue, Aug 28, 2012 at 11:46 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: As far as I can think, you can only selectively uninstall entire features without using permanent components. If the conditions are broken, would patching/minor updating them solve your problem ? I'm not sure what the WiX bug is that you're referring to. Otherwise, you could write an extra installer that only includes the component you want to keep, install that, then remove the original one. The extra reference would retain the component on the machine until you took both installers off. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 28 August 2012 16:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs We have a product that installs a few certificates on the system using the IIS extension using WiX 3.0. Evidently, there is an issue with the certificate action(s) in this version
[WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs
We have a product that installs a few certificates on the system using the IIS extension using WiX 3.0. Evidently, there is an issue with the certificate action(s) in this version of the toolset. We are unable to uninstall/upgrade from this specific version in the field. I would like to know if there is a way during the uninstall (i.e. msiexec /x .) to pass command line parameters/properties to skip the uninstall of specific components, in this case the certificate that is giving us problems. The original authoring has conditions to skip the certificates when installing the product. Passing these properties during the uninstall does not seem to skip them during the uninstall process (like I was hoping it would). Ultimately, we have tested with WiX 3.5 and the bug appears to be fixed. So, we would like to be able to get the old version of the product uninstalled, leaving the certificate it originally installed behind, and then with the new WiX 3.5-built package reinstall the certificate hoping to workaround this original WiX 3.0 issue. If there is no other way to selectively uninstall, is there a possible way of forcibly causing the uninstall to succeed (understanding that some artifacts might be left behind)? I have all of the details of the original installation package, so if anything can be done I would very much appreciate the help. Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs
Okay, so what you are saying is that I cannot skip individual components during uninstall, correct? I am not sure if these would work or not. We don't have minor installs, we use the third digit, but it is a full install. This product installs the certificate, and another product re-installs the identical certificate. For some reason WiX 3.0 does not like this. I would have to dig up the bug report, but I did run across it. During our tests with WiX 3.5 this issue seems to be resolved. Now, we could get into a conversation about cross product dependencies, etc. but I was not involved with any of those decisions so I am just trying to dig us out of the hole we are in. I am not sure the extra installer is going to help. It appears that anything touching the original certificate on the system causes the original WiX 3.0 MSI to fail. Yes, the install would ensure the cert is on the system, but the uninstall for the original WiX 3.0 MSI package would still fail. Thanks for the help. On Tue, Aug 28, 2012 at 11:46 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: As far as I can think, you can only selectively uninstall entire features without using permanent components. If the conditions are broken, would patching/minor updating them solve your problem ? I'm not sure what the WiX bug is that you're referring to. Otherwise, you could write an extra installer that only includes the component you want to keep, install that, then remove the original one. The extra reference would retain the component on the machine until you took both installers off. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 28 August 2012 16:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs We have a product that installs a few certificates on the system using the IIS extension using WiX 3.0. Evidently, there is an issue with the certificate action(s) in this version of the toolset. We are unable to uninstall/upgrade from this specific version in the field. I would like to know if there is a way during the uninstall (i.e. msiexec /x .) to pass command line parameters/properties to skip the uninstall of specific components, in this case the certificate that is giving us problems. The original authoring has conditions to skip the certificates when installing the product. Passing these properties during the uninstall does not seem to skip them during the uninstall process (like I was hoping it would). Ultimately, we have tested with WiX 3.5 and the bug appears to be fixed. So, we would like to be able to get the old version of the product uninstalled, leaving the certificate it originally installed behind, and then with the new WiX 3.5-built package reinstall the certificate hoping to workaround this original WiX 3.0 issue. If there is no other way to selectively uninstall, is there a possible way of forcibly causing the uninstall to succeed (understanding that some artifacts might be left behind)? I have all of the details of the original installation package, so if anything can be done I would very much appreciate the help. Thanks. - - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat
Re: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs
I assume when you say take the original installer you mean bump one of the three version digits and generate a new product version installer, i.e. 1.1.0 to 1.1.1, generate new product GUID, etc. Where this all started was trying to get a newer version of the product on the system. If I can make the RemoveExistingProducts changes to it and that actually works, then we should not need to figure out how to uninstall it first. On Tue, Aug 28, 2012 at 12:42 PM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Correct. Having thought about it a bit more, this might be a better idea: Take the original installer (or whatever is the current release). Make a major upgrade out of it in the normal way. Schedule RemoveExistingProducts in one of the latter two places mentioned in http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29 .aspx Build it with WiX 3.5 That'll create a major upgrade that shouldn't touch the certificate component. Being built with WiX 3.5, removal might then succeed. I'm not sure what the WiX team would say about mixing toolset versions like that but I'd guess there are risks, so you'd have to test thoroughly. You'd have to do the same thing with the second product too since you don't know which one will be removed last and will perform the actual certificate uninstallation. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 28 August 2012 17:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs Okay, so what you are saying is that I cannot skip individual components during uninstall, correct? I am not sure if these would work or not. We don't have minor installs, we use the third digit, but it is a full install. This product installs the certificate, and another product re-installs the identical certificate. For some reason WiX 3.0 does not like this. I would have to dig up the bug report, but I did run across it. During our tests with WiX 3.5 this issue seems to be resolved. Now, we could get into a conversation about cross product dependencies, etc. but I was not involved with any of those decisions so I am just trying to dig us out of the hole we are in. I am not sure the extra installer is going to help. It appears that anything touching the original certificate on the system causes the original WiX 3.0 MSI to fail. Yes, the install would ensure the cert is on the system, but the uninstall for the original WiX 3.0 MSI package would still fail. Thanks for the help. On Tue, Aug 28, 2012 at 11:46 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: As far as I can think, you can only selectively uninstall entire features without using permanent components. If the conditions are broken, would patching/minor updating them solve your problem ? I'm not sure what the WiX bug is that you're referring to. Otherwise, you could write an extra installer that only includes the component you want to keep, install that, then remove the original one. The extra reference would retain the component on the machine until you took both installers off. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 28 August 2012 16:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs We have a product that installs a few certificates on the system using the IIS extension using WiX 3.0. Evidently, there is an issue with the certificate action(s) in this version of the toolset. We are unable to uninstall/upgrade from this specific version in the field. I would like to know if there is a way during the uninstall (i.e. msiexec /x .) to pass command line parameters/properties to skip the uninstall of specific components, in this case the certificate that is giving us problems. The original authoring has conditions to skip the certificates when installing the product. Passing these properties during the uninstall does not seem to skip them during the uninstall process (like I was hoping it would). Ultimately, we have tested with WiX 3.5 and the bug appears to be fixed. So, we would like to be able to get the old version of the product uninstalled, leaving the certificate it originally installed behind, and then with the new WiX 3.5-built package reinstall the certificate hoping to workaround this original WiX 3.0 issue. If there is no other way to selectively uninstall, is there a possible way of forcibly causing the uninstall to succeed (understanding that some artifacts might be left behind)? I have all of the details of the original installation package, so if anything can be done I would very much appreciate the help. Thanks
Re: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs
So I created a new version (major upgrade) of the product. I adjusted RemoveExistingProducts to run after InstallFinalize. This didn't seem to help at all. It still attempts to remove the cert, and I have the same errors. Thanks. On Tue, Aug 28, 2012 at 3:26 PM, Andy Clugston clug...@gmail.com wrote: I assume when you say take the original installer you mean bump one of the three version digits and generate a new product version installer, i.e. 1.1.0 to 1.1.1, generate new product GUID, etc. Where this all started was trying to get a newer version of the product on the system. If I can make the RemoveExistingProducts changes to it and that actually works, then we should not need to figure out how to uninstall it first. On Tue, Aug 28, 2012 at 12:42 PM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Correct. Having thought about it a bit more, this might be a better idea: Take the original installer (or whatever is the current release). Make a major upgrade out of it in the normal way. Schedule RemoveExistingProducts in one of the latter two places mentioned in http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29 .aspx Build it with WiX 3.5 That'll create a major upgrade that shouldn't touch the certificate component. Being built with WiX 3.5, removal might then succeed. I'm not sure what the WiX team would say about mixing toolset versions like that but I'd guess there are risks, so you'd have to test thoroughly. You'd have to do the same thing with the second product too since you don't know which one will be removed last and will perform the actual certificate uninstallation. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 28 August 2012 17:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs Okay, so what you are saying is that I cannot skip individual components during uninstall, correct? I am not sure if these would work or not. We don't have minor installs, we use the third digit, but it is a full install. This product installs the certificate, and another product re-installs the identical certificate. For some reason WiX 3.0 does not like this. I would have to dig up the bug report, but I did run across it. During our tests with WiX 3.5 this issue seems to be resolved. Now, we could get into a conversation about cross product dependencies, etc. but I was not involved with any of those decisions so I am just trying to dig us out of the hole we are in. I am not sure the extra installer is going to help. It appears that anything touching the original certificate on the system causes the original WiX 3.0 MSI to fail. Yes, the install would ensure the cert is on the system, but the uninstall for the original WiX 3.0 MSI package would still fail. Thanks for the help. On Tue, Aug 28, 2012 at 11:46 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: As far as I can think, you can only selectively uninstall entire features without using permanent components. If the conditions are broken, would patching/minor updating them solve your problem ? I'm not sure what the WiX bug is that you're referring to. Otherwise, you could write an extra installer that only includes the component you want to keep, install that, then remove the original one. The extra reference would retain the component on the machine until you took both installers off. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 28 August 2012 16:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Conditional Uninstall - Need to workaround WiX Certificate custom action bugs We have a product that installs a few certificates on the system using the IIS extension using WiX 3.0. Evidently, there is an issue with the certificate action(s) in this version of the toolset. We are unable to uninstall/upgrade from this specific version in the field. I would like to know if there is a way during the uninstall (i.e. msiexec /x .) to pass command line parameters/properties to skip the uninstall of specific components, in this case the certificate that is giving us problems. The original authoring has conditions to skip the certificates when installing the product. Passing these properties during the uninstall does not seem to skip them during the uninstall process (like I was hoping it would). Ultimately, we have tested with WiX 3.5 and the bug appears to be fixed. So, we would like to be able to get the old version of the product uninstalled, leaving the certificate it originally installed behind, and then with the new WiX 3.5-built package reinstall the certificate hoping to workaround this original WiX 3.0 issue. If there is no other way to selectively uninstall
[WiX-users] MsiFileHash table
As I understand from MSDN ...The *MsiFileHash* table can only be used with unversioned files... Within WiX is it possible to force the use of this table for file components of versioned file types? Thank you. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MsiFileHash table
I appreciate the reply. I am very aware of proper versioning practices when developing software. Back to the original question... I can leverage the MSIHashTable for other reasons if it can be used for all files rather than just non-versioned files. So, can the use of the table be forced in any way via WiX? Thanks. On Thu, Mar 8, 2012 at 9:39 AM, Christopher Painter chr...@iswix.comwrote: The the theoretical world, if you are following proper versioning patterns when building your Versioned PE (Program Executable... DLL,SYS,OCX,EXE et al ) then you shouldn't need to worry about the hash. If you aren't ( foo.dll 1.0.0.0 or worse foo.dll version [null] doesn't uniquely describe the version of a file ) then you should really fix that problem first. If you can't because it's an unstream problem ( like foo.dll was provided by a vendor ) then you can consider using version lying as to trick the installer to always overwrite that file. Usually when I see bad practices like this it's either a sign of 1) Ignorant, junior developers 2) Decent developers with a strong background in Unix but ignorant to best practices developing on the Windows platform. Chris From: Andy Clugston clug...@gmail.com Sent: Thursday, March 08, 2012 8:07 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: [WiX-users] MsiFileHash table As I understand from MSDN ...The *MsiFileHash* table can only be used with unversioned files... Within WiX is it possible to force the use of this table for file components of versioned file types? Thank you. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Harvest Component Path
I am working with the Windows Installer APIs (msi.dll). I would like to be able to harvest the paths of file components of certain products installed on the system. I am currently using the automation interface and what I am finding when calling get_ComponentPath() is that the full path is only returned if the keypath (i.e. keypath attribute set to yes) on the component is set. I cannot always rely on the keypath being set. Does anyone know if this is a limitation of the the Automation interface? I am going to try the raw APIs, but I just wanted to get some feedback. This code needs to be as efficient as possible for performance reasons. Otherwise, I am wondering if I might have to build the path using the File and Directory tables. Thanks. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows Installer and Process Environment Block
I need to use CreateProcessAsUser() and pass the user token of the logged on user. Thanks. On Mon, Feb 27, 2012 at 7:48 PM, Wilson, Phil phil.wil...@invensys.comwrote: I suspect a LoadUserProfile is done for the user in question. That's what contains those kinds of paths etc. Phil W -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Wednesday, February 22, 2012 11:04 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Windows Installer and Process Environment Block I am working on an installation sequencer. The heart of the sequencer is a Windows system service that launches the install processes (typically msiexec) as they come in. The sequencer service is grabbing the environment block of the logged on user (this has been verified) and passing this block to CreateProcess(). In addition, any variable expansion on the command is expanded based on the currently logged on user. I see an issue where installation packages that target the user profile paths (AppData, etc.) ends up in the systemprofile instead. If the installation package is run by hand outside of the service, the files, etc. end up where they are supposed to which is in the currently logged on user's profile paths. How does Windows Installer determine the user profile / environment block when msiexec is executed? It apparently is not inheriting the environment from my sequencer service process, otherwise the profile data would end up in the right spot. Thank you. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Windows Installer and Process Environment Block
I am working on an installation sequencer. The heart of the sequencer is a Windows system service that launches the install processes (typically msiexec) as they come in. The sequencer service is grabbing the environment block of the logged on user (this has been verified) and passing this block to CreateProcess(). In addition, any variable expansion on the command is expanded based on the currently logged on user. I see an issue where installation packages that target the user profile paths (AppData, etc.) ends up in the systemprofile instead. If the installation package is run by hand outside of the service, the files, etc. end up where they are supposed to which is in the currently logged on user's profile paths. How does Windows Installer determine the user profile / environment block when msiexec is executed? It apparently is not inheriting the environment from my sequencer service process, otherwise the profile data would end up in the right spot. Thank you. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixQueryOsWellKnownSID
Evidently I am the only person that has attempted to use this? ;) The operating system that was having problems was a native-language version of Windows 7 and *not* standard (English) Windows 7 with a language pack installed. I've not looked into it as it is not a priority right now, but if anyone has any ideas... Thanks. On Mon, Feb 13, 2012 at 7:05 AM, Andy Clugston clug...@gmail.com wrote: Hello, I am attempting to use the WixQueryOsWellKnownSID action to query the localized group names for the Administrators and Users groups. In general, per the log file the action appears to be running and exiting but is still returning the English spelling of these groups thus causing the install package to fail (cannot locate the group names since they are misspelled). This is running on a Portuguese version of Windows 7 Professional. Using released version of WiX 3.0. This is how the source is using the action and properties: PropertyRef Id=WIX_ACCOUNT_ADMINISTRATORS / PropertyRef Id=WIX_ACCOUNT_USERS / util:Group Id=UsersGroup Name=[WIX_ACCOUNT_USERS]/ util:Group Id=AdministratorsGroup Name=[WIX_ACCOUNT_ADMINISTRATORS]/ Within the User element referencing the groups like so... util:GroupRef Id=UsersGroup/ util:GroupRef Id=AdministratorsGroup/ Is there something I am doing wrong, or does this action only support a subset of all possible languages? Is there a way to specify the names by common SID and avoid this action altogether? Thanks. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Applying System Security Policies via WiX (Windows Install in General)
All, Is there a way to apply system policies similar to how one would use secedit.exe? I currently have a custom action that runs secedit.exe which works fine, but the trouble is that my current approach does not work well with localized versions of Windows (i.e. the command line arguments specified are not the same as the English locale). Are there built-in Windows Installer or WiX features that I can use to perform this task instead? I have not found anything but that does not mean I didn't miss it either. Thanks. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WixQueryOsWellKnownSID
Hello, I am attempting to use the WixQueryOsWellKnownSID action to query the localized group names for the Administrators and Users groups. In general, per the log file the action appears to be running and exiting but is still returning the English spelling of these groups thus causing the install package to fail (cannot locate the group names since they are misspelled). This is running on a Portuguese version of Windows 7 Professional. Using released version of WiX 3.0. This is how the source is using the action and properties: PropertyRef Id=WIX_ACCOUNT_ADMINISTRATORS / PropertyRef Id=WIX_ACCOUNT_USERS / util:Group Id=UsersGroup Name=[WIX_ACCOUNT_USERS]/ util:Group Id=AdministratorsGroup Name=[WIX_ACCOUNT_ADMINISTRATORS]/ Within the User element referencing the groups like so... util:GroupRef Id=UsersGroup/ util:GroupRef Id=AdministratorsGroup/ Is there something I am doing wrong, or does this action only support a subset of all possible languages? Is there a way to specify the names by common SID and avoid this action altogether? Thanks. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installs on XP but not on Win7
I have a WiX 3.0 installer that works okay on XP SP3, but when attempting to install on Windows 7 Pro SP1 I see the following error: Action ended 18:33:17: InstallFinalize. Return value 3. Both systems are 32 bit operating systems, Win7 system has UAC disabled. It appears to be getting through the install, however when inspecting the log file (between when the InstallFinalize action started and ended), I just cannot see anything that jumps out at me as an issue, other than the error above. I've looked at the rest of the verbose log, and when diffing against the XP log, there is not anything obvious. There is nothing especially complicated about this install. It delivers some binaries, text files, registry entries, installs a service, and includes a custom action to apply a security template via secedit. Again, this works okay on XP. Any advice is appreciated, thanks for the help. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installs on XP but not on Win7
Funny you mention that. I had commented it out of the package install and was building while I typed the original message. Indeed, the template is the problem. Thanks. On Thu, Nov 17, 2011 at 10:49 PM, Alec Taylor alec.tayl...@gmail.comwrote: The security template may be the issue. On Fri, Nov 18, 2011 at 2:46 PM, Andy Clugston clug...@gmail.com wrote: I have a WiX 3.0 installer that works okay on XP SP3, but when attempting to install on Windows 7 Pro SP1 I see the following error: Action ended 18:33:17: InstallFinalize. Return value 3. Both systems are 32 bit operating systems, Win7 system has UAC disabled. It appears to be getting through the install, however when inspecting the log file (between when the InstallFinalize action started and ended), I just cannot see anything that jumps out at me as an issue, other than the error above. I've looked at the rest of the verbose log, and when diffing against the XP log, there is not anything obvious. There is nothing especially complicated about this install. It delivers some binaries, text files, registry entries, installs a service, and includes a custom action to apply a security template via secedit. Again, this works okay on XP. Any advice is appreciated, thanks for the help. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Computer Domain and Property(s) Listing
Yes, I understand this. Thanks for the heads up. In my environment I think it will work okay. On Tue, Jun 21, 2011 at 9:21 PM, Michael Osmond mosm...@baytech.com.auwrote: Be carefull using USERDOMAIN, it is the domain of the account that is logged in, which is not necessarily that of the domain the machine is in - for instance if you are logged in as a local account on the machine USERDOMAIN will be the computer name. I have not found an environment variable that gives you this. Michael From: Andy Clugston [clug...@gmail.com] Sent: Tuesday, 21 June 2011 8:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Computer Domain and Property(s) Listing I believe USERDOMAIN will work. Still having issues getting the conditional logic to work for me, I'll keep trying. Thanks. On Fri, Jun 17, 2011 at 4:36 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: Computer name includes only the NETBIOS name, not the domain. LogonUser doesn't contain the user's domain either. You could try getting what you want from environment variables. http://blogs.msdn.com/b/windows_installer_team/archive/2005/09/16/461742.aspx Just make sure the variable you check is available on all the OSes you support. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 16 June 2011 18:49 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Computer Domain and Property(s) Listing Hi All, I am looking for a quick way to determine if a system is on a specific domain when running an install. Can the LogonUser or Computer name property be used to derive this information? Is there another property that might help? I'm trying to avoid a custom action, but I'm not sure I can. Also, the latest version of Windows installer does not appear to log the property(s) listing as it did in Windows XP. Is there a way to enable this? FWIW, I enabled verbose loggin, and this information is still missing. Thanks! - - EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ 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. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev
Re: [WiX-users] Computer Domain and Property(s) Listing
I believe USERDOMAIN will work. Still having issues getting the conditional logic to work for me, I'll keep trying. Thanks. On Fri, Jun 17, 2011 at 4:36 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Computer name includes only the NETBIOS name, not the domain. LogonUser doesn't contain the user's domain either. You could try getting what you want from environment variables. http://blogs.msdn.com/b/windows_installer_team/archive/2005/09/16/461742.aspx Just make sure the variable you check is available on all the OSes you support. -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: 16 June 2011 18:49 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Computer Domain and Property(s) Listing Hi All, I am looking for a quick way to determine if a system is on a specific domain when running an install. Can the LogonUser or Computer name property be used to derive this information? Is there another property that might help? I'm trying to avoid a custom action, but I'm not sure I can. Also, the latest version of Windows installer does not appear to log the property(s) listing as it did in Windows XP. Is there a way to enable this? FWIW, I enabled verbose loggin, and this information is still missing. Thanks! - - EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ 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. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Computer Domain and Property(s) Listing
Hi All, I am looking for a quick way to determine if a system is on a specific domain when running an install. Can the LogonUser or Computer name property be used to derive this information? Is there another property that might help? I'm trying to avoid a custom action, but I'm not sure I can. Also, the latest version of Windows installer does not appear to log the property(s) listing as it did in Windows XP. Is there a way to enable this? FWIW, I enabled verbose loggin, and this information is still missing. Thanks! -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Integrity of WiX binaries
Ditto. Very interested in this topic as well. Thanks. On Thu, Apr 21, 2011 at 8:49 PM, lambda...@hushmail.com wrote: Hi, Is it possible for WiX binaries and the MSI (eg Wix35.msi) to be digitally signed by the WiX team? Alternatively is it possible for an authoritative team member to post MD5 and SHA-1 hashes of the official binaries and the MSI to this list? My organization now requires integrity validation of all software used in the build process. If the cost of a digital certificate is a consideration, I'm sure many organizations would be willing to donate Thank you -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WIX_ACCOUNT_EVERYONE]
Seems to be a popular topic lately... http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-7-MSI-privileges-td617.html http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-7-MSI-privileges-td617.htmlAs Pally said, setting the property is the proper method. On Wed, Mar 16, 2011 at 6:29 AM, Pally Sandher pally.sand...@iesve.comwrote: Depends on what you're setting this WIX_ACCOUNT_EVERYONE Property to what you're actually trying to achieve. Assuming you're trying to set permissions for the Everyone group you've arbitrarily picked the property WIX_ACCOUNT_EVERYONE out of the air to mean that without setting it to anything then I doubt it's going to work. Palbinder Sandher Software Deployment Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Naeem Ahmad [mailto:naeem.ah...@sophos.com] Sent: 15 March 2011 18:02 To: wix-users@lists.sourceforge.net Subject: [WiX-users] [WIX_ACCOUNT_EVERYONE] Hi, I am using [WIX_ACCOUNT_EVERYONE] I am trying to set Permission for service using util:Permission user=[WIX_ACCOUNT_EVERYONE] Is it right way to do it? Thanks, Naeem Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 991 2418 08. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 MSI privileges
What you are running into is UAC, Google it if you have not already. You need Execute=deferred custom actions with Impersonate=no. This will allow your custom actions, and subsequent child processes that they create, to inherit the local system privileges of the Windows Installer service. There are some situations where deferred actions cannot be used (depending on when the action is sequenced), but give this a try and see what you can come up with. On Tue, Mar 15, 2011 at 12:04 PM, The Eligible Bachelors theeligiblebachel...@yahoo.com wrote: This is mostly a MSI question and not too WiX specific. I am porting an old WiX (3.0) installer from XP to Windows 7. The installer needs to be run as an admin because makes several calls to external programs that need admin privileges (to register COM objects and such). Even when I am logged in as an admin, the calls to these external programs are failing and thus throwing an error at install time in my MSI. If I run an admin console and launch the MSI, these errors do not happen, since I guess I am more of an admin then. Googling around says this is a common problem in Win 7 and Vista and all the fixes seem cludgy (batch files, registry hacks). So my question is how do I get around this and why is this not a huge deal/common problem? It seems that any installer that needs admin privileges in Windows 7 has to go though hoops. Microsoft presumably has created this situation in an effort to increase security. So is there a new workflow I am supposed to be following to get the same thing done? And/or is there a known workaround for this in WiX? -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Trigger custom action on NEWERFOUND
All, I currently have the prevent downgrade custom action below... Custom Action='NoDowngradeAction' After='FindRelatedProducts'NEWERFOUND/Custom CustomAction Id='NoDowngradeAction' Error='Installation aborted. A later version of [ProductName] is already installed.' / One thing that I am tasked to support is updating of a product at runtime. So, shutting down the app(s), invoking msiexec, and starting them back up. The starting them back up is handled by custom actions in the MSI. The one use case that I am having trouble with is when an older version of the product is attempted to be installed on a system when a newer version already exists. The action above takes care of it, but I still need to restart the application. It appears that the Error handler causes an immediate exit of msiexec. I have tried to place my app-startup action before and after NoDowngradeAction, but in both cases the custom action is not called. The app-startup custom action is of type immediate. As always, any advice is appreciated. Thanks. -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Trigger custom action on NEWERFOUND
I believe I found a way to accomplish this. Using the OnExit=error as well as some other properties I already had setup seems to be working. On Tue, Feb 22, 2011 at 3:38 PM, Andy Clugston clug...@gmail.com wrote: All, I currently have the prevent downgrade custom action below... Custom Action='NoDowngradeAction' After='FindRelatedProducts'NEWERFOUND/Custom CustomAction Id='NoDowngradeAction' Error='Installation aborted. A later version of [ProductName] is already installed.' / One thing that I am tasked to support is updating of a product at runtime. So, shutting down the app(s), invoking msiexec, and starting them back up. The starting them back up is handled by custom actions in the MSI. The one use case that I am having trouble with is when an older version of the product is attempted to be installed on a system when a newer version already exists. The action above takes care of it, but I still need to restart the application. It appears that the Error handler causes an immediate exit of msiexec. I have tried to place my app-startup action before and after NoDowngradeAction, but in both cases the custom action is not called. The app-startup custom action is of type immediate. As always, any advice is appreciated. Thanks. -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about creating a bootstrap to launch the MSI with Reinstall parameters
When you create your new version what specifically is changing? Other than the deliverables/updates of course... - Anything changing with ProductGuid, UpgradeCode, etc? - Are you only bumping the 4th digit, 1.1.0.2, 1.1.0.3, 1.1.0.4, etc.? - Is your MSI file name changing? I've had success doing what you are attempting, although I ended up going the Major Upgrade route in the end based on other requirements. On Mon, Jan 24, 2011 at 6:31 PM, Wilson, Phil phil.wil...@invensys.comwrote: If David is getting multiple entries in ARP then the upgrade is not finding the previous version. All other things being equal (and implemented correctly), a cross-context upgrade won't work, per-user install upgrading to per-system or vice versa. Phil Wilson -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, January 24, 2011 4:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about creating a bootstrap to launch the MSI with Reinstall parameters This works pretty well for me when shipping internal beta builds http://blogs.msdn.com/b/johnls/archive/2006/11/13/how-to-upgrade-software-with-a-windows-installer-package.aspx No bootstrapper required. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: David Borneman [mailto:d...@servingtulsa.com] Sent: 24 January 2011 07:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about creating a bootstrap to launch the MSI with Reinstall parameters Actually, let me back up a second. The whole reason I created this question is that the RemoveExistingProducts action is just not working. The upgrade succeeds, but it leaves multiple entries in the Add/Remove Programs CP. I went thru literally dozens of attempts with different settings for Upgrade/RemoveExisting from information I found on various help websites, with the result most of the time being the dreaded Another version of this program is already installed..., and the others that succeeded leaving multiple entries in the control panel. I am pretty sure there is something very simple wrong, I just can't seem to find it. :/ Dave On Mon, Jan 24, 2011 at 2:21 PM, Blair os...@live.com wrote: That requires a bootstrapper that knows something about Windows Installer. Even for minor changes a Major Upgrade is often the simplest option. If you are trying to minimize the changes during upgrades, consider a Major Upgrade with late scheduling of RemoveExistingProducts. -Blair -Original Message- From: David Borneman [mailto:d...@servingtulsa.com] Sent: Saturday, January 22, 2011 5:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about creating a bootstrap to launch the MSI with Reinstall parameters Hiya all, Hope this messages goes thru... Tis my very first mailing list message :) I am getting the dreaded Another version of this application is already installed blah when trying to install a newer version of our software. Its a minor upgrade, but it is in Beta so we prefer a reinstall, at least for now, like a Major Install. I found a suggestion that I create a bootstrapper for this, which I did (and took the opportunity to add in some pre-requisites), but currently the bootstrapper is simply executing the MSI as it was downloaded, without any other parameters (as is correct since I have not configured it otherwise lol). What i need to know how to do, and cant figure out for the life of me, is how to instead execute the following: msiexec /i OurInstallerApp.msi REINSTALL=ALL REINSTALLMODE=vomus Any kick in the right direction would be greatly appreciated! David Borneman Senior Developer -- -- -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download
[WiX-users] PROCESSOR_ARCHITECTURE - x86 MSI on 64bit Windows 7
Hi Users, I am working the kinks out of an MSI to support 64 bit. This is an x86 MSI that will run in WOW64 on x64 systems. The issue I am seeing is that the PROCESSOR_ARCHITECTURE is set to x86 (rather than what the base OS architecture is; i.e. AMD64) within a custom action that is running. This is observed when the MSI is executed on a 64-bit system. Is this to be expected? I can reason my way through it considering the WOW64 environment, but I wanted to double check. Thanks. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Actions UAC
Phil, I am running Win7 and 5.0 of msiexec is on the system (shipped with it), and I still see the issue. Thanks. On Fri, Jan 21, 2011 at 4:08 PM, wix user wixuser...@gmail.com wrote: Hi Phil, How is the WIX support for MSI 4.5 features? We are planning to use Multiple transaction features. Are there some help resource avaiable? Thanks On Fri, Jan 21, 2011 at 11:17 AM, Wilson, Phil phil.wil...@invensys.com wrote: Use MSI 4.5 - it got restored there. http://support.microsoft.com/kb/942288 Phil Wilson -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Thursday, January 20, 2011 6:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions UAC Well I think I have figured out why the issue is occurring. The call that is failing in the custom action is LoadUserProfile(). This needs the SeBackupPrivilege which the windows installers service *does not* have on a UAC-enabled system. Some details: http://blogs.msdn.com/b/vistacompatteam/archive/2006/10/19/impact-of-least-privilege-in-system-services.aspx http://blogs.msdn.com/b/windows_installer_team/archive/2008/05/01/what-changed-in-windows-installer-4-5.aspx http://social.msdn.microsoft.com/Forums/en/windowssecurity/thread/b9ea2a0e-5a0e-4e07-92e2-4c7e1f2c5496 Any advice or known workarounds are welcome. :) On Thu, Jan 20, 2011 at 3:33 PM, Andy Clugston clug...@gmail.com wrote: Hi Users, I am working on a product that needs to support Windows 7 w/ UAC enabled. The MSI has a few custom actions that perform various configuration items that I would like to keep contained within the MSI/product install. The custom actions are Execute='deferred' with Impersonate='no' and they are scheduled Before='InstallFinalize'. One action is a vb script, and the other calls a native C/C++ dll. They *both* contain configuration items that require elevated privileges. Now, I have verified that the vb script action works fine, however the dll custom action does not. I am getting a permission error from the dll custom action when it runs. So, it appears to me that there is a difference in the two different types of custom actions, and how the user/system privileges are propagated from the msiexec process to these action processes. I've done some digging online (and will continue to) regarding the issue, but have not run across this particular case with the different action types acting differently. I am running the MSI on a Win7 x32 system with UAC using WiX 3.0.5419. As always, thanks for the help. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77 . You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users
Re: [WiX-users] PROCESSOR_ARCHITECTURE - x86 MSI on 64bit Windows 7
Yep. Thanks for the reply. On Sat, Jan 22, 2011 at 11:31 AM, Rob Mensching r...@robmensching.comwrote: Yeah, 32-bit processes on 64-bit Windows get PROCESSOR_ARCHITECTURE=x86. Start up a 32-bit cmd.exe and you'll see the same thing. On Sat, Jan 22, 2011 at 3:58 AM, Andy Clugston clug...@gmail.com wrote: Hi Users, I am working the kinks out of an MSI to support 64 bit. This is an x86 MSI that will run in WOW64 on x64 systems. The issue I am seeing is that the PROCESSOR_ARCHITECTURE is set to x86 (rather than what the base OS architecture is; i.e. AMD64) within a custom action that is running. This is observed when the MSI is executed on a 64-bit system. Is this to be expected? I can reason my way through it considering the WOW64 environment, but I wanted to double check. Thanks. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Actions UAC
I didn't look at your link but, yes, if I add SeBackupPrivilege to the service privileges in the registry (and restart the service) it works as expected. This might be an option, but it is a bit of a chicken and egg scenario for this particular product. The other option is to set Impersonate=yes and be sure to execute the MSI from an elevated command prompt (or local system service). This way, the deferred action grabs the permission from the elevated administrator process rather than the msiexec process. One of the use cases was to be able to allow the user to double click the MSI to launch it (pretty outlandish, right? :) ), and simply agree when prompted with the UAC elevation dialog. Although, given this bug in Windows Installer, there is not a clean/simple way around this. The other point of frustration is that 4.5 claims to have this issue resolved, but it is most definitely not in 5.0. So, I am assuming 4.5 has the same problem even though various sources state differently. My next test will be to upgrade a system to 4.5 and do some testing of my own just to get a level set. This is not a use case I need to support, but it has me curious. Thanks for the reply. On Sat, Jan 22, 2011 at 6:19 PM, Blair os...@live.com wrote: Just curious: do you need to enable SeBackupPrivilege? Something like http://msdn.microsoft.com/en-us/library/aa387705(VS.85).aspxhttp://msdn.microsoft.com/en-us/library/aa387705%28VS.85%29.aspx -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Saturday, January 22, 2011 6:54 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions UAC Phil, I am running Win7 and 5.0 of msiexec is on the system (shipped with it), and I still see the issue. Thanks. On Fri, Jan 21, 2011 at 4:08 PM, wix user wixuser...@gmail.com wrote: Hi Phil, How is the WIX support for MSI 4.5 features? We are planning to use Multiple transaction features. Are there some help resource avaiable? Thanks On Fri, Jan 21, 2011 at 11:17 AM, Wilson, Phil phil.wil...@invensys.com wrote: Use MSI 4.5 - it got restored there. http://support.microsoft.com/kb/942288 Phil Wilson -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Thursday, January 20, 2011 6:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions UAC Well I think I have figured out why the issue is occurring. The call that is failing in the custom action is LoadUserProfile(). This needs the SeBackupPrivilege which the windows installers service *does not* have on a UAC-enabled system. Some details: http://blogs.msdn.com/b/vistacompatteam/archive/2006/10/19/impact-of-least-p rivilege-in-system-services.aspxhttp://blogs.msdn.com/b/vistacompatteam/archive/2006/10/19/impact-of-least-privilege-in-system-services.aspx http://blogs.msdn.com/b/windows_installer_team/archive/2008/05/01/what-chang ed-in-windows-installer-4-5.aspxhttp://blogs.msdn.com/b/windows_installer_team/archive/2008/05/01/what-changed-in-windows-installer-4-5.aspx http://social.msdn.microsoft.com/Forums/en/windowssecurity/thread/b9ea2a0e-5 a0e-4e07-92e2-4c7e1f2c5496http://social.msdn.microsoft.com/Forums/en/windowssecurity/thread/b9ea2a0e-5a0e-4e07-92e2-4c7e1f2c5496 Any advice or known workarounds are welcome. :) On Thu, Jan 20, 2011 at 3:33 PM, Andy Clugston clug...@gmail.com wrote: Hi Users, I am working on a product that needs to support Windows 7 w/ UAC enabled. The MSI has a few custom actions that perform various configuration items that I would like to keep contained within the MSI/product install. The custom actions are Execute='deferred' with Impersonate='no' and they are scheduled Before='InstallFinalize'. One action is a vb script, and the other calls a native C/C++ dll. They *both* contain configuration items that require elevated privileges. Now, I have verified that the vb script action works fine, however the dll custom action does not. I am getting a permission error from the dll custom action when it runs. So, it appears to me that there is a difference in the two different types of custom actions, and how the user/system privileges are propagated from the msiexec process to these action processes. I've done some digging online (and will continue to) regarding the issue, but have not run across this particular case with the different action types acting differently. I am running the MSI on a Win7 x32 system with UAC using WiX 3.0.5419. As always, thanks for the help. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log
Re: [WiX-users] PROCESSOR_ARCHITECTURE - x86 MSI on 64bit Windows 7
Ahh, cool. I was temporarily keying off of ProgramFiles(x86), but this is another option, thanks. On Sat, Jan 22, 2011 at 5:50 PM, Blair os...@live.com wrote: If you happen to need to know what the base OS architecture is you can check for the presence/value of PROCESSOR_ARCHITEW6432. http://msdn.microsoft.com/library/aa384274.aspx -Blair -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Saturday, January 22, 2011 9:26 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] PROCESSOR_ARCHITECTURE - x86 MSI on 64bit Windows 7 Yep. Thanks for the reply. On Sat, Jan 22, 2011 at 11:31 AM, Rob Mensching r...@robmensching.com wrote: Yeah, 32-bit processes on 64-bit Windows get PROCESSOR_ARCHITECTURE=x86. Start up a 32-bit cmd.exe and you'll see the same thing. On Sat, Jan 22, 2011 at 3:58 AM, Andy Clugston clug...@gmail.com wrote: Hi Users, I am working the kinks out of an MSI to support 64 bit. This is an x86 MSI that will run in WOW64 on x64 systems. The issue I am seeing is that the PROCESSOR_ARCHITECTURE is set to x86 (rather than what the base OS architecture is; i.e. AMD64) within a custom action that is running. This is observed when the MSI is executed on a 64-bit system. Is this to be expected? I can reason my way through it considering the WOW64 environment, but I wanted to double check. Thanks. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Actions UAC
Per your link... The issue with Windows Installer 5.0 is that the SeBackupPrivilege permission is missing altogether. It is necessary to add it to the service permission value in the registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msiserver\RequiredPrivileges). If you use process explorer and look at a system service, you will typically see the SeBackupPrivilege being present, but in the disabled state. From my understanding, when the API needs this privilege it enables it, uses it, then disables it again. On Sat, Jan 22, 2011 at 8:42 PM, Andy Clugston clug...@gmail.com wrote: I didn't look at your link but, yes, if I add SeBackupPrivilege to the service privileges in the registry (and restart the service) it works as expected. This might be an option, but it is a bit of a chicken and egg scenario for this particular product. The other option is to set Impersonate=yes and be sure to execute the MSI from an elevated command prompt (or local system service). This way, the deferred action grabs the permission from the elevated administrator process rather than the msiexec process. One of the use cases was to be able to allow the user to double click the MSI to launch it (pretty outlandish, right? :) ), and simply agree when prompted with the UAC elevation dialog. Although, given this bug in Windows Installer, there is not a clean/simple way around this. The other point of frustration is that 4.5 claims to have this issue resolved, but it is most definitely not in 5.0. So, I am assuming 4.5 has the same problem even though various sources state differently. My next test will be to upgrade a system to 4.5 and do some testing of my own just to get a level set. This is not a use case I need to support, but it has me curious. Thanks for the reply. On Sat, Jan 22, 2011 at 6:19 PM, Blair os...@live.com wrote: Just curious: do you need to enable SeBackupPrivilege? Something like http://msdn.microsoft.com/en-us/library/aa387705(VS.85).aspxhttp://msdn.microsoft.com/en-us/library/aa387705%28VS.85%29.aspx -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Saturday, January 22, 2011 6:54 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions UAC Phil, I am running Win7 and 5.0 of msiexec is on the system (shipped with it), and I still see the issue. Thanks. On Fri, Jan 21, 2011 at 4:08 PM, wix user wixuser...@gmail.com wrote: Hi Phil, How is the WIX support for MSI 4.5 features? We are planning to use Multiple transaction features. Are there some help resource avaiable? Thanks On Fri, Jan 21, 2011 at 11:17 AM, Wilson, Phil phil.wil...@invensys.com wrote: Use MSI 4.5 - it got restored there. http://support.microsoft.com/kb/942288 Phil Wilson -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Thursday, January 20, 2011 6:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions UAC Well I think I have figured out why the issue is occurring. The call that is failing in the custom action is LoadUserProfile(). This needs the SeBackupPrivilege which the windows installers service *does not* have on a UAC-enabled system. Some details: http://blogs.msdn.com/b/vistacompatteam/archive/2006/10/19/impact-of-least-p rivilege-in-system-services.aspxhttp://blogs.msdn.com/b/vistacompatteam/archive/2006/10/19/impact-of-least-privilege-in-system-services.aspx http://blogs.msdn.com/b/windows_installer_team/archive/2008/05/01/what-chang ed-in-windows-installer-4-5.aspxhttp://blogs.msdn.com/b/windows_installer_team/archive/2008/05/01/what-changed-in-windows-installer-4-5.aspx http://social.msdn.microsoft.com/Forums/en/windowssecurity/thread/b9ea2a0e-5 a0e-4e07-92e2-4c7e1f2c5496http://social.msdn.microsoft.com/Forums/en/windowssecurity/thread/b9ea2a0e-5a0e-4e07-92e2-4c7e1f2c5496 Any advice or known workarounds are welcome. :) On Thu, Jan 20, 2011 at 3:33 PM, Andy Clugston clug...@gmail.com wrote: Hi Users, I am working on a product that needs to support Windows 7 w/ UAC enabled. The MSI has a few custom actions that perform various configuration items that I would like to keep contained within the MSI/product install. The custom actions are Execute='deferred' with Impersonate='no' and they are scheduled Before='InstallFinalize'. One action is a vb script, and the other calls a native C/C++ dll. They *both* contain configuration items that require elevated privileges. Now, I have verified that the vb script action works fine, however the dll custom action does not. I am getting a permission error from the dll custom action when it runs. So, it appears to me that there is a difference in the two different types
[WiX-users] Custom Actions UAC
Hi Users, I am working on a product that needs to support Windows 7 w/ UAC enabled. The MSI has a few custom actions that perform various configuration items that I would like to keep contained within the MSI/product install. The custom actions are Execute='deferred' with Impersonate='no' and they are scheduled Before='InstallFinalize'. One action is a vb script, and the other calls a native C/C++ dll. They *both* contain configuration items that require elevated privileges. Now, I have verified that the vb script action works fine, however the dll custom action does not. I am getting a permission error from the dll custom action when it runs. So, it appears to me that there is a difference in the two different types of custom actions, and how the user/system privileges are propagated from the msiexec process to these action processes. I've done some digging online (and will continue to) regarding the issue, but have not run across this particular case with the different action types acting differently. I am running the MSI on a Win7 x32 system with UAC using WiX 3.0.5419. As always, thanks for the help. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Actions UAC
Well I think I have figured out why the issue is occurring. The call that is failing in the custom action is LoadUserProfile(). This needs the SeBackupPrivilege which the windows installers service *does not* have on a UAC-enabled system. Some details: http://blogs.msdn.com/b/vistacompatteam/archive/2006/10/19/impact-of-least-privilege-in-system-services.aspx http://blogs.msdn.com/b/windows_installer_team/archive/2008/05/01/what-changed-in-windows-installer-4-5.aspx http://social.msdn.microsoft.com/Forums/en/windowssecurity/thread/b9ea2a0e-5a0e-4e07-92e2-4c7e1f2c5496 Any advice or known workarounds are welcome. :) On Thu, Jan 20, 2011 at 3:33 PM, Andy Clugston clug...@gmail.com wrote: Hi Users, I am working on a product that needs to support Windows 7 w/ UAC enabled. The MSI has a few custom actions that perform various configuration items that I would like to keep contained within the MSI/product install. The custom actions are Execute='deferred' with Impersonate='no' and they are scheduled Before='InstallFinalize'. One action is a vb script, and the other calls a native C/C++ dll. They *both* contain configuration items that require elevated privileges. Now, I have verified that the vb script action works fine, however the dll custom action does not. I am getting a permission error from the dll custom action when it runs. So, it appears to me that there is a difference in the two different types of custom actions, and how the user/system privileges are propagated from the msiexec process to these action processes. I've done some digging online (and will continue to) regarding the issue, but have not run across this particular case with the different action types acting differently. I am running the MSI on a Win7 x32 system with UAC using WiX 3.0.5419. As always, thanks for the help. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom Action - Dll C++
Hi Users, I am running into a bit of an issue while attempting to hook a C++ dll custom action into my installer. From all my research and debugging it appears that I have things setup properly. I have some tracing (message boxes) to indicate when DLLMain is entered/exited as well as my CA function. The dll is being loaded as can be seen by my tracing, but my CA function is not being called. Verbose logging is not telling me much, other than a 1603, and the typical Return value 3 error. I followed the tutorial here: http://www.wixwiki.com/index.php?title=Simple_Custom_Action_Dll Depends shows that the function is being exported properly as I see the exported function/ordinal. Some other things to mention: - I am using the __stdcall convention - To be safe, the dll is statically linked to the runtime (even though the runtime is installed on the target) - The CA dll is being create via VS 2008 and the WiX version is 3.0.5419. - CustomAction element is setting the Id, BinaryKey, and DllEntry=MyCAFunction - Custom element is being sequenced: Before=InstallFinalize - Viewing the MSI via Orca, everything seems to be in order - Same issue on 32 and 64 bit versions of Windows 7 Thanks! -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action - Dll C++
Yes, that was it!
I guess I have been out of native development too long... Thanks for the
reminder on the function export.
Thanks again!
On Wed, Jan 5, 2011 at 10:50 AM, Leonidas Spyropoulos
leonidas.spyropou...@formicary.net wrote:
On 05/01/2011 15:30, Andy Clugston wrote:
Hi Users,
Hey Andy,
I am running into a bit of an issue while attempting to hook a C++ dll
custom action into my installer. From all my research and debugging it
appears that I have things setup properly. I have some tracing (message
boxes) to indicate when DLLMain is entered/exited as well as my CA
function.
The dll is being loaded as can be seen by my tracing, but my CA function
is
not being called. Verbose logging is not telling me much, other than a
1603,
and the typical Return value 3 error.
I followed the tutorial here:
http://www.wixwiki.com/index.php?title=Simple_Custom_Action_Dll
Depends shows that the function is being exported properly as I see the
exported function/ordinal.
I followed the tutorial couple of days ago and got relativly same issues.
At the end after some googling I added: extern C _declspec(dllexport)
in the definition of the function I use like:
extern C _declspec(dllexport) UINT __stdcall ConfigForH2(MSIHANDLE
hInstaller){
...}
Also if you want to use properties from the UISequence you have to add
another CustomAction which will be run BEFORE the actual CustomAction to
set up the Properties. eg.
--
CustomAction Id =ExporterConfiguration.SetProperties Return=check
Property=ExporterConfiguration
Value=InstallLocation=[INSTALLLOCATION];Username=[UserIdBox];Password=[PasswordBox];
/
CustomAction Id =ExporterConfiguration BinaryKey=CustomAction
DllEntry=ConfigForH2 Execute=deferred/
And when I call the Custom Actions:
InstallExecuteSequence
Custom Action=ExporterConfiguration.SetProperties
Before=ExporterConfiguration![CDATA[NOT Installed]]/Custom
Custom Action=ExporterConfiguration
Before=InstallFinalize![CDATA[NOT Installed]]/Custom
/InstallExecuteSequence
I hope this is useful to you.
Some other things to mention:
- I am using the __stdcall convention
- To be safe, the dll is statically linked to the runtime (even though
the
runtime is installed on the target)
- The CA dll is being create via VS 2008 and the WiX version is 3.0.5419.
- CustomAction element is setting the Id, BinaryKey, and
DllEntry=MyCAFunction
- Custom element is being sequenced: Before=InstallFinalize
- Viewing the MSI via Orca, everything seems to be in order
- Same issue on 32 and 64 bit versions of Windows 7
Thanks!
--
Learn how Oracle Real Application Clusters (RAC) One Node allows
customers
to consolidate database storage, standardize their database environment,
and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Leonidas Spyropoulos
Formicary - delivering quality financial technology solutions
www.formicary.net
This message is confidential and may be privileged. It is intended solely
for
the named addressee. If you are not the intended recipient, please inform
us.
Any unauthorised dissemination, distribution or copying hereof is
prohibited.
Formicary Limited registered office in England and Wales, address 1 Taillar
Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT
number
747644304, does not guarantee that the integrity of this communication has
been
maintained nor that this communication is free of viruses, interceptions or
interference.
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment,
and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
[WiX-users] Target User Registry Hive
Hi WiX Users, Is it possible to target a user's hive (other than the logged on user) during the install process? I did a quick review of the Registry elements and didn't see anything jump out at me. Thanks! -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Understanding Windows Installer Exit (Error) Codes
Hi All, After doing some searching, it seems that the general understanding is that Windows Installer does a poor job with exit codes returned when an MSI does not complete successfully for some reason. A case that we have encountered is where we are preventing downgrades for our install packages. When we encounter this, Windows installer returns a 1603 error code. I can understand some type of error code being returned being that the install did not complete successfully. However, 1603 seems to be a pretty common error code, and in some cases it is impossible to determine if the downgrade logic was encountered, or if actually something bad/fatal happened that caused the 1603 code. Is it possible to instruct Windows Installer to return a specific error code? For instance, in our downgrade scenario, would it be possible to exit with a different code instead of the 1603? Thanks. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Understanding Windows Installer Exit (Error) Codes
Guys, I appreciate the reply. Do you have any suggestions on how to accomplish this? If I understand you correctly, you are referring to a status code that might be presented in the (verbose?) log ? Parsing the log was something I have thought about, but it is really going to add more complexity to the install/verification process than I wanted to deal with. Currently, anything other than zero (or a code that is not expected) is considered bad, and it sounds like there is really no good way around this issue... darn. :-/ Thanks again. On Tue, Nov 30, 2010 at 12:11 PM, Blair os...@live.com wrote: There are two types of error codes in windows installer: internal status codes and external result codes. As you noticed, the catchall for the external codes tends to be 1603. Sometimes, however, the internal codes that end up in a detailed log are actually more useful. If you have the ability to use either an external or internal UI handler, sometimes you can get a useful internal code you can report along with the 1603 as additional information (not as an exit code, but yes in your own logging/reporting). That is how we have distinguished your situation. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Tuesday, November 30, 2010 7:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Understanding Windows Installer Exit (Error) Codes Sadly, no. On Tue, Nov 30, 2010 at 5:33 AM, Andy Clugston clug...@gmail.com wrote: Hi All, After doing some searching, it seems that the general understanding is that Windows Installer does a poor job with exit codes returned when an MSI does not complete successfully for some reason. A case that we have encountered is where we are preventing downgrades for our install packages. When we encounter this, Windows installer returns a 1603 error code. I can understand some type of error code being returned being that the install did not complete successfully. However, 1603 seems to be a pretty common error code, and in some cases it is impossible to determine if the downgrade logic was encountered, or if actually something bad/fatal happened that caused the 1603 code. Is it possible to instruct Windows Installer to return a specific error code? For instance, in our downgrade scenario, would it be possible to exit with a different code instead of the 1603? Thanks. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best Practices - Using * for GUID automation
Hi All, I am having some trouble and need to blow the dust off of this one. Still using WiX v3.0. I have created an automated build infrastructure using heat.exe which utilizes the * for component GUIDs. As stated in this thread originally, I have a product that was released (v1.0.0) with hard coded GUIDs. I am now testing with the new build infrastructure and am having issues upgrading from the release 1.0.0 to the new 1.0.1. I have verified that the version string, product, and package GUID have changed, and the Upgrade GUID is the same as released v1.0.0. What I am experiencing is that the deliverables are being removed however the install log states that the install was successful. This leads me to believe that the change of the component GUID paradigm has something to do with it. The paths are identical, and I am using a component-per-deliverable design for the WiX authoring. The PREVIOUSFOUND property is being set in an UpgradeVersion element and I am also setting RemoveExistingProducts After=InstallFinalize/ in the InstallExecuteSequence section. Here is the interesting part... If I generate a v1.0.0 using the new infrastructure, and attempt the install/upgrade of 1.0.1 using the same infrastructure, everything works just fine. Thanks again. On Thu, Jul 1, 2010 at 9:42 AM, Andy Clugston clug...@gmail.com wrote: Alright, thanks. On Tue, Jun 29, 2010 at 11:14 PM, Rob Mensching r...@robmensching.comwrote: No problems if you use a major upgrade and schedule the upgrade early. Standardizing on Component/@Guid=* is fantastic except when you can't use it. The binder will tell you when that is. Then you're stuck with specifying a GUID. -- virtually, Rob Mensching - http://RobMensching.com LLC On Tue, Jun 29, 2010 at 5:29 PM, Andy Clugston clug...@gmail.com wrote: v1.0.0 of a particular product was shipped with hard coded GUIDs. So, if I change to * for version 1.0.1, I will have issues? On Tue, Jun 29, 2010 at 7:47 PM, Blair os...@live.com wrote: Using * for components should always be appropriate for all components that accept * for the Guid, as long as you have never shipped the component with a different GUID before. It won't cause problems with generating Patches. What will cause problems with generating patches is removing any component from any feature, renaming the keypath for any component (which, when using * for the Guid effectively removes the old component and adds a new one in its place), and changing either the directory for the component or any of that directories parents (at least as far as the closest well-known directory), for those components who's keypaths are files. Have you shipped your product before using guids that were not *? -Original Message- From: James Poole [mailto:w...@slowcommotion.com] Sent: Tuesday, June 29, 2010 11:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Best Practices - Using * for GUID automation Could someone chime in with a time when you wouldn't want to use * on component Guids? Would this cause issues with generating patches? -James On Tue, Jun 29, 2010 at 1:19 PM, Andy Clugston clug...@gmail.com wrote: Okay, it seemed like this approach would work, just wanted to verify. Thanks! On Tue, Jun 29, 2010 at 10:10 AM, Cherney John-CJC030 john.cher...@motorola.com wrote: I haven't had any problems with component ids set to *. We keep the Upgrade id constant but vary everything else, including the version and the MSI name (which contains the version). Because of the changing version and the constant upgrade id (and the PREVIOUSFOUND property getting set in the UpgradeVersion element), we are automatically uninstalling older versions as part of our install. Works very well. jwc -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Tuesday, June 29, 2010 7:35 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Best Practices - Using * for GUID automation I am trying to determine the best approach to take with creating GUIDs for the various WiX elements. We use a full upgrade approach so I believe for the Product Id=* is okay. It probably goes without saying that setting Package Id=* makes sense in all cases. It is my understanding that the Upgrade Id should be static (never changes) for the life of a product installer, assuming the name of the MSI does not change. The one that I need some assistance with is at the Component level. We want to automate as much as we can, and having to update Component GUIDs for hundreds of deliverables is a pain. Is it safe to set Component Guid=*, or will this cause problems in the future? I worry
Re: [WiX-users] Best Practices - Using * for GUID automation
Hi Mike, Thanks for the info. What you stated is what I am seeing in the verbose logs. I see where the files are being copied, and then I see where they are being removed. Doing a diff between the good v1.0.0 case and the bad v1.0.0 case makes it obvious. So if I understand you on the sequencing, I need to configure RemoveExisitingProducts like... RemoveExistingProducts After=InstallValidate Before=InstallInitialize/ or is simply RemoveExistingProducts After=InstallValidate/ satisfactory? Will sequencing in this fashion allow a rollback to v1.0.0 to take place if the install of v1.0.1 fails for some reason? One final question. As we create future versions of the product, should I adjust the sequencing of RemoveExistingProducts back to RemoveExistingProducts After=InstallFinalize/ since after v1.0.1 all component GUIDs will be generated via the * convention? I suppose this could get tricky, as we would need to consider upgrade paths. Thanks!! On Wed, Oct 6, 2010 at 11:06 AM, MikeR michael.ru...@gmail.com wrote: This is the expected behavior for that configuration. The problem is that since your component GUIDs don't line up from v1.0.0 to v1.0.1 the upgrade installs the new components and then after InstallFinalize removes the old components because it is not able to properly reference count them using the component GUIDs. You can work around this by sequencing RemoveExistingProducts between InstallValidate and InstallInitialize. This is a less efficient way of upgrading as you are basically doing a complete uninstall and reinstall in one session as opposed to just upgrading the necessary components but it will solve your current problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Best-Practices-Using-for-GUID-automation-tp5234716p5607427.html Sent from the wix-users mailing list archive at Nabble.com. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best Practices - Using * for GUID automation
Alright, thanks. On Tue, Jun 29, 2010 at 11:14 PM, Rob Mensching r...@robmensching.comwrote: No problems if you use a major upgrade and schedule the upgrade early. Standardizing on Component/@Guid=* is fantastic except when you can't use it. The binder will tell you when that is. Then you're stuck with specifying a GUID. -- virtually, Rob Mensching - http://RobMensching.com LLC On Tue, Jun 29, 2010 at 5:29 PM, Andy Clugston clug...@gmail.com wrote: v1.0.0 of a particular product was shipped with hard coded GUIDs. So, if I change to * for version 1.0.1, I will have issues? On Tue, Jun 29, 2010 at 7:47 PM, Blair os...@live.com wrote: Using * for components should always be appropriate for all components that accept * for the Guid, as long as you have never shipped the component with a different GUID before. It won't cause problems with generating Patches. What will cause problems with generating patches is removing any component from any feature, renaming the keypath for any component (which, when using * for the Guid effectively removes the old component and adds a new one in its place), and changing either the directory for the component or any of that directories parents (at least as far as the closest well-known directory), for those components who's keypaths are files. Have you shipped your product before using guids that were not *? -Original Message- From: James Poole [mailto:w...@slowcommotion.com] Sent: Tuesday, June 29, 2010 11:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Best Practices - Using * for GUID automation Could someone chime in with a time when you wouldn't want to use * on component Guids? Would this cause issues with generating patches? -James On Tue, Jun 29, 2010 at 1:19 PM, Andy Clugston clug...@gmail.com wrote: Okay, it seemed like this approach would work, just wanted to verify. Thanks! On Tue, Jun 29, 2010 at 10:10 AM, Cherney John-CJC030 john.cher...@motorola.com wrote: I haven't had any problems with component ids set to *. We keep the Upgrade id constant but vary everything else, including the version and the MSI name (which contains the version). Because of the changing version and the constant upgrade id (and the PREVIOUSFOUND property getting set in the UpgradeVersion element), we are automatically uninstalling older versions as part of our install. Works very well. jwc -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Tuesday, June 29, 2010 7:35 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Best Practices - Using * for GUID automation I am trying to determine the best approach to take with creating GUIDs for the various WiX elements. We use a full upgrade approach so I believe for the Product Id=* is okay. It probably goes without saying that setting Package Id=* makes sense in all cases. It is my understanding that the Upgrade Id should be static (never changes) for the life of a product installer, assuming the name of the MSI does not change. The one that I need some assistance with is at the Component level. We want to automate as much as we can, and having to update Component GUIDs for hundreds of deliverables is a pain. Is it safe to set Component Guid=*, or will this cause problems in the future? I worry that this will affect how upgrades work, but I think I might be misunderstanding (or over-thinking) something. I would assume it is bad practice to leave the Component Guid the same for a deliverable if that deliverable is updated between versions, however if a particular deliverable does *not* change, is it safe to leave its Component Guid alone? Thanks. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Best Practices - Using * for GUID automation
I am trying to determine the best approach to take with creating GUIDs for the various WiX elements. We use a full upgrade approach so I believe for the Product Id=* is okay. It probably goes without saying that setting Package Id=* makes sense in all cases. It is my understanding that the Upgrade Id should be static (never changes) for the life of a product installer, assuming the name of the MSI does not change. The one that I need some assistance with is at the Component level. We want to automate as much as we can, and having to update Component GUIDs for hundreds of deliverables is a pain. Is it safe to set Component Guid=*, or will this cause problems in the future? I worry that this will affect how upgrades work, but I think I might be misunderstanding (or over-thinking) something. I would assume it is bad practice to leave the Component Guid the same for a deliverable if that deliverable is updated between versions, however if a particular deliverable does *not* change, is it safe to leave its Component Guid alone? Thanks. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best Practices - Using * for GUID automation
Okay, it seemed like this approach would work, just wanted to verify. Thanks! On Tue, Jun 29, 2010 at 10:10 AM, Cherney John-CJC030 john.cher...@motorola.com wrote: I haven't had any problems with component ids set to *. We keep the Upgrade id constant but vary everything else, including the version and the MSI name (which contains the version). Because of the changing version and the constant upgrade id (and the PREVIOUSFOUND property getting set in the UpgradeVersion element), we are automatically uninstalling older versions as part of our install. Works very well. jwc -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Tuesday, June 29, 2010 7:35 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Best Practices - Using * for GUID automation I am trying to determine the best approach to take with creating GUIDs for the various WiX elements. We use a full upgrade approach so I believe for the Product Id=* is okay. It probably goes without saying that setting Package Id=* makes sense in all cases. It is my understanding that the Upgrade Id should be static (never changes) for the life of a product installer, assuming the name of the MSI does not change. The one that I need some assistance with is at the Component level. We want to automate as much as we can, and having to update Component GUIDs for hundreds of deliverables is a pain. Is it safe to set Component Guid=*, or will this cause problems in the future? I worry that this will affect how upgrades work, but I think I might be misunderstanding (or over-thinking) something. I would assume it is bad practice to leave the Component Guid the same for a deliverable if that deliverable is updated between versions, however if a particular deliverable does *not* change, is it safe to leave its Component Guid alone? Thanks. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best Practices - Using * for GUID automation
v1.0.0 of a particular product was shipped with hard coded GUIDs. So, if I change to * for version 1.0.1, I will have issues? On Tue, Jun 29, 2010 at 7:47 PM, Blair os...@live.com wrote: Using * for components should always be appropriate for all components that accept * for the Guid, as long as you have never shipped the component with a different GUID before. It won't cause problems with generating Patches. What will cause problems with generating patches is removing any component from any feature, renaming the keypath for any component (which, when using * for the Guid effectively removes the old component and adds a new one in its place), and changing either the directory for the component or any of that directories parents (at least as far as the closest well-known directory), for those components who's keypaths are files. Have you shipped your product before using guids that were not *? -Original Message- From: James Poole [mailto:w...@slowcommotion.com] Sent: Tuesday, June 29, 2010 11:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Best Practices - Using * for GUID automation Could someone chime in with a time when you wouldn't want to use * on component Guids? Would this cause issues with generating patches? -James On Tue, Jun 29, 2010 at 1:19 PM, Andy Clugston clug...@gmail.com wrote: Okay, it seemed like this approach would work, just wanted to verify. Thanks! On Tue, Jun 29, 2010 at 10:10 AM, Cherney John-CJC030 john.cher...@motorola.com wrote: I haven't had any problems with component ids set to *. We keep the Upgrade id constant but vary everything else, including the version and the MSI name (which contains the version). Because of the changing version and the constant upgrade id (and the PREVIOUSFOUND property getting set in the UpgradeVersion element), we are automatically uninstalling older versions as part of our install. Works very well. jwc -Original Message- From: Andy Clugston [mailto:clug...@gmail.com] Sent: Tuesday, June 29, 2010 7:35 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Best Practices - Using * for GUID automation I am trying to determine the best approach to take with creating GUIDs for the various WiX elements. We use a full upgrade approach so I believe for the Product Id=* is okay. It probably goes without saying that setting Package Id=* makes sense in all cases. It is my understanding that the Upgrade Id should be static (never changes) for the life of a product installer, assuming the name of the MSI does not change. The one that I need some assistance with is at the Component level. We want to automate as much as we can, and having to update Component GUIDs for hundreds of deliverables is a pain. Is it safe to set Component Guid=*, or will this cause problems in the future? I worry that this will affect how upgrades work, but I think I might be misunderstanding (or over-thinking) something. I would assume it is bad practice to leave the Component Guid the same for a deliverable if that deliverable is updated between versions, however if a particular deliverable does *not* change, is it safe to leave its Component Guid alone? Thanks. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users
[WiX-users] Using heat.exe with static Components
I am trying to work through some automation scenarios regarding heat and some file-dependent Components. Here is the scenario... I have a product that consists of a set of .exes and dlls. I would like to use heat.exe to automatically generate these deliverables for me at build time. It does this well, but there are a few issues that I need to overcome. One of the .exes needs to be installed as a service. Since the service .exe is always the same, I was wondering if there was a clever way to have a static .wxs define the ServiceInstall element for this .exe? For instance, can I simple create a Component with the File element without actually installing the .exe, but rather just reference the name of the .exe and path via Directory constructs? Similarly, I would like to do the same for a .dll that needs to be installed into the GAC. Have the actual .dll be harvested via heat, but have static additional configuration to the File element reside outside of the dynamically generated .wxs that heat creates. Thank you. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Converting Reg File(s) to WXS
I have found a few indications online that heat.exe does not support converting a .reg file to the WiX .wxs format. The suggestions I ran across show to use tallow.exe from WiX v2. Is it true that v3+ does not support this any longer? Also, the download for v2 is broken. Thanks. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Checking for Self install
At the moment I am trying to understand the conditional logic I posted. Right now, when I attempt to install the condition is evaluating to TRUE and causing the *first* install to fail. I am not understanding why it is evaluating this way. On Tue, Apr 20, 2010 at 2:02 AM, Sascha Beaumont sascha.beaum...@gmail.comwrote: So you want to prevent repair, uninstall and upgrades? Ugh. If the Product ID isn't changing, Windows Installer should bail automatically with Another version of this product is already installed from memory, if you're using an automatically generated Product ID you can use the fact that Windows Installer ignores fourth version field to detect when none of the first three have changed. See my post from last week for more info. Sascha On Tue, Apr 20, 2010 at 6:38 AM, Andy Clugston clug...@gmail.com wrote: I am attempting to determine if a specific version of a product is already installed on the system. I basically want to do this to disallow/bail out of an install if the MSI that is being executed is already installed on the system. Here is my authoring using 3.0 RTM. I must be missing something simple: Upgrade table. FWIW, Product and Upgrade GUID is not changing for each build; only GUID that is changing is the Package GUID. Language attribute matches as well. Upgrade Id='$(var.UpgradeCode)' UpgradeVersion Minimum='$(var.ProdVer)' IncludeMinimum='yes' Maximum='$(var.ProdVer)' IncludeMaximum='yes' OnlyDetect='yes' Language='1033' Property='SELFFOUND'/ /Upgrade Check to see if product previously installed *and* is this specific version. Condition Message=We be here!Installed AND SELFFOUND/Condition Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Checking for Self install
I am attempting to determine if a specific version of a product is already installed on the system. I basically want to do this to disallow/bail out of an install if the MSI that is being executed is already installed on the system. Here is my authoring using 3.0 RTM. I must be missing something simple: Upgrade table. FWIW, Product and Upgrade GUID is not changing for each build; only GUID that is changing is the Package GUID. Language attribute matches as well. Upgrade Id='$(var.UpgradeCode)' UpgradeVersion Minimum='$(var.ProdVer)' IncludeMinimum='yes' Maximum='$(var.ProdVer)' IncludeMaximum='yes' OnlyDetect='yes' Language='1033' Property='SELFFOUND'/ /Upgrade Check to see if product previously installed *and* is this specific version. Condition Message=We be here!Installed AND SELFFOUND/Condition Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Digital Signature to MSI
I am not 100% sure, but I doubt WiX has this built in. I use signtool.exe to sign the MSI after WiX is done with it. Works good, and is probably a little more flexible in the long run anyway. On Tue, Apr 13, 2010 at 12:03 PM, jeff00seattle jeff_tan...@earthlink.netwrote: Hi Curious, does WiX provide a way to add a digital signature to resulting MSI output? - Thanks Jeff in Seattle -- View this message in context: http://n2.nabble.com/Adding-Digital-Signature-to-MSI-tp4896947p4896947.html Sent from the wix-users mailing list archive at Nabble.com. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX cannot install certificate - Error 26352 installing certificate
Okay, great. I will get info up there today. Thanks. On Sat, Apr 10, 2010 at 8:58 AM, Bob Arnson b...@joyofsetup.com wrote: On 4/9/2010 8:06 AM, Andy Clugston wrote: You sure? Still looks closed. I hate bad Web apps. Open now. -- sig://boB http://joyofsetup.com/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX cannot install certificate - Error 26352 installing certificate
You sure? Still looks closed. Thanks. On Thu, Apr 8, 2010 at 5:13 PM, Bob Arnson b...@joyofsetup.com wrote: On 4/8/2010 9:55 AM, Andy Clugston wrote: Upgrading to the RTM (5419) did not help. Same issues. I reopened the old bug. Please attach sample authoring and a verbose log showing the problem. -- sig://boB http://joyofsetup.com/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX cannot install certificate - Error 26352 installing certificate
Upgrading to the RTM (5419) did not help. Same issues. Thank you. On Thu, Apr 8, 2010 at 8:44 AM, Bob Arnson b...@joyofsetup.com wrote: On 4/7/2010 7:49 AM, Andy Clugston wrote: WixIIsExtension.dll version: 3.0.5217.0 Try upgrading to WiX v3.0 RTM. -- sig://boB http://joyofsetup.com/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX cannot install certificate - Error 26352 installing certificate
One of our products is required to install three certificates. There is a possibility that one of our certificates may have already been pushed down to the end user system via IT. I have ran across an issue which appears to mimic the issue reported in the 2184946 tracker report. In our case, the store where the certificate lives is Certificates (Local Computer) - Trusted Root Certification Authorities - Enterprise. I have recreated the issue on an WinXP SP3 vPC by placing the root certificate in this store, and then attempting to install our product. If the certificate is not present ahead of time (removed before the MSI is executed, or never installed at all), our product installs just fine. FWIW, I have also created the original issue reported in 2184946 by placing the certificate in the Group Policy store. WixIIsExtension.dll version: 3.0.5217.0 WiX usage: Component Id =MyRootCert Guid=MyGUID iis:Certificate Id=MyRootCert_1 Name=Root Cert Request=no StoreLocation=localMachine StoreName=root Overwrite=yes BinaryKey=Root_Cert_1/ /Component Original tracker report: https://sourceforge.net/tracker/index.php?func=detailaid=2184946group_id=105970atid=642714 Thank you. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
