Re: [WiX-users] Unnecessary? reboot when repairing an install on Win XP
There should be something earlier in the log that says what's going on. The part of the log you posted is just info confirming it's going to do a reboot and use those files, not the actual reason it created them in the first place. If you search for -reboot- there may be something earlier than this. Phil W -Original Message- From: Don Walker [mailto:don.wal...@versaterm.com] Sent: Monday, June 25, 2012 1:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Unnecessary? reboot when repairing an install on Win XP I have a fairly simple test install built with WiX 3.6.3025.0. It does include the VC90CRTx86 merge module. On Windows 7 I can install and then immediately repair the install without being asked to reboot after the repair. On Windows XP I get asked to reboot after the repair. Here is the part of the log file that seems to indicate the problem: Action 16:39:58: RegisterProduct. Registering product Action 16:39:58: PublishFeatures. Publishing Product Features PublishFeatures: Feature: ProductFeature PublishFeatures: Feature: VC90CRTx86 Action 16:39:58: PublishProduct. Publishing product information 1: vtmlogo.ico Action 16:39:58: RollbackCleanup. Removing backup files RollbackCleanup: File: C:\Config.Msi\126b3b.rbf RollbackCleanup: File: C:\Config.Msi\126b3c.rbf RollbackCleanup: File: C:\Config.Msi\126b3d.rbf RollbackCleanup: File: C:\Config.Msi\126b3e.rbf RollbackCleanup: File: C:\Config.Msi\126b3f.rbf RollbackCleanup: File: C:\Config.Msi\126b40.rbf RollbackCleanup: File: C:\Config.Msi\126b41.rbf RollbackCleanup: File: C:\Config.Msi\126b42.rbf RollbackCleanup: File: C:\Config.Msi\126b43.rbf RollbackCleanup: File: C:\Config.Msi\126b44.rbf Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\126b44.rbf. Must reboot to complete operation. RollbackCleanup: File: C:\Config.Msi\126b45.rbf Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\126b45.rbf. Must reboot to complete operation. RollbackCleanup: File: C:\Config.Msi\126b46.rbf Action ended 16:39:58: InstallFinalize. Return value 1. Action ended 16:39:58: INSTALL. Return value 1. Is this a bug? Is there some way to fix the reboot prompt? -- 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 *** 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). -- 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] Scheduling Custom Action
You don't need a custom action. All you need is a registry item that has [Your property name] in it, and Windows Installer will do the rest. However. When a property is being passed from the UI sequence into the execute sequence it needs marking as secure so it goes into the SecureCustomProperties list. However, the problem you have is that your property is not public (it contains lower case characters) and only public properties can be passed from the UI to the execute sequence, so make it all uppercase. BUT don't call it USERNAME because that is an existing Windows Installer property. Phil W -Original Message- From: Ravi Raj [mailto:raviraj.callin...@gmail.com] Sent: Wednesday, June 20, 2012 11:12 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Scheduling Custom Action I am populating UserName property in UI textbox and then storing it in registry. For this I am using custom action to set this variable at UISqeuence and ExecuteSequence. Everything works great. I found that if I change this value to something else, my registry is never changes to new value. i saw that log then found that in UISequence its fine but in ExecuteSequence it changes back to normal. I need to fix this. I cannot remove the custom action from ExecuteSequence as if I do that then at the repair (with no UI just Right-Click - Repair) I found that, the registry value gets deleted (i am not sure why as verbose sows that value as empty). But having both CAs intact, it works great. Again, if I manually the registry value (just for testing), and do repair using Maintenance dialog, the registry value resets to the original (default) value. I am totally lost how to resolve this? Requirement is to populate username (from computer), in a textbox, store it in registry and keep it there until uninstall. How do I use CAs sequencing or where should I call repair so that nothing gets changed? -- Thanks and Regards, Ravi Raj -- 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 *** 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). -- 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] custom action dll not getting called, debugging advice
Sometimes these are dependency issues, C runtime support etc. Dependency Walker is a useful tool to deal with those issues. Phil W -Original Message- From: Joe Damato [mailto:j...@boundary.com] Sent: Thursday, June 21, 2012 12:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] custom action dll not getting called, debugging advice thanks everyone for the replies. i've changed: CustomAction Id=CheckingSecurityToken BinaryKey=libprovisionmeter DllEntry=provision_meter_msi/ to: CustomAction Id=CheckingSecurityToken BinaryKey=libprovisionmeter DllEntry=provision_meter_msi Execute=firstSequence/ and i left my InstallExecuteSequence sequence intact and now the logfile output from the MSI shows that the MSI is attempting to call into my DLL during both UI and non-UI installs. i have now been trying to decipher this error message: MSI (s) (C4:28) [12:26:21:886]: Product: bProbe Package -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CheckingSecurityToken, entry: provision_meter_msi, library: C:\Windows\Installer\MSIF7C7.tmp i'm running the MSI on a windows 7 machine, but my dll (written in pure C) is a 32bit binary. maybe i need to pass some sort of switch to WiX to get it generate a 32bit friendly MSI? On Tue, Jun 19, 2012 at 2:13 PM, Rob Mensching r...@robmensching.com wrote: I also like to add an AssertSz(FALSE, Debug here); from the wcautil.h. That pops up a dialog box with all the information what process to attach to (since there will be multiple msiexec's). If the assert doesn't fire, then I know the problem is with the CustomAction scheduling. Of course, remembering to take out the Assert FALSE is important too. Wish I could say I never forget to do that. smile/ On Tue, Jun 19, 2012 at 11:28 AM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: This really smells like 71 CustomAction Id=CheckingSecurityToken BinaryKey=libprovisionmeter DllEntry=provision_meter_msi / Is actually CustomAction Id=CheckingSecurityToken BinaryKey=libprovisionmeter DllEntry=provision_meter_msi Execute=firstSequence / In non UI installs, only the InstallExecute sequence runs. In full blown installs, both sequences run. To debug the calling of the custom action, I would recommend looking at your MSI with a tool like Orca or instead to see the actual sequence. From there you can look at the actions happening in your log file right before or after you expect your custom action to be called. Another thing to do would be to introduce logging via the MSI API's inside your custom action for the beginning and ending points. Jacob -Original Message- From: Joe Damato [mailto:j...@boundary.com] Sent: Tuesday, June 19, 2012 1:13 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] custom action dll not getting called, debugging advice hi - this morning i tried installing my msi without using a full UI and noticed that the logfile output by the installer shows the dll getting hit. it seems that InstallExecuteSequence (or the way i am using it) only happens during non-UI installs. i am currently reading docs about InstallUISequence to understand how to fix this when users do a UI install. is there an example somewhere in the docs incorporating both InstallExecuteSequence and InstallUISequence? joe On Mon, Jun 18, 2012 at 3:26 PM, Joe Damato j...@boundary.com wrote: hi - i've written a dll which hits a REST api that my app needs to hit to register its existence with the server, but for some reason or another it seems that my dll is not being hit. i've built a simple exe that links against the dll and that exe works, so i know my dll works at least when linked against by something other than my MSI. my custom dialog is rendering correctly, however when i enter some text into the edit field and click Next, i immediately get a The key is not valid. Verify that you entered the correct key. message that i assume is some sort of built in message (?). i tried to follow along with the SampleCA example ( http://wix.tramontana.co.hu/system/files/samples/SampleCA.zip) and here's the relevant snippets from my files (i've pasted the full contents of the files here: https://gist.github.com/f9388332734cca9eb722 ): 59 Binary Id=libprovisionmeter SourceFile=libprovisionmeter.dll / 60 61 UI Id=MyWixUI_InstallDir 62 UIRef Id=WixUI_InstallDir/ 63 DialogRef Id=SecurityTokenDlg/ 64 Publish Dialog=LicenseAgreementDlg Control=Next Event=NewDialog Value=SecurityTokenDlg Order=2LicenseAccepted = 1/Publish 65 Publish Dialog=WelcomeDlg Control=Back Event=NewDialog
Re: [WiX-users] Continue logging after a force reboot during the install
It's just a property - use it as a condition on anything you don't want to repeat, such as NOT AFTERREBOOT. -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Tuesday, June 19, 2012 9:38 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Continue logging after a force reboot during the install Sorry Bob, can you give me an example of using the AFTERREBOOT property and how to skip to the last position before reboot? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Continue-logging-after-a-force-reboot-during-the-install-tp7578946p7578954.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- 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] Continue logging after a force reboot during the install ()RESUME)
RESUME appears to be the special case that the system rebooted during the installation. http://blogs.msdn.com/b/windows_installer_team/archive/2005/09/19/470980.aspx Phil W -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Wednesday, June 20, 2012 8:49 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Continue logging after a force reboot during the install Also, how is the RESUME property used/related to AFTERREBOOT proptery? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Continue-logging-after-a-force-reboot-during-the-install-tp7578946p7578971.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- 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] PATCH in Wix
OLD_VERSION_FOUND is not standard property, so my guess is that it's set via a search or the Upgrade table in the new MSI that you are installing. UPGRADINGPRODUCTCODE is set in an uninstall when it is being upgraded by a new product. Phil W -Original Message- From: Ravi Raj [mailto:raviraj.callin...@gmail.com] Sent: Tuesday, June 19, 2012 2:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] PATCH in Wix I was trying to use UPGRADINGPRODUCTCODE but none of the features are not working so I decided to go with OLD_VERSION_FOUND and things are going pretty smooth. But will it be nice. I am not sure why former was nor working? On Tue, Jun 19, 2012 at 2:35 PM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: There is a complete list of properties at http://msdn.microsoft.com/en-us/library/windows/desktop/aa370905%28v=v s.85%29 .aspx UPGRADINGPRODUCTCODE is probably what you're after. -Original Message- From: Ravi Raj [mailto:raviraj.callin...@gmail.com] Sent: 19 June 2012 06:10 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] PATCH in Wix I just wanted to ask that what PATCH keyword means? Upgrade or Patch? What condition I choose if I want to display upgrade UI on upgrade as most of the places I have seen: Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=LicenseAgreementDlgNOT Installed AND NOT PATCH/Publish Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=VerifyReadyDlgInstalled AND PATCH/Publish What should I use in case of Upgrade (there is no patch in my case)? -- Thanks and Regards, Ravi Raj -- --- - 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 -- Thanks and Regards, Ravi Raj -- 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 *** 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).
Re: [WiX-users] Detecting upgrades UPGRADINGPRODUCTCODE
UPGRADINGPRODUCTCODE is set in the product being *uninstalled*, the target of the RemoveExistingProducts, not in your code that is calling it. If you want to have a dialog because your setup has detected that it is upgrading an older existing product, then base that dialog on the property being set in your Upgrade, usually a name you invent like FOUNDPREVIOUSVERSIONS. If you want your uninstall code to do something special when it's being upgraded (as opposed to being just installed) then that older outgoing product can condition it on UPGRADINGPRODUCTCODE. Phil W -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Tuesday, June 19, 2012 2:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Detecting upgrades UPGRADINGPRODUCTCODE Hello, I was reading the property reference http://msdn.microsoft.com/en-us/library/windows/desktop/aa370905%28v=vs.85%29 page for UPGRADINGPRODUCTCODE and it says UPGRADINGPRODUCTCODE is set when RemoveExistingProducts is executed. How can I base my dialogs then, if RemoveExistingProducts is executed late in the game? Example I want a specific dialog displayed based on UPGRADINGPRODUCTCODE. So if RemoveExistingProducts is executed after InstallExecute, the dialog stage has past then. Is there something else I can condition the dialog on? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detecting-upgrades-UPGRADINGPRODUCTCODE-tp7578945.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- 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] Deleting user.config after uninstall?
There's this, not official but useful... http://blogs.msdn.com/b/oldnewthing/archive/2007/09/17/4948130.aspx Phil W From: Jerra [beddel...@gmail.com] Sent: Tuesday, June 12, 2012 12:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deleting user.config after uninstall? OK thanks! Well installation is sort of a gigantic big black hole I am trying to understand. Luckily there is a lot of info on the web regarding WiX and this mailing list. MS guidelines, I haven't seen any of those though.. System preferences... Now that's a different beast :) I do not understand this remark. /Jerra On 12.6.2012 10:14, Sascha Beaumont wrote: Refer the ms guidelines, user data should remain after uninstall. So leaving a trail that is expected. System preferences... Now that's a different beast :) Cheers, Sascha On 11/06/2012, at 11:52 PM, Jerrabeddel...@gmail.com wrote: In my application I use the built in functionality for storing user settings (Settings.Default.xyz) which generates a user.config file. I am leaving a trail of these old user.config files. How on earth do I remove these using WiX. I can't hardcode (RemoveFile) the location as it is unknown at installation where they will be stored. Attaching a screendump of my garbage. I guess some kind of recursive search in [user]\AppData\Local and deleting all my application files would be quite reckless. Any help greatly appreciated, Jerra -- Visual Studio 2010 Professional WiX 3.5 Programming in C# /.NET 4.0 -- 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 -- Visual Studio 2010 Professional WiX 3.5 Programming in C# /.NET 4.0 -- 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 *** 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). -- 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
Re: [WiX-users] Installer ignores cancellation
This describes how to do it, but I don't know how (or if) it shows up an MSI log: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371614(v=vs.85).aspx and scroll down to INSTALLMESSAGE_COMMONDATA. -Original Message- From: Rob Hamflett [mailto:rob_hamfl...@sn.scee.net] Sent: Monday, June 11, 2012 12:34 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installer ignores cancellation Hi Rob, On 08/06/2012 16:25, Rob Mensching wrote: Custom actions can swallow the cancel message. If you look at the WiX toolset's custom actions, we have wrappers for most of the MSI APIs and in those wrappers, special handling ifa cancel is sent back. If you have an install with custom actions where the cancel button is being lost, this is often the issue. Thanks, I'll download the source and poke around. The other issue is the Windows Installer may have sent the Disable Cancel button message already. Clicking cancel after that point, of course, has no effect. Is there any documented info about this? Is there anything I can look up on MSDN or search for in the log? Thanks, Rob On Fri, Jun 8, 2012 at 6:39 AM, Rob Hamflettrob_hamfl...@sn.scee.netwrote: I'm seeing a strange issue where it looks like I can't cancel an installation during the last action before InstallFinalize in the InstallExecuteSequence. I have two deferred custom actions for updating VS 2008 and 2010 (running devenv /setup /nosetupvstemplates) and they are scheduled immediately before InstallFinalize. When I see the progress text for the 2008 action I cancel the installation. The 2008 action takes some time to run so the installer continues to show this text for a bit until it eventually rolls back and aborts the installation. If I do the same thing during the 2010 setup, (which comes after the 2008 action and is the last thing before InstallFinalize) then the cancel dialog still shows as normal, but this time the installer will run to completion. I re-ran the installer and opted not to install the 2010 support, so the 2010 action won't run. This time when I cancel during the 2008 action, the installer waits for the 2008 action to complete but this time the installation completes instead of rolling back. Does anyone have any insight into what's going on? Thanks, Rob - - 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 *** 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). -- 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.
Re: [WiX-users] Scheduling Install and Uninstall Custom Actions
It's in the Windows SDK: http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa368561(v=vs.85).aspx Phil W -Original Message- From: Ravi Raj [mailto:raviraj.callin...@gmail.com] Sent: Thursday, June 07, 2012 8:06 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Scheduling Install and Uninstall Custom Actions Well Phil, I got the idea but I am not sure on which component I use this condition. For basic msi I saw that it used component id of DLL which has installer.cs file but in my case I do not have this file at all. Also if you guide me the way how to use this component condition for install, uninstall, repair and upgrade that will be more helpful (some code will also be great as I am totally new to WiX). :) On Thu, Jun 7, 2012 at 10:04 PM, Wilson, Phil phil.wil...@invensys.comwrote: Component or feature conditions work much better in circumstances like this, a couple of examples that are by no means a complete list. 1. Something breaks in your product that running the custom action would correct. You would ask the customer to go to Add/Remove ProgramsFeatures and use Repair to fix it. The component reinstall would run the custom action and fix it. You don't have that option. 2. The custom action is associated with a feature (or a component) that may or may not be installed depending on the features that are chosen. If that feature or component is not being installed, running the CA is pointless. The same is true if that feature is uninstalled. Phil W -Original Message- From: Ravi Raj [mailto:raviraj.callin...@gmail.com] Sent: Thursday, June 07, 2012 1:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Scheduling Install and Uninstall Custom Actions I found a way by opening (via orca) my previous installer (made by Visual Studio 2010 basic msi). All the custom actions are using component conditions. I am not at all comfortable in this. So I am modified my current installer with following CAs. Its working great. Custom Action=CA_SetBase_Install Before=CA_InstallNOT Installed/Custom Custom Action=CA_Install After=StartServicesNOT Installed AND NOT UPGRADINGPRODUCTCODE/Custom Custom Action=CA_SetBase_UnInstall Before=CA_UnInstallInstalled/Custom Custom Action=CA_UnInstall After=MsiUnpublishAssembliesInstalled/Custom The CAs are working as desired. I want to ask about what is the diff between this approach and with component approach? Also If I want to use rollback custom action then how to use it? Should Rollback be after StartServices and then Install CAs (coz this is how orca showed me, first rollback followed by install CA)? On Thu, Jun 7, 2012 at 12:41 PM, Rob Hamflett rob_hamfl...@sn.scee.net wrote: Are these actions specified as being deferred, so they actually run as part of the installation script? Rob On 05/06/2012 13:52, Ravi Raj wrote: I want to schedule my custom actions in following manner: 1) Install: CA will run *only after* the installer copies all files to the respective directories. 2) Uninstall: custom action has completed successfully and then installer removes the files from the system. How should I write my custom action? I am using: Custom Action=CA_SetCustomActionData_Install Before=CA_GetCustomActionData_InstallNOT Installed/CustomCustom Action=CA_GetCustomActionData_Install After=InstallInitializeNOT Installed AND NOT UPGRADINGPRODUCTCODE/Custom Custom Action=CA_SetCustomActionData_UnInstall Before=CA_GetCustomActionData_UnInstallInstalled/CustomCusto m Action=CA_GetCustomActionData_UnInstall Before=InstallFinializeInstalled/Custom But this is not working. -- 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 -- Thanks and Regards, Ravi Raj -- 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
Re: [WiX-users] Scheduling Install and Uninstall Custom Actions
Component or feature conditions work much better in circumstances like this, a couple of examples that are by no means a complete list. 1. Something breaks in your product that running the custom action would correct. You would ask the customer to go to Add/Remove ProgramsFeatures and use Repair to fix it. The component reinstall would run the custom action and fix it. You don't have that option. 2. The custom action is associated with a feature (or a component) that may or may not be installed depending on the features that are chosen. If that feature or component is not being installed, running the CA is pointless. The same is true if that feature is uninstalled. Phil W -Original Message- From: Ravi Raj [mailto:raviraj.callin...@gmail.com] Sent: Thursday, June 07, 2012 1:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Scheduling Install and Uninstall Custom Actions I found a way by opening (via orca) my previous installer (made by Visual Studio 2010 basic msi). All the custom actions are using component conditions. I am not at all comfortable in this. So I am modified my current installer with following CAs. Its working great. Custom Action=CA_SetBase_Install Before=CA_InstallNOT Installed/Custom Custom Action=CA_Install After=StartServicesNOT Installed AND NOT UPGRADINGPRODUCTCODE/Custom Custom Action=CA_SetBase_UnInstall Before=CA_UnInstallInstalled/Custom Custom Action=CA_UnInstall After=MsiUnpublishAssembliesInstalled/Custom The CAs are working as desired. I want to ask about what is the diff between this approach and with component approach? Also If I want to use rollback custom action then how to use it? Should Rollback be after StartServices and then Install CAs (coz this is how orca showed me, first rollback followed by install CA)? On Thu, Jun 7, 2012 at 12:41 PM, Rob Hamflett rob_hamfl...@sn.scee.netwrote: Are these actions specified as being deferred, so they actually run as part of the installation script? Rob On 05/06/2012 13:52, Ravi Raj wrote: I want to schedule my custom actions in following manner: 1) Install: CA will run *only after* the installer copies all files to the respective directories. 2) Uninstall: custom action has completed successfully and then installer removes the files from the system. How should I write my custom action? I am using: Custom Action=CA_SetCustomActionData_Install Before=CA_GetCustomActionData_InstallNOT Installed/CustomCustom Action=CA_GetCustomActionData_Install After=InstallInitializeNOT Installed AND NOT UPGRADINGPRODUCTCODE/Custom Custom Action=CA_SetCustomActionData_UnInstall Before=CA_GetCustomActionData_UnInstallInstalled/CustomCustom Action=CA_GetCustomActionData_UnInstall Before=InstallFinializeInstalled/Custom But this is not working. -- 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 -- Thanks and Regards, Ravi Raj -- 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 *** 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
Re: [WiX-users] MSI Uninstall throw exception
Most likely your code is crashing, the custom action, if the subject line is
the issue. That part of the log would have been more useful. that something
about Win64. My guess is that you have an uninstall custom action which assumes
that the properties you are using (SERVERNAME, DATABASENAME) are preserved
somewhere. They are not. It might be that you don't want to run that custom
action at uninstall time, if so you need a condition on the custom action,
perhaps something like Not Installed, so it runs only at install time.
Phil W
From: Rajeshkannan Krishnamoorthy [rajeshkannan.kr...@gmail.com]
Sent: Tuesday, May 29, 2012 11:45 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] MSI Uninstall throw exception
Hi,
I am new to Wix. I have created MSI for DB deployment.
I can able to run and install the DB in DB server. But when i want to
uninstall the MSI from Add/Remove programs, its not uninstalling. Then I
check the log file
it shows like
MSI (s) (D0:30) [11:57:42:286]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files
(x86)\MyDatabase\Tenix.Nova.Database_Database.sqldeployment' folder had
been blocked by the 1 mask argument (the folder pair's iSwapAttrib member =
0).
MSI (s) (D0:30) [11:57:42:287]: Allowing uninstallation of shared
component: {45A30C59-37F5-4096-A937-92CA66D8F8F4}. Other clients exist, but
installed to a different location
I dont know where is the problem. Can some one help me to find the solution.
Thanks for help.
My code details
CustomAction Id=LaunchNova
Property=NovaSchema
Value=quot;[#vsdbcmd.exe]quot; /a:Deploy
/cs:quot;Server=[SERVERNAME];Integrated Security=true;quot; /dsp:Sql /dd+
/manifest:quot;[#Database1.deploymanifest]quot;
/p:DeployDatabaseProperties=False /p:AlwaysCreateNewDatabase=False
/p:TargetDatabase=quot;[DATABASENAME]quot;
Execute=immediate/
!--Define the custom action to execute vsdbcmd.exe--
CustomAction Id=NovaSchema BinaryKey=WixCA DllEntry=CAQuietExec
Execute=deferred Return=check Impersonate=yes/
CustomAction Id=LaunchRBAC
Property=RBACSchema
Value=quot;[#vsdbcmd.exe]quot; /a:Deploy
/cs:quot;Server=[SERVERNAME];Integrated Security=true;quot; /dsp:Sql /dd+
/script:tenix.nova.Database.RBAC.sql /P:PerformDatabaseBackup=True
/p:DeployDatabaseProperties=False /p:AlwaysCreateNewDatabase=False
/Model:quot;[#Database2.dbschema]quot;
/manifest:quot;[#Database1.deploymanifest]quot;
/p:TargetDatabase=quot;[DATABASENAME]quot;
Execute=immediate/
CustomAction Id=RBACSchema BinaryKey=WixCA DllEntry=CAQuietExec
Execute=deferred Return=check Impersonate=yes/
CustomAction Id=LaunchWorkflow
Property=WorkflowSchema
Value=quot;[#vsdbcmd.exe]quot; /a:Deploy
/cs:quot;Server=[SERVERNAME];Integrated Security=true;quot; /dsp:Sql /dd+
/script:tenix.nova.Database.Workflow.sql /p:DeployDatabaseProperties=False
/p:AlwaysCreateNewDatabase=False /Model:quot;[#Database4.dbschema]quot;
/manifest:quot;[#Database1.deploymanifest]quot;
/p:TargetDatabase=quot;[DATABASENAME]quot;
Execute=immediate/
CustomAction Id=WorkflowSchema BinaryKey=WixCA
DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=yes/
CustomAction Id=LaunchGCI
Property=GCISchema
Value=quot;[#vsdbcmd.exe]quot; /a:Deploy
/cs:quot;Server=[SERVERNAME];Integrated Security=true;quot; /dsp:Sql /dd+
/script:tenix.nova.Database.GCI.sql /p:DeployDatabaseProperties=False
/p:AlwaysCreateNewDatabase=False /Model:quot;[#Database1.dbschema]quot;
/manifest:quot;[#Database1.deploymanifest]quot;
/p:TargetDatabase=quot;[DATABASENAME]quot;
Execute=immediate/
CustomAction Id=GCISchema BinaryKey=WixCA DllEntry=CAQuietExec
Execute=deferred Return=check Impersonate=yes/
CustomAction Id=LaunchBatch
Property=BatchSchema
Value=quot;[#vsdbcmd.exe]quot; /a:Deploy
/cs:quot;Server=[SERVERNAME];Integrated Security=true;quot; /dsp:Sql /dd+
/script:tenix.nova.Database.Batch.sql /p:DeployDatabaseProperties=False
/p:AlwaysCreateNewDatabase=False /Model:quot;[#Database3.dbschema]quot;
/manifest:quot;[#Database1.deploymanifest]quot;
/p:TargetDatabase=quot;[DATABASENAME]quot;
Execute=immediate/
CustomAction Id=BatchSchema BinaryKey=WixCA DllEntry=CAQuietExec
Execute=deferred Return=check Impersonate=yes/
CustomAction Id=SetUpgrading Property=Upgrading Value=true/
CustomAction Id=PreventDowngrading Error=Newer version already
installed. /
!--Define when the two custom actions will be executed--
InstallExecuteSequence
Custom Action=LaunchRBAC Before=InstallFiles/
Custom Action=RBACSchema After=InstallFiles/
Custom Action=LaunchWorkflow Before=InstallFiles/
Custom Action=WorkflowSchema After=RBACSchema/
Custom Action=LaunchGCI Before=InstallFiles/
Custom Action=GCISchema After=WorkflowSchema/
Custom
Re: [WiX-users] Message Box at the top of Installer Dialog
Those DTF managed custom actions tree up to call MsiProcessMessage(), so you're
restricted to the functionality of MsiProcessMessage. I assume that if the
IntelliSense in the dev environment doesn't offer what you want then you can't
do it.
Phil W
-Original Message-
From: Ravi Raj [mailto:raviraj.callin...@gmail.com]
Sent: Tuesday, May 29, 2012 8:59 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Message Box at the top of Installer Dialog
I got one method and its *working fine*:
*session.Message(
InstallMessage.Error |
(InstallMessage)(MessageBoxIcon.Error) |
(InstallMessage)MessageBoxButtons.OK,
new Record { FormatString = Some custom message });*
Can you suggest me if I can override its fields say instead
InstallMessage.Error I want to use something else coz I tried this and my
installer ended per-maturely. Also I want to change its Title message which is
Installer Information. I want to use some custom title message.
On Wed, May 30, 2012 at 8:33 AM, Ravi Raj raviraj.callin...@gmail.comwrote:
Is there anything related to C# as I am C# developer and not very
accustomed to C++.
On Wed, May 30, 2012 at 1:36 AM, Wilson, Phil phil.wil...@invensys.comwrote:
MsiProcessMessage might be what you should be using, with
INSTALLMESSAGE_USER.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370354(v=vs
.85).aspx
Phil W
-Original Message-
From: Ravi Raj [mailto:raviraj.callin...@gmail.com]
Sent: Monday, May 28, 2012 2:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Message Box at the top of Installer Dialog
I am trying to populate some information to the user via Message Box
in custom action (deferred). But everytime my message box goes to the
back of the dialog and I have to manually click at the taskbar to see
the information.
How can I make these at the top of the installer??
--
Thanks and Regards,
Ravi Raj
-
-
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
*** 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).
-
-
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
--
Thanks and Regards,
Ravi Raj
--
Thanks and Regards,
Ravi Raj
--
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
*** Confidentiality
Re: [WiX-users] Message Box at the top of Installer Dialog
MsiProcessMessage might be what you should be using, with INSTALLMESSAGE_USER. http://msdn.microsoft.com/en-us/library/windows/desktop/aa370354(v=vs.85).aspx Phil W -Original Message- From: Ravi Raj [mailto:raviraj.callin...@gmail.com] Sent: Monday, May 28, 2012 2:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Message Box at the top of Installer Dialog I am trying to populate some information to the user via Message Box in custom action (deferred). But everytime my message box goes to the back of the dialog and I have to manually click at the taskbar to see the information. How can I make these at the top of the installer?? -- Thanks and Regards, Ravi Raj -- 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 *** 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). -- 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] WIX regsvr32 with XP
Those top two are Visual C++ 2010 C runtime support Dlls, typically supplied with this type of thing: http://www.microsoft.com/en-us/download/details.aspx?id= or with merge modules that came with Visual Studio 2010. You'll probably need a minimum of XP SP3 (see the link, system requirements). Phil W -Original Message- From: Jelani Jackson [mailto:jeljac...@gmail.com] Sent: Thursday, May 24, 2012 7:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WIX regsvr32 with XP There are 3 files the that give an error opening a file they are: MSVCP100.DLL MSVCR100.DLL MSJAVA.DLL On Thu, May 24, 2012 at 9:56 AM, Jelani Jackson jeljac...@gmail.com wrote: I opened the dll with dependency walker and this is the error that I received Error: At least one required implicit or forwarded dependency was not found. Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module. On Thu, May 24, 2012 at 9:15 AM, Pally Sandher pally.sand...@iesve.comwrote: Sounds like either as Rob says an API call which doesn't exist on XP or a missing dependency (essentially the same thing). Open your DLL in dependency walker on XP see what it says. Once you get it registering manually, use heat to register it the proper way in your MSI. 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: Jelani Jackson [mailto:jeljac...@gmail.com] Sent: 24 May 2012 13:01 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WIX regsvr32 with XP Yes I have, when I run regsvr32 on XP I get LoadLibrary(the dll I'm using) failed - The specified module could not be found On Thu, May 24, 2012 at 3:18 AM, Rob Hamflett rob_hamfl...@sn.scee.net wrote: Have you tried running regsvr32 on the DLL directly on an XP machine? I've seen issues with DLLs where the developer is using a Windows 7 machine and has unknowingly used an API call that's just not available on XP. - - 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 *** 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,
Re: [WiX-users] WIX: COM registration does not work with UAC
It might actually be working for per-user... A genuine per-user COM registration will be in HKCU for the installing user - it won't be exposed to the entire system. In what sense is it not working? Phil W -Original Message- From: vasjko [mailto:vas...@ua.fm] Sent: Wednesday, May 23, 2012 11:19 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WIX: COM registration does not work with UAC Thanks for correct question Pally, tried per-machine MSI version and it works fine. Do you know how to make it works for per-user installation? Thanks 23.05.2012 19:07, Pally Sandher pally.sand...@iesve.com Is your MSI per-machine or per-user? 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: vasjko [mailto:vas...@ua.fm] Sent: 23 May 2012 17:02 To: wix-users@lists.sourceforge.net Subject: [WiX-users] WIX: COM registration does not work with UAC Hello All, I'm using Heat.exe to get registration information for my libraries and include this info in my Wix code. The registration works fine on machines when UAC is off, but it doesn't work on machines where UAC is on. This happens even if I run my msi as administrator(from bootstrapper or cmd) Does anyone have an idea why does it happen? Thanks in advance, Vasyl -- реклама --- Хостинг с доменом от 9.8 грн в месяц http://freehost.ua -- 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 -- реклама --- Хостинг с доменом от 9.8 грн в месяц http://freehost.ua -- 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 *** 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). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT
Re: [WiX-users] WIX regsvr32 with XP
WiX has a tool for extracting COM information, it's harvested using heat.exe. Even if you wanted to have the Dll self-register you don't need to do that by running regsvr32 because Windows Installer has a SelfReg table, just get your Dll in there. Developers often think that installs work using the same tools as used during development. You don't need regsv32 to do registration (or regasm), you don't install assemblies in the GAC with GacUtil, and you don't need InstallUtil to install services etc. Phil W -Original Message- From: Jelani Jackson [mailto:jeljac...@gmail.com] Sent: Wednesday, May 23, 2012 11:28 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WIX regsvr32 with XP Hello all I am currently working on an installer which works for Windows Vista and Windows 7. When it comes to Windows XP on the other hand I receive the error code 1722. I logged the installation process and found that the error occurred when the command regsvr32 is ran for a particular dll (the only time regsvr32 is actually called). Any insight would be a great help. -- 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 *** 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). -- 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] WIX regsvr32 with XP
Regsvr32 didn't work, that's the point. Maybe it couldn't find your file. :
C:\Program Files\[Product Information]\, looks wrong to me, because [ ] implies
a Windows Installer property, but not with that space in the middle.
The point of the tools like heat is that you don't need to run code at install
time - it's the weakest link. Extract it all with heat and you don't need to
run anything else.
Phil W
-Original Message-
From: Jelani Jackson [mailto:jeljac...@gmail.com]
Sent: Wednesday, May 23, 2012 1:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WIX regsvr32 with XP
Thank you for the feedback. I'm not necessarily certain how to go about doing
that since I am developing the wix installer with visual studio. Also here is
the error that I am getting
Event Type: Error
Event Source: MsiInstaller
Event Category: None
Event ID: 11722
Date: 5/23/2012
Time: 4:17:12 PM
User: VIRTUALXP-52160\XPMUser
Computer: VIRTUALXP-52160
Description:
Product: [Product] -- Error 1722. There is a problem with this Windows
Installer package. A program run as part of the setup did not finish as
expected. Contact your support personnel or package vendor. Action
RegisterPlugin, location: C:\Program Files\[Product Information]\, command:
regsvr32.exe /s C:\Program Files\[Product Information].dll
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
: 7b 36 46 30 44 39 41 38 {6F0D9A8
0008: 41 2d 34 39 37 34 2d 34 A-4974-4
0010: 30 37 41 2d 42 34 42 33 07A-B4B3
0018: 2d 37 31 31 32 37 43 39 -71127C9
0020: 46 46 34 38 30 7d FF480}
On Wed, May 23, 2012 at 3:02 PM, Wilson, Phil phil.wil...@invensys.comwrote:
WiX has a tool for extracting COM information, it's harvested using
heat.exe. Even if you wanted to have the Dll self-register you don't
need to do that by running regsvr32 because Windows Installer has a
SelfReg table, just get your Dll in there.
Developers often think that installs work using the same tools as used
during development. You don't need regsv32 to do registration (or
regasm), you don't install assemblies in the GAC with GacUtil, and you
don't need InstallUtil to install services etc.
Phil W
-Original Message-
From: Jelani Jackson [mailto:jeljac...@gmail.com]
Sent: Wednesday, May 23, 2012 11:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WIX regsvr32 with XP
Hello all I am currently working on an installer which works for
Windows Vista and Windows 7. When it comes to Windows XP on the other
hand I receive the error code 1722. I logged the installation process
and found that the error occurred when the command regsvr32 is ran for
a particular dll (the only time regsvr32 is actually called). Any
insight would be a great help.
--
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
*** 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).
--
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
Re: [WiX-users] light.exe error when merging VC100 merge modules for both x86 and x64
Just to add the doc link: http://msdn.microsoft.com/en-us/library/windows/desktop/aa367451(v=vs.85).aspx Phil W From: Bob Arnson [b...@joyofsetup.com] Sent: Friday, May 18, 2012 9:13 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] light.exe error when merging VC100 merge modules for both x86 and x64 On 18-May-12 11:32, Gareth wrote: But you can install 64-bit dlls withoin a 32-bit package - they're just files. Not if they're marked as a 64-bit component that goes into a 64-bit part of the file system. Then they're special. then how can a 64-bit operating system interogate a bespoke file format in order to draw a thumbnail preview when it is installed as part of a 32-bit package? It can't. That requires a 64-bit package, as I said. The rules are that a 32-bit package can contain only 32-bit components but a 64-bit package can contain both 64-bit and 32-bit components. -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- 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] OnExecuteProgress WS03: progress values go back to 95 from 100
That's probably normal. I don't know the actual implementation, but assuming it's based on MsiProcessMessage and INSTALLMESSAGE_PROGRESS the documentation says that progress can go backwards. There's probably a joke somewhere in there... Phil W -Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: Thursday, May 17, 2012 2:28 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] OnExecuteProgress WS03: progress values go back to 95 from 100 I noticed that on Windows Server 2003 (Windows Installer 3.1) the progress values in OnExecuteProgress can go down - they reach 100 and then go back to 95 and work their way back up to 100. -- Bruce Cran -- 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 *** 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). -- 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] The feature-action state value not correct after CostFinalize stage in Wix 3.6
In cases where the user chooses features from a dialog, that dialog is after CostFinalize in the MSI files I've looked at, so feature-action is unknown. Maybe it's correct after CostFinalize if you've specified features in advance on the command line, but I don't know if that's what you're doing. Phil W -Original Message- From: tzleon [mailto:tzl...@gmail.com] Sent: Tuesday, May 15, 2012 2:56 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The feature-action state value not correct after CostFinalize stage in Wix 3.6 Accroding to the msdn spec http://msdn.microsoft.com/en-us/library/aa368012.aspx, I could get feature-action value after CostFinalize stage, but in Wix 3.6 I tried to add MyFeature value to condition as below: SetProperty Id=WIXUI_EXITDIALOGOPTIONALCHECKBOX Value=1 After=CostFinalize/SetProperty It seems the feature-action value is always -1, so does anyone can give me a suggestion? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-feature-action-state-value-not-correct-after-CostFinalize-stage-in-Wix-3-6-tp7559587.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- 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] Does wix support calling bcdedit?
Windows Installer folder properties include a backslash. Try: '[System64Folder]bcdedit.exe Phil W -Original Message- From: Vincent Wong [mailto:victorhwhis...@yahoo.com] Sent: Friday, May 11, 2012 1:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does wix support calling bcdedit? Sorry, Here's the CA codes and I'm running elevated as perMachine install CustomAction Id=SetInstallCmd_Cmd Property=SetInstallCmd Value='[System64Folder]\bcdedit.exe /set testsigning on' / CustomAction Id=SetInstallCmd BinaryKey=WixCA DllEntry=CAQuietExec Return=ignore Execute=deferred Impersonate=no/ --- On Fri, 5/11/12, victorwhiskey victorhwhis...@yahoo.com wrote: From: victorwhiskey victorhwhis...@yahoo.com Subject: [WiX-users] Does wix support calling bcdedit? To: wix-users@lists.sourceforge.net Date: Friday, May 11, 2012, 8:07 PM Hi, I'm trying to call bcdedit from a deferred custom action to set the machine in test mode. I'm trying to install unsigned drivers at the moment so I want to put the machine in test mode with the command bcdedit /set testsigning on. I'm calling CAQuietExec byt I'm getting Error 0x80070002 These are snips of my log: MSI (s) (B8:74) [11:25:49:046]: Note: 1: 2205 2: 3: PatchPackage Action ended 11:25:49: InstallFiles. Return value 1. MSI (s) (B8:74) [11:25:49:046]: Doing action: SetInstallCmd_Cmd Action start 11:25:49: SetInstallCmd_Cmd. MSI (s) (B8:74) [11:25:49:046]: PROPERTY CHANGE: Adding SetInstallCmd property. Its value is 'C:\Windows\system32\\bcdedit.exe /set testsigning on'. Action ended 11:25:49: SetInstallCmd_Cmd. Return value 1. MSI (s) (B8:74) [11:25:49:046]: Doing action: SetInstallCmd Action start 11:25:49: SetInstallCmd. Action ended 11:25:49: SetInstallCmd. Return value 1. MSI (s) (B8:74) [11:25:49:062]: Doing action: InstallAHCI64 ... MSI (s) (B8:74) [11:25:49:140]: Executing op: ActionStart(Name=SetInstallCmd,,) MSI (s) (B8:74) [11:25:49:140]: Executing op: CustomActionSchedule(Action=SetInstallCmd,ActionType=3137,Source=BinaryData,Target=CAQuietExec,CustomActionData=C:\Windows\system32\\bcdedit.exe /set testsigning on) MSI (s) (B8:74) [11:25:49:140]: Creating MSIHANDLE (4) of type 790536 for thread 1908 MSI (s) (B8:D8) [11:25:49:140]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIC31B.tmp, Entrypoint: CAQuietExec MSI (s) (B8:C4) [11:25:49:140]: Generating random cookie. MSI (s) (B8:C4) [11:25:49:140]: Created Custom Action Server with PID 1884 (0x75C). MSI (s) (B8:48) [11:25:49:498]: Running as a service. MSI (s) (B8:48) [11:25:49:498]: Hello, I'm your 32bit Elevated custom action server. MSI (s) (B8!44) [11:25:49:514]: Creating MSIHANDLE (5) of type 790531 for thread 2628 CAQuietExec: Error 0x80070002: Command failed to execute. MSI (s) (B8!44) [11:25:49:514]: Closing MSIHANDLE (5) of type 790531 for thread 2628 MSI (s) (B8!44) [11:25:49:514]: Creating MSIHANDLE (6) of type 790531 for thread 2628 CAQuietExec: Error 0x80070002: CAQuietExec Failed MSI (s) (B8!44) [11:25:49:514]: Closing MSIHANDLE (6) of type 790531 for thread 2628 CustomAction SetInstallCmd returned actual error code 1603 but will be translated to success due to continue marking MSI (s) (B8:D8) [11:25:49:514]: Closing MSIHANDLE (4) of type 790536 for thread 1908 MSI (s) (B8:74) [11:25:49:514]: Executing op: ActionStart(Name=InstallAHCI64,Description=Installing ,) MSI (s) (B8:74) [11:25:49:514]: Executing op: CustomActionSchedule(Action=InstallAHCI64,ActionType=3138,Source=BinaryData,Target=/F /PATH C:\Program Files\\\,) CustomAction InstallAHCI64 returned actual error code 1073741825 but will be translated to success due to continue marking Any ideas? Thank you -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Does-wix-support-calling-bcdedit-tp7551749.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [WiX-users] Does wix support calling bcdedit?
...which is why I suggested deleting that extra \ as something to try. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Friday, May 11, 2012 2:37 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does wix support calling bcdedit? HRESULT 0x80070002 means ERROR_FILE_NOT_FOUND See http://msdn.microsoft.com/en-us/library/windows/desktop/dd319335.aspx Open up a cmd prompt and execute the following command (don't change the quotes or anything else): C:\Windows\system32\\bcdedit.exe /set testsigning on Verify whether the command above (exactly) succeeds or fails. The command above is the exact command that your custom action is attempting to execute. If it works, then you'll need to continue investigating. If it doesn't then there's something wrong in the way you set the SetInstallCmd property. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Vincent Wong [mailto:victorhwhis...@yahoo.com] Sent: Friday, May 11, 2012 1:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does wix support calling bcdedit? Sorry, Here's the CA codes and I'm running elevated as perMachine install CustomAction Id=SetInstallCmd_Cmd Property=SetInstallCmd Value='[System64Folder]\bcdedit.exe /set testsigning on' / CustomAction Id=SetInstallCmd BinaryKey=WixCA DllEntry=CAQuietExec Return=ignore Execute=deferred Impersonate=no/ --- On Fri, 5/11/12, victorwhiskey victorhwhis...@yahoo.com wrote: From: victorwhiskey victorhwhis...@yahoo.com Subject: [WiX-users] Does wix support calling bcdedit? To: wix-users@lists.sourceforge.net Date: Friday, May 11, 2012, 8:07 PM Hi, I'm trying to call bcdedit from a deferred custom action to set the machine in test mode. I'm trying to install unsigned drivers at the moment so I want to put the machine in test mode with the command bcdedit /set testsigning on. I'm calling CAQuietExec byt I'm getting Error 0x80070002 These are snips of my log: MSI (s) (B8:74) [11:25:49:046]: Note: 1: 2205 2: 3: PatchPackage Action ended 11:25:49: InstallFiles. Return value 1. MSI (s) (B8:74) [11:25:49:046]: Doing action: SetInstallCmd_Cmd Action start 11:25:49: SetInstallCmd_Cmd. MSI (s) (B8:74) [11:25:49:046]: PROPERTY CHANGE: Adding SetInstallCmd property. Its value is 'C:\Windows\system32\\bcdedit.exe /set testsigning on'. Action ended 11:25:49: SetInstallCmd_Cmd. Return value 1. MSI (s) (B8:74) [11:25:49:046]: Doing action: SetInstallCmd Action start 11:25:49: SetInstallCmd. Action ended 11:25:49: SetInstallCmd. Return value 1. MSI (s) (B8:74) [11:25:49:062]: Doing action: InstallAHCI64 ... MSI (s) (B8:74) [11:25:49:140]: Executing op: ActionStart(Name=SetInstallCmd,,) MSI (s) (B8:74) [11:25:49:140]: Executing op: CustomActionSchedule(Action=SetInstallCmd,ActionType=3137,Source=Binar yD ata,Target=CAQuietExec,CustomActionData=C:\Windows\system32\\bcdedit. e xe /set testsigning on) MSI (s) (B8:74) [11:25:49:140]: Creating MSIHANDLE (4) of type 790536 for thread 1908 MSI (s) (B8:D8) [11:25:49:140]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIC31B.tmp, Entrypoint: CAQuietExec MSI (s) (B8:C4) [11:25:49:140]: Generating random cookie. MSI (s) (B8:C4) [11:25:49:140]: Created Custom Action Server with PID 1884 (0x75C). MSI (s) (B8:48) [11:25:49:498]: Running as a service. MSI (s) (B8:48) [11:25:49:498]: Hello, I'm your 32bit Elevated custom action server. MSI (s) (B8!44) [11:25:49:514]: Creating MSIHANDLE (5) of type 790531 for thread 2628 CAQuietExec: Error 0x80070002: Command failed to execute. MSI (s) (B8!44) [11:25:49:514]: Closing MSIHANDLE (5) of type 790531 for thread 2628 MSI (s) (B8!44) [11:25:49:514]: Creating MSIHANDLE (6) of type 790531 for thread 2628 CAQuietExec: Error 0x80070002: CAQuietExec Failed MSI (s) (B8!44) [11:25:49:514]: Closing MSIHANDLE (6) of type 790531 for thread 2628 CustomAction SetInstallCmd returned actual error code 1603 but will be translated to success due to continue marking MSI (s) (B8:D8) [11:25:49:514]: Closing MSIHANDLE (4) of type 790536 for thread 1908 MSI (s) (B8:74) [11:25:49:514]: Executing op: ActionStart(Name=InstallAHCI64,Description=Installing ,) MSI (s) (B8:74) [11:25:49:514]: Executing op: CustomActionSchedule(Action=InstallAHCI64,ActionType=3138,Source=Binar yD ata,Target=/F /PATH C:\Program Files\\\,) CustomAction InstallAHCI64 returned actual error code 1073741825 but will be translated to success due to continue marking Any ideas? Thank you -- View this message in context:
Re: [WiX-users] Add/remove Programs
Not sure if this has been mentioned, but one of the gotchas is that the
previous version of the install might be installed per-user instead of
per-machine. A per-machine install will not upgrade a per user (and vice versa)
so you get two entries in ARP. That's an InstallShield log, not an MSI log, but
not related might be trying to tell you it's not the same install context as
the incoming one.
I vaguely recall that InstallShield tries to be clever in this area, that's why
that code is called SetAllUsers. When you do an upgrade I think it might make
an effort to match ALLUSERS with the installed product it found (so you can do
the upgrade). If anything is going on there, it's an InstallShield thing.
Clearly you need to put versions in your Upgrade table that match the versions
you want to upgrade, as InstallShield is using those records to figure out what
upgrade it will do.
Phil W
-Original Message-
From: Ian Brooke [mailto:ianbro...@hotmail.com]
Sent: Tuesday, May 08, 2012 8:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Add/remove Programs
I'm sorry to keep going on about this problem. Despite the various suggestions
(some of which I have to admit were over my head!) I am still uncertain where
this problem lies, there seems to be various candidates - a problem with the
original install, a problem with Installshield or a problem with Windows
Installer. The second of these I could I believe fix by switching to WiX, the
others I could not.
I went through the InstallLog from the latest attempt and found this section:
Begin SetAllUsers()
InstallShield 9:22:28: Getting records from Upgrade table
InstallShield 9:22:28: UpgradeCode: {B638-F1BE-45AC-B27A-BE69104843CF}
MinVersion: MaxVersion: Language: 1033Attributes: 1024
InstallShield 9:22:28: Checking related product
{030062FD-BFBE-4443-A22A-668F27A8D718}
InstallShield 9:22:28: AppName{030062FD-BFBE-4443-A22A-668F27A8D718}
10337.0.2 ***Not Related***
InstallShield 9:22:28: No related products for UpgradeCode
{B638-F1BE-45AC-B27A-BE69104843CF} found
InstallShield 9:22:28: UpgradeCode: {B638-F1BE-45AC-B27A-BE69104843CF}
MinVersion: 7.1.0MaxVersion: Language: Attributes: 2
InstallShield 9:22:28: Checking related product
{030062FD-BFBE-4443-A22A-668F27A8D718}
InstallShield 9:22:28: No related products for UpgradeCode
{B638-F1BE-45AC-B27A-BE69104843CF} found InstallShield 9:22:28: End
SetAllUsers()
To me that ***Not Related*** seems significant! But I don't know why it's
saying this. I was previously specifying Min and a Max version number with
Min=7.0.0 and Max=7.0.3 but this wasn't working so I removed them to see if it
would help, it didn't.
Can anyone tell me what Attributes: 1024 means and is this likely to affect
anything?
I really don't know why the new version 7.1.0 is shown with a blank language
code as one was specified. Is that the cause?
More importantly, can anyone tell me if this looks like an issue that I could
fix by switching to WiX?
Many thanks
Ian
-Original Message-
From: Ian Brooke
Sent: Tuesday, May 08, 2012 7:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Add/remove Programs
Thanks for your reply Neil,
I'm not aware of a Package Code in Installshield, however the Product Code
has changed and the Version number has changed (from 7.0.2 to 7.0.4) and the
Upgrade Code has remained the same so I have no idea what's going on.
Sounds as though it's an Installshield problem though rather than one with the
Windows Installer.
Looks like I'm going to have to spend the time to switch it to WiX, not
something I wanted to do at this moment in time :(
Ian
-Original Message-
From: Neil Sleightholm
Sent: Tuesday, May 08, 2012 12:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Add/remove Programs
That is supported by Windows Installer and shouldn't be happening if your MSI
is setup correctly even in Installshield. For a major upgrade you need to
change the Package code, Product code and version and leave the Upgrade code
the same.
WiX 3.5 makes this easy to setup
http://wix.sourceforge.net/manual-wix3/major_upgrade.htm,
http://www.joyofsetup.com/2010/01/16/major-upgrades-now-easier-than-ever/
Here is the setup for v3
http://neilsleightholm.blogspot.co.uk/2009/01/wix-script-for-major-upgrades.html
Neil
-Original Message-
From: Ian Brooke [mailto:ianbro...@hotmail.com]
Sent: 08 May 2012 01:38
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Add/remove Programs
I hope you don't mind this slightly unusual question!
We have a product currently installed by Installshield (Express 2012) which we
are considering switching to WiX but don't really want to spend the time doing
that if it doesn't solve our problem.
What I really need to determine is
Re: [WiX-users] MsiRMFilesInUse example to restart browsers
Are you maybe misunderstanding the FilesInUse dialogs? Windows decides to show this or nor based on what files need replacing, whether they are in use, their versions etc. CloseApplication is not the same thing at all - it's a WiX feature that closes applications. Phil W -Original Message- From: E. Timothy Uy [mailto:t...@loqu8.com] Sent: Thursday, April 26, 2012 9:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MsiRMFilesInUse example to restart browsers With chrome in the mix, nothing at all (not even IE or Firefox) gets terminated. Action 9:04:37: WixRegisterRestartResources. Action start 9:04:37: WixRegisterRestartResources. WixRegisterRestartResources: Entering WixRegisterRestartResources in C:\Windows\Installer\MSI7074.tmp, version 3.6.2809.0 WixRegisterRestartResources: Registering process name iexplore.exe with the Restart Manager. WixRegisterRestartResources: Registering process name firefox.exe with the Restart Manager. WixRegisterRestartResources: Registering process name chrome.exe with the Restart Manager. Action ended 9:04:38: WixRegisterRestartResources. Return value 1. Action 9:04:38: InstallValidate. Validating install Action start 9:04:38: InstallValidate. Action 9:04:43: ShutdownApplications. Shutting down applications The setup was unable to automatically close all requested applications. Please ensure that the applications holding files in use are closed before continuing with the installation. Action ended 9:04:54: InstallValidate. Return value 1. On Wed, Apr 25, 2012 at 3:59 PM, E. Timothy Uy t...@loqu8.com wrote: chrome.exe - does not close firefox.exe - closes, but never restarts iexplore.exe - closes and restarts (blank page) On Wed, Apr 25, 2012 at 2:50 PM, E. Timothy Uy t...@loqu8.com wrote: The plot thickens. Removing Chrome from the mix makes it work. util:RestartResource Id=RestartIE ProcessName=iexplore.exe / util:RestartResource Id=RestartFirefox ProcessName=firefox.exe / Is this solvable? I did notice that chrome.exe uses a lot of processes. Could this be the issue? Is there a limit on the # of processes? On Wed, Apr 25, 2012 at 2:14 PM, E. Timothy Uy t...@loqu8.com wrote: I was able to show the FilesInUse (for iexplore, chrome and firefox) but just adding util:RestartResource Id=RestartIE ProcessName=iexplore.exe / util:RestartResource Id=RestartChrome ProcessName=chrome.exe / util:RestartResource Id=RestartFirefox ProcessName=firefox.exe / However, clicking on attempt to close prompted me with The setup was unable to automatically close all requested applications. Please ensure that the applications holding files in use are closed before continuing with the installation. None of the browser instances are closed. Any advice would be much appreciated. Respectfully, Tim On Wed, Apr 25, 2012 at 1:56 PM, E. Timothy Uy t...@loqu8.com wrote: Looks like RM only works with Vista+. What is the fallback for XP? On Wed, Apr 25, 2012 at 1:53 PM, E. Timothy Uy t...@loqu8.com wrote: Dear Rob et al., Thanks everyone for being so gracious. This time I would like the installer to shutdown any browsers (IE, Chrome, Firefox) prior to installation, and restart them after installation completes. I think I should use MsiRMFilesInUse but have not been able to locate any samples or instructions. Is this used with util:CloseApplication? I gather that I need DialogRef Id=MsiRMFilesInUse / in UI. Can I use WixUI_InstallDir or should I be using Mondo? A completed example would be ideal. The How To Guides are fantastic. Respectfully, Tim -- 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 *** 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
Re: [WiX-users] Install Failed, Log Attached
That HRESULT is FUSION_E_UNEXPECTED_MODULE_FOUND.
http://blogs.msdn.com/b/astebner/archive/2004/11/10/255346.aspx
Is there a config file associated with the assembly (maybe because it's a
policy assembly)?
Is it actually a Dll?
Phil W
-Original Message-
From: Sam Youtsey [mailto:sam.yout...@gmail.com]
Sent: Thursday, April 26, 2012 10:35 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Install Failed, Log Attached
Hi all,
My installer doesn't seem to be installing anything properly. Any chance I
could get some help with it?
Here's the .wxs file:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=MyGuid
Name=MyProg
Language=1033
Version=$(var.ProductVersion)
Manufacturer=MyCompany
UpgradeCode=MyGuid2
Package InstallerVersion=200 Compressed=yes InstallScope=perMachine
/
MajorUpgrade DowngradeErrorMessage=A newer version of [ProductName] is
already installed. / MediaTemplate EmbedCab=yes/
Feature Id=ProductFeature Title=MyProg Level=1 ComponentGroupRef
Id=ProductComponents / /Feature /Product
Fragment
Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder
Name=Program Files Directory Id=COMPANYFOLDER Name=MyCompany
Directory Id=INSTALLFOLDER Name=MyProg / /Directory /Directory
/Directory /Fragment
Fragment
ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER
!-- TODO: Remove the comments around this Component element and the
ComponentRef below in order to add resources to this installer. -- Component
Id=ProductComponent Guid=MyGuid3 File Id=MyProgDLL
Source=..\MyProg\bin\Debug\MyProg.dll KeyPath=yes
Assembly=.net/File
File Id=MyProgTLB
Source=..\MyProg\bin\Debug\MyProg.tlb/File
File Id=F_JavascriptNET KeyPath=no
Source=..\$(var.JavascriptNET)\Noesis.Javascript.dll / File
Id=MyProg_Demo Source=..\MyProg_Demo.xlsm/File
/Component
/ComponentGroup
/Fragment
/Wix
And here's around the error that I'm seeing in the log:
MSI (s) (CC:68) [10:04:32:829]: Executing op:
UpgradeCodePublish(UpgradeCode={MyGuid3})
MSI (s) (CC:68) [10:04:32:829]: Executing op:
SourceListPublish(NumberOfDisks=1)
MSI (s) (CC:68) [10:04:32:839]: Note: 1: 1402 2:
UNKNOWN\Installer\Products\xxx\SourceList 3: 2 MSI (s) (CC:68) [10:04:32:859]:
Executing op: ProductPublishClient(,,) MSI (s) (CC:68) [10:04:32:879]:
Executing op:
SourceListRegisterLastUsed(SourceProduct={MyGuid3},LastUsedSource=C:\Users\Clean\Downloads\)
MSI (s) (CC:68) [10:04:32:919]: Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (s) (CC:68) [10:04:32:939]: Setting cached product context: machine
assigned for product: xxx MSI (s) (CC:68) [10:04:32:949]: Specifed source is
already in a list.
MSI (s) (CC:68) [10:04:32:979]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (CC:68) [10:04:32:989]: Adding new sources is allowed.
MSI (s) (CC:68) [10:04:33:009]: Set LastUsedSource to:
C:\Users\Clean\Downloads\.
MSI (s) (CC:68) [10:04:33:029]: Set LastUsedType to: n.
MSI (s) (CC:68) [10:04:33:039]: Set LastUsedIndex to: 1.
MSI (s) (CC:68) [10:04:33:059]: Executing op:
End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=4286641)
MSI (s) (CC:68) [10:04:33:089]: Note: 1: 1935 2: {MyGuid3} 3: 0x80131043 4:
IAssemblyCacheItem 5: Commit
6:
MyProg,version=1.0.0.0,culture=neutral,publicKeyToken=1BC84BAF13B2B399,processorArchitecture=MSIL
MSI (s) (CC:68) [10:04:33:280]: Note: 1: 2205 2: 3: Error MSI (s) (CC:68)
[10:04:33:350]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error`
WHERE `Error` = 1935 MSI (c) (20:B0) [10:04:34:051]: Font created. Charset:
Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1935. An error occurred during the installation of assembly
'MyProg,version=1.0.0.0,culture=neutral,publicKeyToken=1BC84BAF13B2B399,processorArchitecture=MSIL'.
Please refer to Help and Support for more information. HRESULT: 0x80131043.
assembly interface: IAssemblyCacheItem, function: Commit, component:
{MyGuid3}
MSI (s) (CC:68) [10:04:35:623]: Note: 1: 2205 2: 3: Error MSI (s) (CC:68)
[10:04:35:633]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error`
WHERE `Error` = 1709 MSI (s) (CC:68) [10:04:35:643]: Product: MyProg -- Error
1935. An error occurred during the installation of assembly
'MyProg,version=1.0.0.0,culture=neutral,publicKeyToken=1BC84BAF13B2B399,processorArchitecture=MSIL'.
Please refer to Help and Support for more information. HRESULT: 0x80131043.
assembly interface: IAssemblyCacheItem, function: Commit, component:
{MyGuid3}
Action ended 10:04:35: InstallFinalize. Return value 3.
--
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.
Re: [WiX-users] Install Failed, Log Attached
And the TLB file is in the same component as the assembly or is somehow being
installed to the GAC? That could explain an error
FUSION_E_UNEXPECTED_MODULE_FOUND.
Phil W
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Thursday, April 26, 2012 12:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install Failed, Log Attached
A TLB files strongly suggests that this is a COM and/or native DLL. I don't
think that's a candidate for the GAC either way.
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: Sam Youtsey [mailto:sam.yout...@gmail.com]
Sent: Thursday, April 26, 2012 2:28 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Install Failed, Log Attached
Yeah, it's a DLL. There don't seem to be any config files associated, just the
TLB file. Anything else to look for?
That HRESULT is FUSION_E_UNEXPECTED_MODULE_FOUND.
http://blogs.msdn.com/b/astebner/archive/2004/11/10/255346.aspx
Is there a config file associated with the assembly (maybe because
it's a policy assembly)?
Is it actually a Dll?
Phil W
-Original Message-
From: Sam Youtsey [mailto:sam.youtsey@...]
Sent: Thursday, April 26, 2012 10:35 AM
To: wix-users@...
Subject: [WiX-users] Install Failed, Log Attached Hi all, My installer
doesn't seem to be installing anything properly. Any chance I could
get some help with it?
Here's the .wxs file:
?xml version=1.0 encoding=UTF-8? Wix
xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=MyGuid
Name=MyProg
Language=1033
Version=$(var.ProductVersion)
Manufacturer=MyCompany
UpgradeCode=MyGuid2
Package InstallerVersion=200 Compressed=yes InstallScope=perMachine
/
MajorUpgrade DowngradeErrorMessage=A newer version of [ProductName]
is already installed. / MediaTemplate EmbedCab=yes/ Feature
Id=ProductFeature Title=MyProg Level=1 ComponentGroupRef
Id=ProductComponents / /Feature /Product Fragment Directory
Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder
Name=Program Files Directory Id=COMPANYFOLDER
Name=MyCompany Directory Id=INSTALLFOLDER Name=MyProg /
/Directory /Directory /Directory /Fragment Fragment
ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER
!-- TODO: Remove the comments around this Component element and the
ComponentRef below in order to add resources to this installer. --
Component Id=ProductComponent Guid=MyGuid3 File Id=MyProgDLL
Source=..\MyProg\bin\Debug\MyProg.dll KeyPath=yes
Assembly=.net/File
File Id=MyProgTLB
Source=..\MyProg\bin\Debug\MyProg.tlb/File
File Id=F_JavascriptNET KeyPath=no
Source=..\$(var.JavascriptNET)\Noesis.Javascript.dll / File
Id=MyProg_Demo Source=..\MyProg_Demo.xlsm/File
/Component
/ComponentGroup
/Fragment
/Wix
And here's around the error that I'm seeing in the log:
MSI (s) (CC:68) [10:04:32:829]: Executing op:
UpgradeCodePublish(UpgradeCode={MyGuid3})
MSI (s) (CC:68) [10:04:32:829]: Executing op:
SourceListPublish(NumberOfDisks=1)
MSI (s) (CC:68) [10:04:32:839]: Note: 1: 1402 2:
UNKNOWN\Installer\Products\xxx\SourceList 3: 2 MSI (s) (CC:68)
[10:04:32:859]: Executing op: ProductPublishClient(,,) MSI (s) (CC:68)
[10:04:32:879]: Executing op:
SourceListRegisterLastUsed(SourceProduct={MyGuid3},LastUsedSource=C:\U
sers\Clean\Downloads\) MSI (s) (CC:68) [10:04:32:919]: Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (s) (CC:68) [10:04:32:939]: Setting cached product context:
machine assigned for product: xxx MSI (s) (CC:68) [10:04:32:949]:
Specifed source is already in a list.
MSI (s) (CC:68) [10:04:32:979]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (CC:68) [10:04:32:989]: Adding new sources is allowed.
MSI (s) (CC:68) [10:04:33:009]: Set LastUsedSource to:
C:\Users\Clean\Downloads\.
MSI (s) (CC:68) [10:04:33:029]: Set LastUsedType to: n.
MSI (s) (CC:68) [10:04:33:039]: Set LastUsedIndex to: 1.
MSI (s) (CC:68) [10:04:33:059]: Executing op:
End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=4286641)
MSI (s) (CC:68) [10:04:33:089]: Note: 1: 1935 2: {MyGuid3} 3: 0x80131043 4:
IAssemblyCacheItem 5: Commit
6:
MyProg,version=1.0.0.0,culture=neutral,publicKeyToken=1BC84BAF13B2B399,processorArchitecture=MSIL
MSI (s) (CC:68) [10:04:33:280]: Note: 1: 2205 2: 3: Error MSI (s)
(CC:68)
[10:04:33:350]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM
`Error` WHERE `Error` = 1935 MSI (c) (20:B0) [10:04:34:051]: Font created.
Charset:
Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1935. An error occurred during the installation of assembly
'MyProg,version=1.0.0.0,culture=neutral,publicKeyToken=1BC84BAF13B2B399,processorArchitecture=MSIL'.
Please refer to Help and Support for more information. HRESULT: 0x80131043.
assembly interface:
Re: [WiX-users] Install Failed, Log Attached
Well you can install assemblies (that supply COM interfaces) into the GAC. But
you are trying to install a Win32 COM DLL into the GAC? That won't work, and
it's not a WiX issue - it doesn't matter what you use to build your MSI file
because it's MSI that's doing the install.
If it's Win32 COM, just install it in CommonFiles for your Company.
Phil W
-Original Message-
From: Sam Youtsey [mailto:sam.yout...@gmail.com]
Sent: Thursday, April 26, 2012 1:41 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Install Failed, Log Attached
Ah, I wasn't aware COM DLLs couldn't be installed into the GAC. What's an
appropriate course of action for using them on the client system if I still
wanted to use WiX?
And the TLB file is in the same component as the assembly or is
somehow being installed to the GAC? That could explain an error
FUSION_E_UNEXPECTED_MODULE_FOUND.
Phil W
-Original Message-
From: John Cooper [mailto:JoCooper@...]
Sent: Thursday, April 26, 2012 12:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install Failed, Log Attached A TLB files
strongly suggests that this is a COM and/or native DLL. I don't think
that's a candidate for the GAC either way.
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
JoCooper@...
http://www.jackhenry.com
-Original Message-
From: Sam Youtsey [mailto:sam.youtsey@...]
Sent: Thursday, April 26, 2012 2:28 PM
To: wix-users@...
Subject: Re: [WiX-users] Install Failed, Log Attached Yeah, it's a
DLL. There don't seem to be any config files associated, just the TLB
file. Anything else to look for?
That HRESULT is FUSION_E_UNEXPECTED_MODULE_FOUND.
http://blogs.msdn.com/b/astebner/archive/2004/11/10/255346.aspx
Is there a config file associated with the assembly (maybe because
it's a policy assembly)?
Is it actually a Dll?
Phil W
-Original Message-
From: Sam Youtsey [mailto:sam.youtsey@...]
Sent: Thursday, April 26, 2012 10:35 AM
To: wix-users@...
Subject: [WiX-users] Install Failed, Log Attached Hi all, My
installer doesn't seem to be installing anything properly. Any
chance I could get some help with it?
Here's the .wxs file:
?xml version=1.0 encoding=UTF-8? Wix
xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=MyGuid
Name=MyProg
Language=1033
Version=$(var.ProductVersion)
Manufacturer=MyCompany
UpgradeCode=MyGuid2
Package InstallerVersion=200 Compressed=yes
InstallScope=perMachine
/
MajorUpgrade DowngradeErrorMessage=A newer version of
[ProductName] is already installed. / MediaTemplate
EmbedCab=yes/ Feature Id=ProductFeature Title=MyProg
Level=1 ComponentGroupRef Id=ProductComponents / /Feature
/Product Fragment Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Name=Program Files Directory Id=COMPANYFOLDER
Name=MyCompany Directory Id=INSTALLFOLDER Name=MyProg /
/Directory /Directory /Directory /Fragment Fragment
ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER
!-- TODO: Remove the comments around this Component element and the
ComponentRef below in order to add resources to this installer. --
Component Id=ProductComponent Guid=MyGuid3 File Id=MyProgDLL
Source=..\MyProg\bin\Debug\MyProg.dll KeyPath=yes
Assembly=.net/File
File Id=MyProgTLB
Source=..\MyProg\bin\Debug\MyProg.tlb/File
File Id=F_JavascriptNET KeyPath=no
Source=..\$(var.JavascriptNET)\Noesis.Javascript.dll / File
Id=MyProg_Demo Source=..\MyProg_Demo.xlsm/File
/Component
/ComponentGroup
/Fragment
/Wix
And here's around the error that I'm seeing in the log:
MSI (s) (CC:68) [10:04:32:829]: Executing op:
UpgradeCodePublish(UpgradeCode={MyGuid3})
MSI (s) (CC:68) [10:04:32:829]: Executing op:
SourceListPublish(NumberOfDisks=1)
MSI (s) (CC:68) [10:04:32:839]: Note: 1: 1402 2:
UNKNOWN\Installer\Products\xxx\SourceList 3: 2 MSI (s) (CC:68)
[10:04:32:859]: Executing op: ProductPublishClient(,,) MSI (s)
(CC:68)
[10:04:32:879]: Executing op:
SourceListRegisterLastUsed(SourceProduct={MyGuid3},LastUsedSource=C:
\U
sers\Clean\Downloads\) MSI (s) (CC:68) [10:04:32:919]: Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (s) (CC:68) [10:04:32:939]: Setting cached product context:
machine assigned for product: xxx MSI (s) (CC:68) [10:04:32:949]:
Specifed source is already in a list.
MSI (s) (CC:68) [10:04:32:979]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (CC:68) [10:04:32:989]: Adding new sources is allowed.
MSI (s) (CC:68) [10:04:33:009]: Set LastUsedSource to:
C:\Users\Clean\Downloads\.
MSI (s) (CC:68) [10:04:33:029]: Set LastUsedType to: n.
MSI (s) (CC:68) [10:04:33:039]: Set LastUsedIndex to: 1.
MSI (s) (CC:68) [10:04:33:059]: Executing op:
Re: [WiX-users] Install Failed, Log Attached
You really have to say if it's a Win32 COM Dll or not. I can't see a definitive
statement one way or another. However if it is Win32 COM, just use Heat.exe to
generate the WiX source for the registration.
Phil W
-Original Message-
From: Sam Youtsey [mailto:sam.yout...@gmail.com]
Sent: Thursday, April 26, 2012 3:13 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Install Failed, Log Attached
Once I've installed it into the CommonFiles directory how can I register and
access it through the system? This is typically done with RegAsm.exe on the dev
machine but this isn't available on the client machine. Eventually, I want to
be able to see this DLL's classes through Excel.
Well you can install assemblies (that supply COM interfaces) into the GAC.
But you are trying to install a Win32 COM DLL into the GAC? That won't
work, and it's not a WiX issue - it doesn't matter what you use to
build your MSI file because it's MSI that's doing the install.
If it's Win32 COM, just install it in CommonFiles for your Company.
Phil W
-Original Message-
From: Sam Youtsey [mailto:sam.youtsey@...]
Sent: Thursday, April 26, 2012 1:41 PM
To: wix-users@...
Subject: Re: [WiX-users] Install Failed, Log Attached Ah, I wasn't
aware COM DLLs couldn't be installed into the GAC. What's an
appropriate course of action for using them on the client system if I
still wanted to use WiX?
And the TLB file is in the same component as the assembly or is
somehow being installed to the GAC? That could explain an error
FUSION_E_UNEXPECTED_MODULE_FOUND.
Phil W
-Original Message-
From: John Cooper [mailto:JoCooper@...]
Sent: Thursday, April 26, 2012 12:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Install Failed, Log Attached A TLB files
strongly suggests that this is a COM and/or native DLL. I don't
think that's a candidate for the GAC either way.
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
JoCooper@...
http://www.jackhenry.com
-Original Message-
From: Sam Youtsey [mailto:sam.youtsey@...]
Sent: Thursday, April 26, 2012 2:28 PM
To: wix-users@...
Subject: Re: [WiX-users] Install Failed, Log Attached Yeah, it's a
DLL. There don't seem to be any config files associated, just the
TLB file. Anything else to look for?
That HRESULT is FUSION_E_UNEXPECTED_MODULE_FOUND.
http://blogs.msdn.com/b/astebner/archive/2004/11/10/255346.aspx
Is there a config file associated with the assembly (maybe because
it's a policy assembly)?
Is it actually a Dll?
Phil W
-Original Message-
From: Sam Youtsey [mailto:sam.youtsey@...]
Sent: Thursday, April 26, 2012 10:35 AM
To: wix-users@...
Subject: [WiX-users] Install Failed, Log Attached Hi all, My
installer doesn't seem to be installing anything properly. Any
chance I could get some help with it?
Here's the .wxs file:
?xml version=1.0 encoding=UTF-8? Wix
xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=MyGuid
Name=MyProg
Language=1033
Version=$(var.ProductVersion)
Manufacturer=MyCompany
UpgradeCode=MyGuid2
Package InstallerVersion=200 Compressed=yes
InstallScope=perMachine
/
MajorUpgrade DowngradeErrorMessage=A newer version of
[ProductName] is already installed. / MediaTemplate
EmbedCab=yes/ Feature Id=ProductFeature Title=MyProg
Level=1 ComponentGroupRef Id=ProductComponents / /Feature
/Product Fragment Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Name=Program Files Directory Id=COMPANYFOLDER
Name=MyCompany Directory Id=INSTALLFOLDER Name=MyProg /
/Directory /Directory /Directory /Fragment Fragment
ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER
!-- TODO: Remove the comments around this Component element and
the ComponentRef below in order to add resources to this
installer. -- Component Id=ProductComponent Guid=MyGuid3 File
Id=MyProgDLL
Source=..\MyProg\bin\Debug\MyProg.dll KeyPath=yes
Assembly=.net/File
File Id=MyProgTLB
Source=..\MyProg\bin\Debug\MyProg.tlb/File
File Id=F_JavascriptNET KeyPath=no
Source=..\$(var.JavascriptNET)\Noesis.Javascript.dll / File
Id=MyProg_Demo Source=..\MyProg_Demo.xlsm/File
/Component
/ComponentGroup
/Fragment
/Wix
And here's around the error that I'm seeing in the log:
MSI (s) (CC:68) [10:04:32:829]: Executing op:
UpgradeCodePublish(UpgradeCode={MyGuid3})
MSI (s) (CC:68) [10:04:32:829]: Executing op:
SourceListPublish(NumberOfDisks=1)
MSI (s) (CC:68) [10:04:32:839]: Note: 1: 1402 2:
UNKNOWN\Installer\Products\xxx\SourceList 3: 2 MSI (s) (CC:68)
[10:04:32:859]: Executing op: ProductPublishClient(,,) MSI (s)
(CC:68)
[10:04:32:879]: Executing op:
Re: [WiX-users] ERROR_INSTALL_SOURCE_ABSENT: error on update or uninstallation
A couple or three notes on causes: 1. A ResolveSource action with an incorrect condition can cause this, something that may be worth checking. 2. Any kind of update requires Windows to see if an incoming versioned file has a higher version than the one on the system. Some people do out-of-band updates, such as manually replacing a file instead of building a patch to install it. If this has happened, the only way for Windows to figure out if the file should be updated or not is to ask for the original install image to get that file back. I think similar things can happen on an uninstall if the file is shared. 3. More at http://msdn.microsoft.com/en-us/library/windows/desktop/aa370841(v=vs.85).aspx Phil W -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, April 18, 2012 8:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ERROR_INSTALL_SOURCE_ABSENT: error on update or uninstallation This is exactly why Burn caches MSIs for you on the users machine. One way to fix it would be to get the original MSI and run msiexec /fv . I believe that would get the original MSI cached again with the new source location then you can move forward with the upgrade. On Wed, Apr 18, 2012 at 5:30 AM, Osanger, Martin martin.osan...@fabasoft.com wrote: Hello, I have the following questions about this msi error: ERROR_INSTALL_SOURCE_ABSENT: Contact your technical support group. System Error 1612. I built a msi package which works fine on 98% of all installations, but sometimes on an update or uninstallation the system error 1612 occurs. In my opinion on nearly all installations where this error occurs it couldn't be copied into the cache directory (C:\Windows\Installer). Is there anything which I could do, to avoid this error or improve my setup so that this error couldn't occur anymore? I invest a lot of time to search for a solution on the internet but I only read the same things about removing the registry key or using the Microsoft cleanup utility, but this things aren't the best way for many users. Kind regards, martin -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-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 -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ 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). -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Disabling System32 folder redirection
Heath's article probably applies http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx Phil W -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, April 10, 2012 10:55 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Disabling System32 folder redirection Is your installer marked as a 64 bit installer? I would assume not as it is redirecting you to the 32 bit system folder. I believe you need to make both a 32 bit MSI and a 64 bit MSI. Jacob -Original Message- From: Chris Robison [mailto:chrisdrobi...@gmail.com] Sent: Tuesday, April 10, 2012 11:59 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Disabling System32 folder redirection I have a need to install files into the System32 folder on a x64 system. The installer seems to be redirecting everything to the SysWOW64 folder no matter what I try. Is there a way to do this? Chris -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ 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). -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Wix-Users] How to disable/by pass error dialog on FullUI mode?
Do you have any more details of the error? The normal behavior in full UI mode is that you will see an error message and the install transaction will roll back. Phil W -Original Message- From: Niklaus Pham [mailto:niklaus.p...@gmail.com] Sent: Sunday, April 08, 2012 12:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] [Wix-Users] How to disable/by pass error dialog on FullUI mode? Hi all, How can I disable/by pass Error message when installer run by UILevel = 5 (Full UI) mode? It look like silent mode. When error occured, installer will exit and have no error dialog showed. Any ideas? Plz help me! Thanks and Best regards, Niklaus Pham Developer at FSU17.BU2, FPT Sofware. Hanoi, Vietnam. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ 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). -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RemoveExisitngProducts and deferred CA
There may not be enough context in that WiX to see what actually gets generated in the MSI file. That sequence is certainly allowed because other tools have been generating it for years. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 2:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RemoveExisitngProducts and deferred CA Thanks for your reply Phil, I had tried that and unfortunately got the error *RemoveExistingProducts action sequenced incorrectly* The sequence which I had tried was InstallExecute Before=RemoveExistingProducts / RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts I had also tried the following sequence but still got the RemoveExistingProducts error RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts On Thu, Mar 29, 2012 at 1:42 PM, Wilson, Phil phil.wil...@invensys.comwrote: The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ 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). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
Re: [WiX-users] RemoveExisitngProducts and deferred CA
That is what I posted earlier, but without seeing that area in the final MSI file it's not clear that's actually what's going on. Phil W -Original Message- From: David Connet [mailto:d...@agilityrecordbook.com] Sent: Friday, March 30, 2012 1:59 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RemoveExisitngProducts and deferred CA If you sequence before InstallFinalize, you need to also schedule InstallExecute (and REP is sequenced after that.) http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29.aspx Dave On 3/30/2012 1:40 PM, Wilson, Phil wrote: There may not be enough context in that WiX to see what actually gets generated in the MSI file. That sequence is certainly allowed because other tools have been generating it for years. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 2:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RemoveExisitngProducts and deferred CA Thanks for your reply Phil, I had tried that and unfortunately got the error *RemoveExistingProducts action sequenced incorrectly* The sequence which I had tried was InstallExecute Before=RemoveExistingProducts / RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts I had also tried the following sequence but still got the RemoveExistingProducts error RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts On Thu, Mar 29, 2012 at 1:42 PM, Wilson, Philphil.wil...@invensys.comwrote: The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ 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
Re: [WiX-users] RemoveExisitngProducts and deferred CA
The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ 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). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Migration from VS Setup Project to WIX - not uninstalling
Doing the upgrade with a verbose log will tell you if it's finding the previous
product. One gotcha when everything else looks correct is that the older
install could have per user (or per system) and your upgrade is the opposite.
Phil W
-Original Message-
From: Daniel Sniderman [mailto:dani...@magenic.com]
Sent: Friday, March 16, 2012 9:47 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Migration from VS Setup Project to WIX - not uninstalling
We are currently using a Visual Studio 2010 Setup project to generate the MSI
for our application and I'm developing a replacement in WIX. Currently - it's
not uninstalling the previous (Visual Studio generated) installation. I found
a solution on Stack Overflow - but it's not working.
I used Orca to find the UpgradeCode for the previous installation and that is
what I'm using
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=* Codepage=1252 Language=1033 Manufacturer=Abbott
Laboratories Name=$(var.Name)
UpgradeCode={52E1A44E-FE13-48CE-8599-CDEDDB569F70}
Version=3.5.7
Package Compressed=yes InstallerVersion=300 Languages=1033
Manufacturer=Abbott Laboratories Platform=x86 /
Upgrade Id={52E1A44E-FE13-48CE-8599-CDEDDB569F70}
!--UpgradeVersion OnlyDetect=yes Minimum=$(var.Version)
Property=NEWERVERSIONDETECTED IncludeMinimum=no /
UpgradeVersion OnlyDetect=no Maximum=$(var.Version)
Property=OLDERVERSIONBEINGUPGRADED IncludeMaximum=no /--
UpgradeVersion
Minimum=1.0.0.0 Maximum=99.0.0.0
Property=PREVIOUSVERSIONSINSTALLED
IncludeMinimum=yes IncludeMaximum=no /
/Upgrade
Property Id=PREVIOUSVERSIONSINSTALLED Secure=yes /
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize /
/InstallExecuteSequence
Daniel P. Sniderman| Sr Consultant| Magenic
MCSD.NET, MCTS: Team Foundation Server 2010 Administration
333 E. Butterfield Rd. Suite 100, Lombard, IL 60148
Mobile: 847-668-4882 | eFax 847-390-7810
magenic.com | dani...@magenic.commailto:dani...@magenic.com
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
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).
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting MsiLogFileLocation property
You can't set MsiLogFileLocation, as the MSDN docs pretty much say. You can try to set it but it's ineffective. If you set it in the property table it just gets overwritten. If you set it with a type 51 it just gets ignored. Phil W -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 10:09 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property Adam, This post indicates that it is possible to set MSI property from WIX: http://blogs.technet.com/b/alexshev/archive/2009/05/16/from-msi-to-wix-part-23-dll-custom-actions-logging-and-setting-properties.aspx If this is true, shouldn't I be able to use this approach to set some kind of MSI property to force logging and/or configure location of the log file? Enabling logging seems to be a pretty common question on the WIX forum, can we have WIX team to provide a recommendation on how to do this? Thanks, Alec On Thu, Mar 15, 2012 at 10:54 AM, Adam Kadzban mightyshorta...@gmail.com wrote: Alec, As far as I know, you can't set the log file location inside WIX because you need to tell msiexec where to write the log file to before actually starting the MSI. You need some sort of bootstrapper that calls msiexec with the logging options. I've used IExpress in the past, but I think I'll be switching to dotNetInstaller soon. -Adam On Thu, Mar 15, 2012 at 11:43 AM, John Cooper jocoo...@jackhenry.comwrote: I've seen the same bugs CP has seen. I've got it set in my installers, but only because CD demands it. Setting it causes a fair number of install failures, particular in install/repair/uninstall cycles. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 11:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property The following thread implied that the file log location can be set through MsiLogFileLocation property in WIX: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Msi-Logging-td707004.html#a707011 But it sounds like Rob is saying this is not possible. So, how can I reliably enable MSI logging programmatically in WIX code and ideally set the location of the log file? We need to support Windows XP SP2 and higher. Thanks, Alec On Thu, Mar 15, 2012 at 10:05 AM, Christopher Painter chr...@iswix.com wrote: I don't know if this is common knowledge but I don't set the MsiLogging property anymore. There' s a known bug in Windows 7 where Explorer / Shell can lose reference to the installer log file location and it causes the installer to crash out. It can manifest itself on uninstall which means you are stuck unless you run the uninstall from the command line passing in an explicit path. From: Rob Mensching r...@robmensching.com Sent: Thursday, March 15, 2012 11:02 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Setting MsiLogFileLocation property I don't think you can set the log file using MsiLogFileLocation. I think it *gets* set to the log file location. You can force your package to require MSI 4.0 by setting the Package/InstallerVersion attribute. On Wed, Mar 14, 2012 at 9:10 PM, Alec Swan alecs...@gmail.com wrote: Hello, I need to enable verbose logging and configure MSI log file location. I am currently doing this by adding the following properties inside of my .wxs file: Wix Product Property Id=LOGVERBOSE1/Property Property Id=MsiLogFileLocationx:/WIX/wix-msi.log/Property ... Is this the right place for these properties? If so, then I am assuming that the reason why they are not taking effect is that the MSI version our Wix project is using is lower than 4.0 and does not support MsiLogFileLocation property. Where do I update the MSI version in my WIX project? Thanks, Alec -- -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here
Re: [WiX-users] Setting MsiLogFileLocation property
Given that WiX generates MSI files and the MSI MSDN docs say you can't set it, and my testing also indicates that you can't set it, I don't see how you could expect a different answer from the WiX Team! It's nothing to do with WiX, or InstallShield or any other tool that generates MSI files. Setting log file location is something you do on the command line to the install or equivalent (MsiInstallProduct parameter). Phil W -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 10:44 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property Phil, thank you for sharing your experience. I would like to keep this thread active until we get a definite answer from the WIX team. Whether it is You can't enable MSI logging in the current version of WIX but will be available in version x.x or This is how you do this ... - it will still be very helpful. Thanks, Alec On Thu, Mar 15, 2012 at 11:32 AM, Wilson, Phil phil.wil...@invensys.com wrote: You can't set MsiLogFileLocation, as the MSDN docs pretty much say. You can try to set it but it's ineffective. If you set it in the property table it just gets overwritten. If you set it with a type 51 it just gets ignored. Phil W -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 10:09 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property Adam, This post indicates that it is possible to set MSI property from WIX: http://blogs.technet.com/b/alexshev/archive/2009/05/16/from-msi-to-wix-part-23-dll-custom-actions-logging-and-setting-properties.aspx If this is true, shouldn't I be able to use this approach to set some kind of MSI property to force logging and/or configure location of the log file? Enabling logging seems to be a pretty common question on the WIX forum, can we have WIX team to provide a recommendation on how to do this? Thanks, Alec On Thu, Mar 15, 2012 at 10:54 AM, Adam Kadzban mightyshorta...@gmail.com wrote: Alec, As far as I know, you can't set the log file location inside WIX because you need to tell msiexec where to write the log file to before actually starting the MSI. You need some sort of bootstrapper that calls msiexec with the logging options. I've used IExpress in the past, but I think I'll be switching to dotNetInstaller soon. -Adam On Thu, Mar 15, 2012 at 11:43 AM, John Cooper jocoo...@jackhenry.comwrote: I've seen the same bugs CP has seen. I've got it set in my installers, but only because CD demands it. Setting it causes a fair number of install failures, particular in install/repair/uninstall cycles. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Alec Swan [mailto:alecs...@gmail.com] Sent: Thursday, March 15, 2012 11:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting MsiLogFileLocation property The following thread implied that the file log location can be set through MsiLogFileLocation property in WIX: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Msi-Logging-td707004.html#a707011 But it sounds like Rob is saying this is not possible. So, how can I reliably enable MSI logging programmatically in WIX code and ideally set the location of the log file? We need to support Windows XP SP2 and higher. Thanks, Alec On Thu, Mar 15, 2012 at 10:05 AM, Christopher Painter chr...@iswix.com wrote: I don't know if this is common knowledge but I don't set the MsiLogging property anymore. There' s a known bug in Windows 7 where Explorer / Shell can lose reference to the installer log file location and it causes the installer to crash out. It can manifest itself on uninstall which means you are stuck unless you run the uninstall from the command line passing in an explicit path. From: Rob Mensching r...@robmensching.com Sent: Thursday, March 15, 2012 11:02 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Setting MsiLogFileLocation property I don't think you can set the log file using MsiLogFileLocation. I think it *gets* set to the log file location. You can force your package to require MSI 4.0 by setting the Package/InstallerVersion attribute. On Wed, Mar 14, 2012 at 9:10 PM, Alec Swan alecs...@gmail.com wrote: Hello, I need to enable verbose logging and configure MSI log file location. I am currently doing this by adding the following properties inside of my .wxs file: Wix Product Property Id
Re: [WiX-users] Multi-language installer
Transforms are transforms - they apply to the MSI file, not just the UI. I've changed Shortcut names, custom action conditions and (I'm pretty sure) ProductName using transforms. Phil W -Original Message- From: Dave Mateer [mailto:dave_mat...@ntm.org] Sent: Tuesday, March 13, 2012 7:26 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Multi-language installer Having already done some research, it appears that single-MSI multi-language installers are not supported by Windows Installer, and thus, not by WiX. However, the latest information I could find that actually looked definitive was from 2007, and I'm wondering if there has been any progress since that time, or if perhaps there is a solution for my very simple case. 99.9% of the payload in my installer is the same between the various languages. In fact, it is being called silently from a bootstrapper so I don't even care about UI transformation. The ONLY thing that needs to be translated is the product name as it appears in Add/Remove Programs and the shortcut (including the folder), i.e.: Product Name=!(loc.ProductName)/ Package Description=!(loc.ProductName)/ Directory Id=ProgramMenuFolder Directory Id=ApplicationProgramsFolder Name=!(loc.ProductName)/ /Directory DirectoryRef Id=ApplicationProgramsFolder Component Shortcut Name=!(loc.ProductName) /Component /DirectoryRef Is there any way to officially do this without duplicating the content? I have four languages to support, and the content is over 400 MB, so it would be a real waste to create four separate installers. The language of the application itself can be switched at runtime (using localization resource files), so we really want to create one DVD with our single installer. The most helpful workarounds I found (from 2007) are: http://jpassing.com/2007/06/14/authoring-multi-language-msi-packages/ http://wix.tramontana.co.hu/tutorial/transforms/morphing-installers Is this still the state of things? Would those transforms even work with non-UI transforms? Any better ideas? Thanks, Dave -- 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 *** 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
Re: [WiX-users] CustomActionData
CustomActionData is actually per custom action, although it sometimes appears that there is only one for all custom actions. Basically, if you have a custom action called Fred that you want to pass data into, you create an immediate set-a-property custom action (type 51 in MSI) that sets Fred to the data (yes, you create a property that has the same name as your custom action). Inside the deferred custom action Fred your CustomActionData property will be that data. Some tools (like Visual Studio setups) hide these internal details, can't remember if WiX does. Phil W -Original Message- From: Parkes, Kevin [mailto:kevin.par...@wacom.eu] Sent: Friday, March 09, 2012 9:23 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] CustomActionData I have a couple of deferred custom actions to which I need to pass parameters. Obviously for a single custom action I'd just set the CustomActionData property. Do I have to pack all parameters for each custom action into CustomActionData and have each action extract its own parameters somehow or is there another way to do it? 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 *** 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). -- 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] Configuring service being installed fails during silent upgrade (but passes when UI is enabled)
Assuming that you have that custom action in both old and new setups, take a look at the entire log. It might be happening when the old install is being removed and the service is really not there because the condition doesn't look right to me, if my thinking is correct. NOT ((REMOVE~=ALL) AND (NOT UPGRADINGPRODUCTCODE)) When the old product is being upgraded, REMOVE=ALL is true and UPGRADINGPRODUCTCODE is true. That expression evaluates to NOT (true and (not true)), and that entire expression is therefore true, so that custom action is running when the old product is being uninstalled. Phil W -Original Message- From: Sameer Arora [mailto:arora...@gmail.com] Sent: Friday, March 09, 2012 10:20 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Configuring service being installed fails during silent upgrade (but passes when UI is enabled) Ping... Appreciate all suggestions and pointers. On Wed, Feb 8, 2012 at 11:08 AM, Sameer Arora arora...@gmail.com wrote: Hi, I have a WiX 3.5 project that installs and starts a windows service and thereafter executes a custom action to configure the service using command line utility sc.exe that ships with the OS. This MSI can be used both for fresh install or major upgrade. It uses custom dialogs to capture user information in global properties (which can be passed from command line as well). For a fresh install, the MSI installation succeeds whether run in normal or quiet mode (UI enabled/suppressed). However, for a major upgrade, installation succeeds only in normal mode, but fails in quiet mode with sc.exe failing to find the installed service (error details below). My initial hunch was that with UI enabled, there is sufficient time lag between execution of service installation and configuring steps so that sc.exe succeeds in finding the service installed. In quiet mode OTOH, the steps may get executed too quickly for sc.exe to find the service installed and hence the failure. To test this, I tweaked the InstallExecuteSequence to increase the distance between StartServices and the custom action (even introduced a sleep in an intermediate custom action), but to no avail. I also looked into the InstallUISequence but couldn't see anything that might impact service installation or config steps. Any thoughts what could be the cause/remedy? Appreciate all pointers. Sameer OS is Win7, but not sure if OS is a factor here. --- Error from installation log: Begin ... MSI (s) (A0:0C) [08:50:40:235]: Executing op: CustomActionSchedule(Action=QtExecDeferred,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData=C:\Windows\SysWOW64\sc.exe sidtype service name unrestricted) MSI (s) (A0:7C) [08:50:40:278]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIB16A.tmp, Entrypoint: CAQuietExec MSI (s) (A0:C0) [08:50:40:278]: Generating random cookie. MSI (s) (A0:C0) [08:50:40:283]: Created Custom Action Server with PID 7120 (0x1BD0). MSI (s) (A0:A8) [08:50:40:320]: Running as a service. MSI (s) (A0:A8) [08:50:40:322]: Hello, I'm your 32bit Elevated custom action server. CAQuietExec: OpenService FAILED 1060: CAQuietExec: CAQuietExec: The specified service does not exist as an installed service. CAQuietExec: CAQuietExec: Error 0x80070424: Command line returned an error. CAQuietExec: Error 0x80070424: CAQuietExec Failed CustomAction QtExecDeferred returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) ... --- Error from installation log: End WiX Code snippets: Begin !--Custom Action definition-- CustomAction Id=SetServiceSidToUnrestricted_CmdLine Property=QtExecDeferred Value='[SystemFolder]sc.exe sidtype $(var.agentHostServiceName) $(var.agentServiceSidType)' / CustomAction Id=QtExecDeferred BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/ ... !-- InstallExecuteSequence-- ... InstallInitialize Sequence=n / ... InstallServices Sequence=xVersionNT/InstallServices StartServices Sequence=x+1VersionNT/StartServices !--Run this custom action on install/upgrade/repair, do not run only on an uninstall -- Custom Action=QtExecDeferred After=StartServices ![CDATA[ NOT ((REMOVE~=ALL) AND (NOT UPGRADINGPRODUCTCODE)) ]] /Custom InstiallFinalize/ WiX Code snippets: End -- 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
Re: [WiX-users] Determining which OS is installed
Maybe and no. You should be looking at the Windows Installer properties for locations. There are properties such as ProgramFilesFolder and ProgramFiles64Folder that resolve to those locations at install time. In your case, the more useful one is the FileKey property for your file. http://msdn.microsoft.com/en-us/library/windows/desktop/aa368609(v=vs.85).aspx Your registry value is then something like [#filekey] (and add your #1) and that resolves to the path to the file wherever it was installed. Phil W -Original Message- From: Rick Hantz (Hotmail) [mailto:rick_ha...@hotmail.com] Sent: Wednesday, March 07, 2012 10:49 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Determining which OS is installed So would this work? I separated the command registry entry into two components. Component Id=RegShellOpenCommand32bit Guid=726CF30C-BC18-45A1-BAB1-3EEF08B8C10A Condition VersionNT64 = 600 /Condition RegistryKey Id=RegShellOpenCommand32' Root='HKCR' Key=\Shell\open\command' Action='createAndRemoveOnUninstall' Permission User=Administrators GenericAll=yes / Permission User=Users GenericAll=yes / RegistryValue Type='string' Value='C:\Program Files (x86)\\.exe %1' / /RegistryKey /Component Component Id=RegShellOpenCommand64bit Guid=9ADF87DE-D138-4AF1-ADE9-BDCB21736A0E Condition VersionNT = 600/Condition RegistryKey Id='SmartListW32RegShellOpenCommand64' Root='HKCR' Key=\Shell\open\command' Action='createAndRemoveOnUninstall' Permission User=Administrators GenericAll=yes / Permission User=Users GenericAll=yes / RegistryValue Type='string' Value='C:\Program Files (x86)\\.exe %1' / /RegistryKey /Component -Original Message- From: David Esiobu [mailto:david.esi...@citrix.com] Sent: Wednesday, March 07, 2012 10:18 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Determining which OS is installed Hi Rick, Please see the documentation for WiX preprocessor statements: http://wix.sourceforge.net/manual-wix3/preprocessor.htm Note that you can't use MSI properties there because preprocessor statements affect the build process, not the runtime behavior. Hope that helps, David -Original Message- From: Rick Hantz (Hotmail) [mailto:rick_ha...@hotmail.com] Sent: Wednesday, March 07, 2012 1:00 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Determining which OS is installed I need to install an URL handler, which means different path entries if you have a 32 or 64bit OS installed. I tried: ?if (VersionNT64 = 600) ? RegistryKey Id='RegShellOpenCommand' Root='HKCR' Key='SmartList\Shell\open\command' Action='createAndRemoveOnUninstall' Permission User=Administrators GenericAll=yes / Permission User=Users GenericAll=yes / RegistryValue Type='string' Value='C:\Program Files (x86)\\.exe %1' / /RegistryKey ?else? RegistryKey Id='SmartLRegShellOpenCommand' Root='HKCR' Key=\Shell\open\command' Action='createAndRemoveOnUninstall' Permission User=Administrators GenericAll=yes / Permission User=Users GenericAll=yes / RegistryValue Type='string' Value='C:\Program Files\\.exe %1' / /RegistryKey But it errors at (VersionNT64 = 600). I'm a first time WiX user, using VS11 beta and one of the latest 3.6 beta builds.. Appreciate any help. Thanks, RickH _ I am using the Free version of SPAMfighter http://www.spamfighter.com/len . SPAMfighter has removed 102072 of my spam emails to date. Do you have a slow PC? http://www.spamfighter.com/SLOW-PCfighter?cid=sigen Try free scan! -- 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 -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 102072 of my spam emails to
Re: [WiX-users] General Installer question
Raymond agrees with you ;=) http://blogs.msdn.com/b/oldnewthing/archive/2007/09/17/4948130.aspx Phil W -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Tuesday, February 28, 2012 7:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] General Installer question Generally: Don't. If it's user data leave it. Not always the most ideal but the best option from installation point of view. On Mon, Feb 27, 2012 at 10:04 PM, victorwhiskey victorhwhis...@yahoo.comwrote: What's the opinion on leaving files/directories behind on uninstall? Applications write files/directories the installer doesn't know about, especially user specific ones. But the installer doesn't know about the files/directories created. What's the best way to go about cleaning them? Enumerating through all users could be a lot...? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/General-Installer-question-tp7324586p7324586.html Sent from the wix-users mailing list archive at Nabble.com. -- 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 -- virtually, Rob Mensching - http://RobMensching.com LLC -- 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 *** 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
Re: [WiX-users] Problem with MSCOMCT2 OCX/MSM
6.1.98.16 was a security update, and I don't believe new merge modules were ever supplied. The Windows Installer default file replacement rules mean that 6.0.88.4 should never replace a 6.1.98.16. I suspect that something non-standard is going on. You're not updating with a REINSTALLMODE specification that includes a? Phil W -Original Message- From: Øivind Flaten [mailto:oivind.fla...@visma.com] Sent: Wednesday, February 22, 2012 5:51 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with MSCOMCT2 OCX/MSM Hi. On Windows 7 64 bits version I have encountered a problem with our software. I've used the MSCOMCT2.MSM for quite a number of years. It contains version 6.0.88.4 of the MSCOMCT2.OCX. At a customer pc with Win 7 64 bit, they have installed a program which replace the OCX with a new version- 6.1.98.16. If we install our software after the other program it just replace the MSCOMCT2.OCX with the one from the MSM-file. I have been searching for a newer version of the MSCOMCT2.MSM but can't find it. Does anyone have any experience or tips on how to solve this problem? I had hope to find a new version of the MSCOMCT2.MSM file because then I could just replace the old one, but Thanks in advance. Regards, Oivind Flaten -- 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
Re: [WiX-users] Windows Installer and Process Environment Block
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
Re: [WiX-users] InstallValidate Action check Windows Service or not?
It depends on what you put in your ServiceControl for the service, but the do I need to show FilesInUse is smart enough to check the ServiceControl table in the MSI file, and if there's an entry that says stop at uninstall time then there's no need for FilesInUse because the service is going to be stopped anyway. Phil W -Original Message- From: william lee [mailto:wele...@gmail.com] Sent: Saturday, February 18, 2012 7:11 PM To: Rob Mensching Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] InstallValidate Action check Windows Service or not? Hi Rob, You are correct, my daemon process is totally invisible to user. Does this mean, we can assume Windows Service is more friendly to RM when uninstall than a daemon way? If it is true, then we should create all background worker process as Service then. Thanks! William L. On Sun, Feb 19, 2012 at 5:43 AM, Rob Mensching r...@robmensching.com wrote: I think the difference is Restart Manager not Windows installer. RM knows how to stop services and processes with a top level visible window (IIRC) so it doesn't complain about those. Your daemon is probably invisible and thus gets the less desirable behavior. From: william lee Sent: 2/18/2012 1:23 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] InstallValidate Action check Windows Service or not? Hi, I met a common problem when create an app installer. The app is running 24x7, like a daemon process. When Uninstall the app, the InstallValidate try trigger Files In Use dialog or Restart Manager, because it is still running when Uninstall. This is easy to understand. I just create a simple demo, If I create a native Windows Service by using ATL, and a MSI by Wix to install it, start the service. Then during Uninstall, even the service is still running, I can see the process in Task Manager as well, Windows Installer just uninstall successfully. The service was stopped and removed, files got deleted. InstallValidate does not pop up Files In Use or Restart Manager during Uninstall. Does it mean, InstallValidate treat Windows Service and Windows Application differently? I'm testing on Win7 Pro, with UAC off. Thanks, William L. -- 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 *** 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
Re: [WiX-users] dealing with functions that throw exceptions
C++ custom actions have a defined signature that includes expected return values. http://msdn.microsoft.com/en-us/library/windows/desktop/aa368072(v=vs.85).aspx You may be able to store the message in a property or anywhere else (registry?) to retrieve later. Phil W -Original Message- From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] Sent: Sunday, February 12, 2012 6:37 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] dealing with functions that throw exceptions Hi; I am currently writing a custom action dll in c++ for an installer. I've got a function provided that throws c++ exceptions. What I'd like to do is return S_FALSE plus the exception message if an exception is thrown. Has anyone got any macrows to do this? Any help appreciated. Cheers Sean. -- 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). -- 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
Re: [WiX-users] Optionally keep a file on MajorUpgrade
Where is your RemoveExistingProducts sequenced? If it was towards the end, the
upgrade would behave more like an update and replace only files with higher
versions and not replace altered data files (when they have the same component
guid).
BTW Permanent really means permanent. It's a setting in the project, but once
you install a component that's permanent it's permanent on the system. Why
expect it mean not permanent?
Phil W
-Original Message-
From: Alexander Krivács Schrøder [mailto:alexander.schro...@mermaid.no]
Sent: Wednesday, February 08, 2012 6:11 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Optionally keep a file on MajorUpgrade
I have an installer that installs a configuration file, like so:
Feature Id=AppName.Feature Title=Application Name Level=1
Feature Id=AppConfig.Feature Level=1 Display=hidden
Component Id=AppConfig.Component
Guid={E56D54A5-0646-4D0C-9F95-73F82E293705} Directory=INSTALLLOCATION
File Source=$(var.AppName.TargetPath).config /
/Component
Condition Level=0KEEP_EXISTING_CONFIG = 1 AND
APPCONFIGEXISTS/Condition
/Feature
...
/Feature
The APPCONFIGEXISTS is brought out like so:
!-- Check for existing application configuration file --
Property Id=APPCONFIGEXISTS
DirectorySearch Id=CheckAppConfigDir Path=INSTALLDIR Depth=0
FileSearch Id=CheckAppConfigFile
Name=$(var.AppName.TargetFileName).config /
/DirectorySearch
/Property
The KEEP_EXISTING_CONFIG is a command-line variable, sent in to msiexec.exe.
This configuration alone does not do the trick (obviously, since I'm asking
here) as the configuration file is removed by the next version of the MSI
before it starts its installation. The Component element has a Permanent
property, but with that one enabled, it certainly does not behave as expected
(does not get removed on uninstall, never gets replaced on upgrade, regardless
of what the value of KEEP_EXISTING_CONFIG is).
Any ideas?
--
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
*** 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
Re: [WiX-users] Odd Service Stop Error
It could be a services dependency - you'd see that in the services applet.
Make sure that there isn't something in the ServiceControl table even if it's
just spaces that might not show. I've noticed that spaces can affect this kind
of thing. It might literally be trying to stop a service that's one blank space
in the table.
Phil W
-Original Message-
From: Richard Martin [mailto:rsmart8...@gmail.com]
Sent: Tuesday, February 07, 2012 9:37 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Odd Service Stop Error
I have an installer that stops three services, but get an error:
MSI (s) (90:44) [12:11:17:558]: Executing op:
ActionStart(Name=StopServices,Description=Stopping
services,Template=Service: [1])
Action 12:11:17: StopServices. Stopping services
MSI (s) (90:44) [12:11:17:558]: Executing op:
ProgressTotal(Total=4,Type=1,ByteEquivalent=130)
MSI (s) (90:44) [12:11:17:558]: Executing op:
ServiceControl(,Name=GGUpstreamProcessor,Action=2,Wait=1,)
StopServices: Service: SMS|GlobalGuest Upstream Processor
MSI (s) (90:44) [12:11:18:574]: Executing op:
ServiceControl(,Name=PsmsGrmcLegacyReader,Action=2,Wait=1,)
MSI (s) (90:44) [12:11:18:574]: Executing op:
ServiceControl(,Name=PsmsGGLegacyReader,Action=2,Wait=1,)
MSI (s) (90:44) [12:11:18:574]: Executing op:
ServiceControl(,,Action=2,Wait=1,)
StopServices: Service:
Error 1921. Service '' () could not be stopped. Verify that you have
sufficient privileges to stop system services.
The three services I want to stop are listed in the log as the first three
ServiceControl ops above, but it looks like a fourth was thrown in for
free. I have looked at the ServiceControl table in Orcas and there are only
the three rows I expect to see. Can anyone give me a clue what I should
look for to track down this fourth ServiceControl op?
Thanks!
Rick Martin
Component Id=C.U.LegacyEventReaderService
Guid={73579CDF-DAC9-4814-9306-584D33768825}
File
Id = F.U.LegacyEventReaderService
Source = $(var.PSMS.CRMBridge.LegacyEventReaderService.TargetPath)
Vital= yes
Checksum = yes
KeyPath = yes /
ServiceInstall
Id=S.LegacyEventReaderService
Name=!(loc.UpstreamServiceId)
DisplayName=!(loc.UpstreamServiceName)
Type=ownProcess
Start=auto
ErrorControl=normal
Description=!(loc.UpstreamServiceDescription)
Account=[SERVICEACCOUNT]
Password=[SERVICEPASSWORD]
Vital=yes
ServiceDependency Id=Netman/
/ServiceInstall
ServiceControl
Id=S.Stop.LegacyEventReaderService
Name=!(loc.UpstreamServiceId)
Stop=both
Wait=yes
Remove=both /
ServiceControl
Id=S.Stop.OldLegacyEventReaderService
Name=!(loc.UpstreamServiceOldId1)
Stop=both
Wait=yes
Remove=both /
ServiceControl
Id=S.Stop.Old2LegacyEventReaderService
Name=!(loc.UpstreamServiceOldId2)
Stop=both
Wait=yes
Remove=both /
/Component
--
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
*** 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!
Re: [WiX-users] Question from a WiX Votive newbie
You know that MSI setup projects in Visual Studio are disappearing anyway, right? See retirement note at the top of these forums: http://social.msdn.microsoft.com/Forums/en-US/winformssetup/threads Phil W -Original Message- From: Michael Powell [mailto:mwpowel...@gmail.com] Sent: Thursday, February 02, 2012 6:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question from a WiX Votive newbie I am new to WiX Votive but not new to installers or setups by any means. Briefly, I am getting spun up on WiX as a plausible upgrade from the basic Setup (VDPROJ) project that Visual Studio 2010 offices out of the box. Can someone tell me briefly, how does it compare? Besides doing what the Setup project does by automatically detecting dependencies, generating an MSI output, folder organization, registry actions, and other custom actions... I am interested that WiX Votive supports custom dialogs? Also that it can be incorporated into a solution seamlessly during a Continuous Integration build using MSBuild is a huge plus (you don't even know...). Thank you... Best regards, Michael Powell -- 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 *** 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). -- 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
Re: [WiX-users] unable to start a service through MSI
Service can't start can be a dependency issue. A service that's dependent on Dlls being installed to the GAC or to SxS (C++ runtimes) will fail when MSI starts because StartServices is before these are committed to the system. It will start from Service Control Panel afterwards (if there's no rollback) because now the dependencies are installed. Phil W -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Wednesday, February 01, 2012 4:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] unable to start a service through MSI The error message is pretty generic, the service can't start for almost any reason. We have MSIs that run in full dialog mode so there is a dialog popped when the service fails to start with the error you are seeing in the eventlog, with a retry and cancel options. When you get this dialog go to the Services control panel and manual start the service, you will often get a more meaningful error. If you don't get the dialog with the error, change your MSI so it does not try start the service, and debug the startup when the install is finished Michael -Original Message- From: Rajesh Khetan [mailto:rajesh.khe...@microsoft.com] Sent: Thursday, 2 February 2012 10:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] unable to start a service through MSI Hi, I am currently trying to get my service started as a part of MSI install and am unable to do so. In the event viewer, I see the following error: Product: Myservice Cache Service -- Error 1920. Service ' Myservice ' (Myservice) failed to start. Verify that you have sufficient privileges to start system services. However, I am logged in as admin. Also, if I simply install the service and start the service manually, I am able to do that. I appreciate any input to help me figure out what I might be doing wrong or missing. One additional data about my service is: I am trying to install the service under account NT AUTHORITY\NETWORK SERVICE (Property SERVICEACCOUNT = 'NT AUTHORITY\NETWORK SERVICE' below) Thanks a lot for your help. Rajesh PS: Here is a snippet from my WXS file: Directory Id='TARGETDIR' Name='SourceDir' Component Id=' MyserviceCacheComponent' Guid='my guid' !-- The files to be installed -- File Id='Myservice.exe' Name='Myservice.exe' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.exe' / File Id='Myservice.pdb' Name='Myservice.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\Myservice.pdb' / File Id='MyservicePf.dll' Name='MyservicePf.dll' SelfRegCost='1' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.dll' / File Id='MyservicePf.pdb' Name='MyservicePf.pdb' DiskId='1' Source='$(var.INETROOT)\target\$(var.BUILDTYPE)\$(var.BUILDTARGET)\MyservicePf.pdb' / RemoveFile Id='REM_MYSERVICE_XML' Name='Myservice_Cache_Service.xml' On='uninstall'/ ServiceControl Id='Myservice_Cache_Service' Name='Myservice' Start='install' Stop='both' Remove='both' Wait='no'/ ServiceInstall Id='Myservice_Cache_Service' Name='Myservice' DisplayName='Myservice' Type='ownProcess' Start='auto' ErrorControl='normal' Account='[SERVICEACCOUNT]' Description='Myservice Cache Service'/ ... /Component /Directory -- 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 -- 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
Re: [WiX-users] msp patch does not update one of files
And in the verbose log, see if there are any SELMGR entries. They indicate that you've broken component rules during a patch by deleting a component. Otherwise look at the log to see what it says about that particular file and why it didn't replace it. Phil W -Original Message- From: Fyodor Koryazhkin [mailto:fyodor...@gmail.com] Sent: Sunday, January 29, 2012 12:11 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] msp patch does not update one of files Hi, To find out why file is not being updated you can do the following: 1. Examine log file. 2. Apply patch to the target image at design time: a. Open target image in ORCA b. Open Transforms - View Patch c. All changed tables, rows and columns will be marked in green rectangle d. Check version, sequence and language for suspicious file. -- Regards, Fyodor Koryazhkin.. -- 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 *** 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). -- 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
Re: [WiX-users] MSI runtime error code 2343
You might need an Error table in your MSI file. I think an empty path is an error related to the SQL query not finding anything. Error should be a standard table, but the log seems to think there isn't one, assuming that really is the issue. I thought WiX used the SDK's schema.msi as a base? Phil W -Original Message- From: T. Kuro Kurosaka [mailto:k...@basistech.com] Sent: Friday, January 20, 2012 2:17 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] MSI runtime error code 2343 I am trying to modify the InstallDir template by replacing LicenseAgreementDlg with a new dialog that is a modified version of BrowseDlg with which the user would specify the directory where our license file can be found. My prototype fails just after hitting Next in WelcomeDlg with the unexpected error popup which quotes error code 2343. I ran the MSI with msiexec to collect the log. But the log doesn't tell me much. The most detailed message seems to be just: DEBUG: Error 2343: Specified path is empty. It doesn't tell me what path it is talking about. I reviewed all property values that the logger dumped after the error message, and the paths look good. How can I trace the error further from here? Below are messages surrounding the error message in question: MSI (c) (78:38) [13:12:01:764]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: Registry MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: BindImage MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: ProgId MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: PublishComponent MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: SelfReg MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: Extension MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: Font MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: Shortcut MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: Class MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: Icon MSI (c) (78:38) [13:12:01:764]: Note: 1: 2205 2: 3: TypeLib MSI (c) (78:38) [13:12:01:764]: Note: 1: 2727 2: MSI (c) (78:D0) [13:12:05:670]: Note: 1: 2205 2: 3: Error MSI (c) (78:D0) [13:12:05:670]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2898 Info 2898.For WixUI_Font_Title textstyle, the system created a 'Tahoma' font, in 0 character set, of 14 pixels height. MSI (c) (78:D0) [13:12:05:670]: Note: 1: 2343 MSI (c) (78:D0) [13:12:05:670]: Note: 1: 2205 2: 3: Error MSI (c) (78:D0) [13:12:05:670]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2343 DEBUG: Error 2343: Specified path is empty. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2343. The arguments are: , , MSI (c) (78:D0) [13:12:07:654]: Note: 1: 2205 2: 3: Error MSI (c) (78:D0) [13:12:07:654]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (c) (78:D0) [13:12:07:654]: Product: Rosette Web Service 64 Bit -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2343. The arguments are: , , Action ended 13:12:07: WelcomeDlg. Return value 3. MSI (c) (78:50) [13:12:07:654]: Doing action: FatalError MSI (c) (78:50) [13:12:07:654]: Note: 1: 2205 2: 3: ActionText Action 13:12:07: FatalError. Action start 13:12:07: FatalError. Action 13:12:07: FatalError. Dialog created Action ended 13:12:09: FatalError. Return value 2. Action ended 13:12:09: INSTALL. Return value 3. -- 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 *** 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
Re: [WiX-users] Completely revert installation on install failure
In the ServiceControl element that starts your service, what's your Wait value? It's not documented in MSDN, but AFAIK a Wait value of 1 causes a wait for the Service to start successfully and if it fails the install will roll back. Phil W -Original Message- From: Jeremy Farrell [mailto:jeremy.farr...@oracle.com] Sent: Saturday, January 14, 2012 4:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Completely revert installation on install failure Yes, David Watson did at 2012-01-11 18:09:28 GMT: Rollback should and does happen automatically. If you have any custom actions they need to cater for this. What does a verbose log say? How are you installing the service, are you using the ServiceInstall element? From: Kevin Hebert [mailto:ke...@legendary-immersion.com] Anyone have any suggestions about this? Thank you. On 1/11/2012 12:06 PM, AxiomaticImpact wrote: My installer is installing a service (which starts automatically upon installation) and a program. Now, if the install fails for any reason, the service is still installed, but fails to start. How can I go about doing a complete rollback upon failure? Is a custom action that calls the installers uninstall portion feasible? Thanks. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Log in won't cause replication of the keys. An earlier post mentioned that you need an advertised shortcut. Phil W -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, January 13, 2012 8:06 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Dan Gough Cc: McCain, Jon Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ !--These two entries keep the install from re-running or repairing itself when the installing user logs back in.-- RegistryValue Id=ctd_activesetup_HKCU_COPY_1 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_HKCU_COPY_2 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ /Component Component Id=ctd_ieplugin_hkcu_menuext_context Guid=327241A1-ECFF-454D-A8EC-34E0BF616904 SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ /Component The OS I am running this on is Windows 7 64 Bit. The installing user is also in the local admin group but the others users are not. Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, January 12, 2012 7:12 PM To: Dan Gough; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Then there's the case of Office AddIns that allowed either HKCU or HKLM in 2003, took away in 2007 ( and put it back with a hotfix and enabling registry value ) and really put it back in 2010 leaving one hell of a mess for us installer guys to deal with. So, yes, YMMV... in the event it really needs to be HKCU like the poster asserted then my response below will help. From: Dan Gough goug...@gmail.com Sent: Thursday, January 12, 2012 5:21 PM To: chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.com wrote: The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
There are other triggers in the MSI that can cause install on demand from the MSI, advertised COM being one, and I think file extensions do it too, but I don't know if that's an option for this particular issue. Of course Active Setup can do it, yes, maybe that's a solution, getting Windows to run a command line often is ;) Phil From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, January 13, 2012 12:40 PM To: Wilson, Phil; General discussion for Windows Installer XML toolset.; Dan Gough Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Actually I just realized I've been saying it all. I've been implying that the repair approach and the active setup approach are mutually exclusive. In fact the active setup is just a way to trigger the repair through a command line when an advertised shortcut is unavailable. I'm sorry if I was unclear or if I was clear and now I'm just confusing myself. :-) From: Christopher Painter chr...@iswix.com Sent: Friday, January 13, 2012 2:33 PM To: Wilson, Phil phil.wil...@invensys.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install l've used the Active Setup technique and replication occurred right away when the user logged on. Make sure you are using a clean machine such as a snapshotted VM to ensure a good testing environment. It could be that replication already occurred and isn't occuring again because the Version value isn't changing/increasing. From: Wilson, Phil phil.wil...@invensys.com Sent: Friday, January 13, 2012 2:30 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, chr...@iswix.com chr...@iswix.com, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Log in won't cause replication of the keys. An earlier post mentioned that you need an advertised shortcut. Phil W -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, January 13, 2012 8:06 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Dan Gough Cc: McCain, Jon Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ !--These two entries keep the install from re-running or repairing itself when the installing user logs back in.-- RegistryValue Id=ctd_activesetup_HKCU_COPY_1 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_HKCU_COPY_2 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ /Component Component Id=ctd_ieplugin_hkcu_menuext_context Guid=327241A1-ECFF-454D-A8EC-34E0BF616904 SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ /Component The OS I am running this on is Windows 7
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
And the MSDN docs *recommend* RunOnce as a way to finish application setups. It does seem unfair for an AV product to decide to prevent completion of application setup. InstallShield uses the RunOnce key too, judging from search hits and their content. Phil W -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Friday, January 13, 2012 12:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068 Burn is a little different because it is designed to recover from power failures and unexpected reboots. To do that it writes to the RunOnce registry key up front. Other bootstrappers/chainers may not write to RunOnce except when a force reboot is required in the middle of the chain. Then the bootstrapper/chainer must write to RunOnce in order to complete the installation. If something (anti-virus in this case) kills processes writing to RunOnce then those other chainers could end up in a bad state if they didn't save their data before getting killed. Burn won't have that problem since it tries to register with RunOnce before modifying machine state. So, basically, Burn exposes the configuration problem that could leave other chainers in a bad state. Or maybe they would just work okay but you'd have to go figure out why they didn't resume after reboot. On Fri, Jan 13, 2012 at 4:36 AM, Nikolaj Steensgaard n...@panorama9.comwrote: On Fri, Jan 13, 2012 at 7:48 AM, Peter Hull peterhul...@hotmail.com wrote: Date: Thu, 12 Jan 2012 20:56:15 +0100 From: n...@panorama9.com I would start by digitally signing your burn bundle. The bundle is already signed with a Thawte code signing certificate The reported file name looks more like it's the extracted engine than your bundle itself. Have you signed the engine. I only think we have signed the bundle, so we are working on signing the engine and retesting to see if it makes a difference. Either should Trend Micro change there detection mechanism regarding the RunOnce key or the bundling framework of burn should change its default behavior . From the Trend docs I saw it seemed to suggest that 'Malware Behaviour Monitoring' could be turned off (indeed, terminating programs like this was not the default) and also that signed executables were exempt. So it maybe is a bug in Trend that means it doesn't work as documented? Maybe, but as this is the default setting for a Trend Micro installation it is quite a problem. The other thing is that other installers (InstallShield) don't seem to do this so does anyone understand how InstallShield handles the reboot issue? Don't know , but it could be that they don't look in the RunOnce key as default behavior in their engine and thereby don't have this issue ? Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Best Regards Nikolaj Steensgaard Panorama9 A/S Langebrogade 5 1411 Copenhagen K Phone: +45 7020 3565 Mobile: +45 2124 3040 n...@panorama9.com Panorama9 is an IT management platform that shows you everything you need to know about your assets, IT availability, security vulnerabilities, and non-compliant systems – from a single Dashboard that’s amazingly easy to monitor and interpret. Your organization can cut IT costs through improved uptime and as a cloud-based solution, there is no infrastructure to deploy or manage. For more information - www.panorama9.com -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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
Re: [WiX-users] X64 issue on uninstall
The FileAbsent means you've got some kind of sharing issue. Make sure you don't
have another component with the same guid or another product using it.
Phil W
-Original Message-
From: Yannick [mailto:abgrallyann...@free.fr]
Sent: Tuesday, January 10, 2012 12:07 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] X64 issue on uninstall
Hi,
1. Was the service executable removed?
No, it is still in my folder.
2. Was the service entry removed from the service applet.
The service entry is still present and the service is running (should be
stopped)
3. Are you using ServiceInstall elements to install/uninstall the service?
yes. Here are my settings:
ServiceInstall ErrorControl=normal Type=shareProcess DisplayName=My
Service Name=MyServer Start=auto Vital=yes /
fw:FirewallException Id=MyServerException Name=My Service
Port=[MYPORT] Profile=all Scope=localSubnet Protocol=tcp
IgnoreFailure=yes /
ServiceControl Id=MyServiceControl
Remove=uninstall Name=MyServer
Start=install Stop=uninstall /
4. What does the log say about the component state (as in Component:.
Request: Absent Action: )?
MSI (s) (B0:48) [15:02:55:420]: Component: My_Server; Installed: Local;
Request: Absent; Action: FileAbsent
MSI (s) (B0:48) [15:02:55:420]: Component:My_Server_Configuration;
Installed: Local; Request: Absent; Action: FileAbsent
I have a second service (instrument). This one is correctly uninstalled
MSI (s) (B0:48) [15:02:55:420]: Component: Client; Installed: Local;
Request: Absent; Action: Absent
MSI (s) (B0:48) [15:02:55:420]: Component: My_Instrument_Server; Installed:
Local; Request: Absent; Action: Absent
Thanks,
Yannick A
Wilson, Phil-2 wrote
That log extract is not necessarily anything to do with the problem.
1. Was the service executable removed?
2. Was the service entry removed from the service applet.
3. Are you using ServiceInstall elements to install/uninstall the service?
4. What does the log say about the component state (as in Component:.
Request: Absent Action: )?
Phil W
-Original Message-
From: Yannick [mailto:abgrallyannick@]
Sent: Monday, January 09, 2012 4:36 AM
To: wix-users@.sourceforge
Subject: [WiX-users] X64 issue on uninstall
Hi,
I'm using Wix to install my application. On a 32 bit compurer, install and
uninstall are going well.
On a 64 bit computer, install process is running well but I've got the
following message when uninstalling and so, some files (and service)
remain on the machine.
(part of my log)
MSI (s) (B0:48) [15:02:55:403]: Allowing uninstallation of shared
component:
{20BB7E11-C9DD-460C-B850-59A53A538D7B}. Other clients exist, but installed
to a different location
MSI (s) (B0:48) [15:02:55:403]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\CAMAG\CATS\Camag.Platypus.CommonMigration.dll'
folder had been blocked by the 1 mask argument (the folder pair's
iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:406]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\MyApplication\MyService.exe' folder had been
blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:407]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\MyApplication\MyApplication.exe' folder had been
blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:408]: Allowing uninstallation of shared
component:
{A76581EF-8A87-4460-BAFB-8D0058463277}. Other clients exist, but installed
to a different location
MSI (s) (B0:48) [15:02:55:408]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\CAMAG\CATS\' folder had been blocked by the 1 mask
argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:409]: Allowing uninstallation of shared
component:
{D15941A2-E643-433B-85B1-B0C7F720C3C8}. Other clients exist, but installed
to a different location
MSI (s) (B0:48) [15:02:55:409]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\CAMAG\CATS\PlatypusServer.exe' folder had been
blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:415]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\MyApplication\log4net.dll' folder had been blocked
by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:416]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\MyApplication\Help\MyFile.pdf' folder had been
blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
Thanks for your help.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/X64-issue-on-uninstall-tp7167663p7167663.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box
Re: [WiX-users] X64 issue on uninstall
That log extract is not necessarily anything to do with the problem.
1. Was the service executable removed?
2. Was the service entry removed from the service applet.
3. Are you using ServiceInstall elements to install/uninstall the service?
4. What does the log say about the component state (as in Component:.
Request: Absent Action: )?
Phil W
-Original Message-
From: Yannick [mailto:abgrallyann...@free.fr]
Sent: Monday, January 09, 2012 4:36 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] X64 issue on uninstall
Hi,
I'm using Wix to install my application. On a 32 bit compurer, install and
uninstall are going well.
On a 64 bit computer, install process is running well but I've got the
following message when uninstalling and so, some files (and service) remain on
the machine.
(part of my log)
MSI (s) (B0:48) [15:02:55:403]: Allowing uninstallation of shared component:
{20BB7E11-C9DD-460C-B850-59A53A538D7B}. Other clients exist, but installed to a
different location
MSI (s) (B0:48) [15:02:55:403]: WIN64DUALFOLDERS: Substitution in 'C:\Program
Files (x86)\CAMAG\CATS\Camag.Platypus.CommonMigration.dll'
folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib
member = 0).
MSI (s) (B0:48) [15:02:55:406]: WIN64DUALFOLDERS: Substitution in 'C:\Program
Files (x86)\MyApplication\MyService.exe' folder had been blocked by the 1 mask
argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:407]: WIN64DUALFOLDERS: Substitution in 'C:\Program
Files (x86)\MyApplication\MyApplication.exe' folder had been blocked by the 1
mask argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:408]: Allowing uninstallation of shared component:
{A76581EF-8A87-4460-BAFB-8D0058463277}. Other clients exist, but installed to a
different location
MSI (s) (B0:48) [15:02:55:408]: WIN64DUALFOLDERS: Substitution in 'C:\Program
Files (x86)\CAMAG\CATS\' folder had been blocked by the 1 mask argument (the
folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:409]: Allowing uninstallation of shared component:
{D15941A2-E643-433B-85B1-B0C7F720C3C8}. Other clients exist, but installed to a
different location
MSI (s) (B0:48) [15:02:55:409]: WIN64DUALFOLDERS: Substitution in 'C:\Program
Files (x86)\CAMAG\CATS\PlatypusServer.exe' folder had been blocked by the 1
mask argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:415]: WIN64DUALFOLDERS: Substitution in 'C:\Program
Files (x86)\MyApplication\log4net.dll' folder had been blocked by the 1 mask
argument (the folder pair's iSwapAttrib member = 0).
MSI (s) (B0:48) [15:02:55:416]: WIN64DUALFOLDERS: Substitution in 'C:\Program
Files (x86)\MyApplication\Help\MyFile.pdf' folder had been blocked by the 1
mask argument (the folder pair's iSwapAttrib member = 0).
Thanks for your help.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/X64-issue-on-uninstall-tp7167663p7167663.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual desktops
for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it
free! http://p.sf.net/sfu/Citrix-VDIinabox
___
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).
--
Write once. Port to many.
Get the SDK and tools to simplify
Re: [WiX-users] Querying the package andinstalled productarchitecture
No real error checking,just stuck together code using VS 2010 UpgradeCode as a
test:
#include msiquery.h
WCHAR pbuf [40] = {0};
UINT eres = MsiEnumRelatedProducts
(L{776922EE-1E34-36CE-A15B-82BB65DC183E}, 0, 0, pbuf);
WCHAR localpath [MAX_PATH+1] = {0};
DWORD plen = MAX_PATH;
eres = MsiGetProductInfo (pbuf, INSTALLPROPERTY_LOCALPACKAGE,
localpath, plen);
PMSIHANDLE hsum;
INT naught=0;
WCHAR buf [100] = {0};
DWORD len = 100;
UINT type=0;
UINT res = MsiGetSummaryInformation (0, localpath, 0, hsum);
if (ERROR_SUCCESS == res)
{
res = MsiSummaryInfoGetProperty (hsum, 7, type, naught, NULL,
buf, len);
}
-Original Message-
From: Alex Ivanoff [mailto:aivan...@vmware.com]
Sent: Friday, January 06, 2012 10:29 AM
To: chr...@iswix.com; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Querying the package andinstalled productarchitecture
Native C++.
-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Friday, January 06, 2012 11:23
To: General discussion for Windows Installer XML toolset.; General
discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Querying the package andinstalled
productarchitecture
There are methods on the automation objects that you can call to resolve a
product code that machines and upgrade code then get the file path to the
cached MSI for that product code and then open the database to get access to
the summary information stream and then access the template summary
property.
I'd give you samples but I'm not sure if you are using C++, VBScript or C#.
From: Alex Ivanoff aivan...@vmware.com
Sent: Friday, January 06, 2012 9:46 AM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Querying the package andinstalled
productarchitecture
I am sorry, I should have been more explicit in the question: given the
installed product upgrade code how do I find that product architecture?
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, January 05, 2012 18:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Querying the package andinstalled
productarchitecture
If it's working ok you should get a result something like Intel64;1033or
Intel;1033that tells you that.
Phil W.
-Original Message-
From: Alex Ivanoff [mailto:aivan...@vmware.com]
Sent: Thursday, January 05, 2012 10:30 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Querying the package andinstalled
productarchitecture
I think I figured out how to get package architecture throw Template
property of SummaryInfo, but I still cannot find a way to get installed
product architecture.
There are tools in the Windows SDK (I am currently using v7) that can
query an MSI database. Look especially at the vbs scripts, you can
invoke them with SQL to query properties and tables.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372865(v=vs.85).as
px
Gary
-Original Message-
From: Alex Ivanoff [mailto:aivan...@vmware.com]
Sent: Friday, December 30, 2011 11:19 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Querying the package and installed
productarchitecture
I need to be able to do it programmatically.
-Original Message-
From: McCain, Jon [mailto:jon.mcc...@inin.com]
Sent: Friday, December 30, 2011 07:31
To: General discussion for Windows Installer XML toolset.
Cc: McCain, Jon
Subject: Re: [WiX-users] Querying the package and installed product
architecture
1. Open the install in Orca
2. Click View - Summary Information 3. The architecture type is
listed under Platform.
Jon
-Original Message-
From: Alex Ivanoff [mailto:aivan...@vmware.com]
Sent: Thursday, December 29, 2011 6:17 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Querying the package and installed product
architecture
Is there a way to query the MSI package and/or installed product
architecture (x86 vs. x64)?
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo
Re: [WiX-users] Querying the package andinstalled productarchitecture
If it's working ok you should get a result something like Intel64;1033or Intel;1033that tells you that. Phil W. -Original Message- From: Alex Ivanoff [mailto:aivan...@vmware.com] Sent: Thursday, January 05, 2012 10:30 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Querying the package andinstalled productarchitecture I think I figured out how to get package architecture throw Template property of SummaryInfo, but I still cannot find a way to get installed product architecture. There are tools in the Windows SDK (I am currently using v7) that can query an MSI database. Look especially at the vbs scripts, you can invoke them with SQL to query properties and tables. http://msdn.microsoft.com/en-us/library/windows/desktop/aa372865(v=vs.85).as px Gary -Original Message- From: Alex Ivanoff [mailto:aivan...@vmware.com] Sent: Friday, December 30, 2011 11:19 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Querying the package and installed productarchitecture I need to be able to do it programmatically. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, December 30, 2011 07:31 To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Querying the package and installed product architecture 1. Open the install in Orca 2. Click View - Summary Information 3. The architecture type is listed under Platform. Jon -Original Message- From: Alex Ivanoff [mailto:aivan...@vmware.com] Sent: Thursday, December 29, 2011 6:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Querying the package and installed product architecture Is there a way to query the MSI package and/or installed product architecture (x86 vs. x64)? -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ 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). -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error2819
That error message should have more detail if you produce a verbose log. The error is: 2819 Control [3] on dialog [2] needs a property linked to it. So the log should tell you the name of the control. Phil W -Original Message- From: Rohini S [mailto:roh...@lucidindia.com] Sent: Wednesday, January 04, 2012 5:38 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error2819 The Code which i used to add a new dialog in the setup. Product.wxs: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=996b7490-325e-4890-b412-2119f36dd9dc Name=Install Language=1033 Version=1.0.0.0 Manufacturer=Install UpgradeCode=06b2d9eb-e790-4dd1-99f0-42051062b1c4 Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=media1.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLLOCATION Name=Install !-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -- Component Id=ProductComponent Guid=95409870-9e37-4611-802e-15c15c05ba84 File Id=MyApplicationFile Name=$(var.NewForm.TargetFileName) Source=$(var.NewForm.TargetPath) DiskId=1 KeyPath=yes Compressed=yes / /Component /Directory /Directory /Directory Feature Id=ProductFeature Title=Install Level=1 !-- TODO: Remove the comments around this ComponentRef element and the Component above in order to add resources to this installer. -- ComponentRef Id=ProductComponent / !-- Note: The following ComponentGroupRef is required to pull in generated authoring from project references. -- ComponentGroupRef Id=Product.Generated / /Feature Property Id=MyWIXUI_INSTALLDIR Value=INSTALLLOCATION /Property UIRef Id=MyWixUI_InstallDir / /Product /Wix MyWixUI_InstallDir.wxs Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment UI Id=MyWixUI_InstallDir TextStyle Id=WixUI_Font_Normal FaceName=Tahoma Size=8 / TextStyle Id=WixUI_Font_Bigger FaceName=Tahoma Size=12 / TextStyle Id=WixUI_Font_Title FaceName=Tahoma Size=9 Bold=yes / Property Id=DefaultUIFont Value=WixUI_Font_Normal / Property Id=WixUI_Mode Value=InstallDir / DialogRef Id=BrowseDlg / DialogRef Id=DiskCostDlg / DialogRef Id=ErrorDlg / DialogRef Id=FatalError / DialogRef Id=FilesInUse / DialogRef Id=MsiRMFilesInUse / DialogRef Id=PrepareDlg / DialogRef Id=ProgressDlg / DialogRef Id=ResumeDlg / DialogRef Id=UserExit / Publish Dialog=BrowseDlg Control=OK Event=DoAction Value=WixUIValidatePath Order=31/Publish Publish Dialog=BrowseDlg Control=OK Event=SpawnDialog Value=InvalidDirDlg Order=4![CDATA[WIXUI_INSTALLDIR_VALID1]]/Publish Publish Dialog=ExitDialog Control=Finish Event=EndDialog Value=Return Order=9991/Publish Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=LicenseAgreementDlgNOT Installed/Publish Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=CheckDlgInstalled AND PATCH/Publish Publish Dialog=LicenseAgreementDlg Control=Back Event=NewDialog Value=WelcomeDlg1/Publish Publish Dialog=LicenseAgreementDlg Control=Next Event=NewDialog Value=MyInstallDirDlgLicenseAccepted = 1/Publish Publish Dialog=MyInstallDirDlg Control=Back Event=NewDialog Value=LicenseAgreementDlg1/Publish Publish Dialog=MyInstallDirDlg Control=Next Event=SetTargetPath Value=[WIXUI_INSTALLDIR] Order=11/Publish Publish Dialog=MyInstallDirDlg Control=Next Event=DoAction Value=WixUIValidatePath Order=2NOT WIXUI_DONTVALIDATEPATH/Publish Publish Dialog=MyInstallDirDlg Control=Next Event=SpawnDialog Value=InvalidDirDlg Order=3![CDATA[NOT WIXUI_DONTVALIDATEPATH AND WIXUI_INSTALLDIR_VALID1]]/Publish Publish Dialog=MyInstallDirDlg Control=Next Event=NewDialog Value=CheckDlg Order=4WIXUI_DONTVALIDATEPATH OR WIXUI_INSTALLDIR_VALID=1/Publish Publish Dialog=MyInstallDirDlg Control=ChangeFolder Property=_BrowseProperty Value=[WIXUI_INSTALLDIR] Order=11/Publish Publish Dialog=MyInstallDirDlg Control=ChangeFolder Event=SpawnDialog Value=BrowseDlg Order=21/Publish Publish Dialog=CheckDlg Control=Back Event=NewDialog Value=MyInstallDirDlg1/Publish Publish Dialog=CheckDlg Control=Next Event=NewDialog Value=VerifyReadyDlg1/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=CheckDlg Order=1NOT Installed/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=MaintenanceTypeDlg Order=2Installed AND NOT PATCH/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=WelcomeDlg Order=2Installed AND PATCH/Publish Publish Dialog=MaintenanceWelcomeDlg Control=Next Event=NewDialog Value=MaintenanceTypeDlg1/Publish Publish Dialog=MaintenanceTypeDlg Control=RepairButton Event=NewDialog Value=VerifyReadyDlg1/Publish Publish Dialog=MaintenanceTypeDlg Control=RemoveButton Event=NewDialog Value=VerifyReadyDlg1/Publish Publish Dialog=MaintenanceTypeDlg Control=Back Event=NewDialog Value=MaintenanceWelcomeDlg1/Publish Property Id=ARPNOMODIFY Value=1 / /UI UIRef Id=WixUI_Common / /Fragment /Wix
Re: [WiX-users] RemoveExistingProducts after the InstallFinalize action still needed so that Major Upgrades don't remove assembly from GAC ?
There is a hotfix available, not sure if this has been mentioned in this thread. http://support.microsoft.com/kb/972397/EN-US More Info says you also need http://support.microsoft.com/kb/983280 Phil W -Original Message- From: CristianG [mailto:cristian.gherghine...@gmail.com] Sent: Tuesday, January 03, 2012 1:09 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] RemoveExistingProducts after the InstallFinalize action still needed so that Major Upgrades don't remove assembly from GAC ? I've done some more tests and it seems that on Windows Installer 4.5 the assembly is removed from GAC after a major upgrade. Good to see that at least on 5.0 got fixed. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RemoveExistingProducts-after-the-InstallFinalize-action-still-needed-so-that-Major-Upgrades-don-t-re-tp7137858p7146124.html Sent from the wix-users mailing list archive at Nabble.com. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ 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). -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Querying the package and installed productarchitecture
I think the sample VBScripts in the SDK are useful to the extent that they describe the flow for folks that aren't familiar with how to use the APIs. Exporting an MSI table with no guidance at all is a pain, but I can see from WiExport.vbs that I open the database, do an OpenView with a Select query, do a View fetch, and then get each record's string data. In this particular SummaryInfo case, WiSumInf.vbs is quite instructive on how to get the SummaryInfo for the Platform. I'm not a language purist to the extent that I'll ignore a working example, whatever language it might be! Phil W -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, December 30, 2011 5:56 PM To: g...@gocek.org; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Querying the package and installed productarchitecture It's nearly 2012 and I'd much rather use C# and DTF. Perhaps in 1999 those VBScript files were interesting and useful. I can understand the msi.h / msi.lib is still good for the unmanaged C++ guys out there and is certainly the foundation for DTF but the whole VBScript / ActiveScript / COM / Automation Interface world can RIP for all I care. Same goes for the POS Win32_Product class. From: Gary Gocek g...@gocek.org Sent: Friday, December 30, 2011 7:28 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Querying the package and installed productarchitecture There are tools in the Windows SDK (I am currently using v7) that can query an MSI database. Look especially at the vbs scripts, you can invoke them with SQL to query properties and tables. http://msdn.microsoft.com/en-us/library/windows/desktop/aa372865(v=vs.85).as px Gary -Original Message- From: Alex Ivanoff [mailto:aivan...@vmware.com] Sent: Friday, December 30, 2011 11:19 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Querying the package and installed productarchitecture I need to be able to do it programmatically. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, December 30, 2011 07:31 To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Querying the package and installed product architecture 1. Open the install in Orca 2. Click View - Summary Information 3. The architecture type is listed under Platform. Jon -Original Message- From: Alex Ivanoff [mailto:aivan...@vmware.com] Sent: Thursday, December 29, 2011 6:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Querying the package and installed product architecture Is there a way to query the MSI package and/or installed product architecture (x86 vs. x64)? -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ 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
Re: [WiX-users] Querying the package and installed productarchitecture
I'm not suggesting using the code in that way, only that any complete example
is a roadmap of how to perform a task in terms of the APIs that are called and
in what order.
What's the status of DTF these days? Does Microsoft support it? Because whether
DTF rocks or not is irrelevant when a company has rules that severely restrict
or prohibit distributing 3rd party code or Dlls. Two companies I've been
involved with both prohibit any 3rd party code: these are environments where
the SDL (security) process matters, where 3rd party code must have a support
contract and pass security audits and so on. It's ok to use these types of
tools for internal development but shipping them to customers is not allowed.
So knowing how to P/Invoke or use native Win32 APIs is necessary.
Phil W
-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Tuesday, January 03, 2012 3:10 PM
To: General discussion for Windows Installer XML toolset.; General discussion
for Windows Installer XML toolset.
Subject: Re: [WiX-users] Querying the package and installed productarchitecture
Ok, let's pretend I'm a .NET developer who doesn't know anything about MSI
and I follow you're advice of reading through WiExport.vbs to understand
the flow of exporting an IDT file.
First problem I'm going to hit is trying to add a reference to
WindowsInstaller.Installer. Last time I checked the interops (it's been
years) won't generate correctly. So I'm going to be writing all kinds of
COM Interop wrappers or worse using a ProcessInfo class to shell out of
process to the VBscript. Laugh, but I see it done all the time.
Or I can just add a reference to Microsoft.Deployment.WindowsInstaller and
write:
using(Database database = new Database(foo.msi,
DatabaseOpenMode.ReadOnly))
{
database.ExportAll(@C:\);
}
It's really that easy and as clean as can be. For extra bonus points the
using statement will automatically call the Dispose() methods which will in
turn clean up all those pesky unmanged handles.
For the summary information stream I just say:
using( var summaryInformation = new SummaryInfo(@foo.msi, false))
{
summaryInformation. // Intellisense kicks in .
}
I can now easily see that summaryInformation exposes Author,
CharacterCount, CodePage et al.
The point is, managed code and DTF rocks. DTF isn't just about writing
custom actions, it's an all purpose interop assembly for anything needing
to interact with Windows Installer and I find it really, really useful for
writing build automation tasks and applications / utilities. If you are
writing managed code you should be using it. If you are doing unmanged C++
then use the MSI API. If someone is still writing VBScript instead of
PowerShell and VB6 instead of C#/VB.NET I really have to scratch my head
and ask. Why??
I'm not a purist I'm just pointing out the fact that the VBS files are 12
years (at least) old and were only samples. Sadly I've seen far too many
people treat them as production libraries in their solutions.
From: Wilson, Phil phil.wil...@invensys.com
Sent: Tuesday, January 03, 2012 4:44 PM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Querying the package and installed
productarchitecture
I think the sample VBScripts in the SDK are useful to the extent that they
describe the flow for folks that aren't familiar with how to use the APIs.
Exporting an MSI table with no guidance at all is a pain, but I can see
from WiExport.vbs that I open the database, do an OpenView with a Select
query, do a View fetch, and then get each record's string data.
In this particular SummaryInfo case, WiSumInf.vbs is quite instructive on
how to get the SummaryInfo for the Platform. I'm not a language purist to
the extent that I'll ignore a working example, whatever language it might
be!
Phil W
-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Friday, December 30, 2011 5:56 PM
To: g...@gocek.org; General discussion for Windows Installer XML toolset.;
General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Querying the package and installed
productarchitecture
It's nearly 2012 and I'd much rather use C# and DTF. Perhaps in 1999 those
VBScript files were interesting and useful. I can understand the msi.h /
msi.lib is still good for the unmanaged C++ guys out there and is certainly
the foundation for DTF but the whole VBScript / ActiveScript / COM /
Automation Interface world can RIP for all I care. Same goes for the POS
Win32_Product class.
From: Gary Gocek g...@gocek.org
Sent: Friday, December 30, 2011 7:28 PM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Querying the package
Re: [WiX-users] RemoveExistingProducts after the InstallFinalize action still needed so that Major Upgrades don't remove assembly from GAC ?
I believe the issue is fixed in MSI 5.0. I've forgotten who told me but I think it was somebody in Microsoft. Phil W -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Friday, December 30, 2011 4:13 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RemoveExistingProducts after the InstallFinalize action still needed so that Major Upgrades don't remove assembly from GAC ? My colleague investigated some scenarios like this a few months ago. He found that when not changing the assembly version, then using the -fv switch on light and increasing the file version enabled a major upgrade of an assembly in the GAC with early RemoveExistingProducts to succeed. Without -fv, it failed on Win2003 with MSI 4.5 but succeeded on Win7 with MSI 5. When changing the assembly version too, the major upgrade succeeded. It might be worth making a quick test installer for the scenarios you are interested in to see if you get the same results. I'd look at the GAC, rather than the log, as the indicator of what happened, to avoid misinterpreting it. -Original Message- From: CristianG [mailto:cristian.gherghine...@gmail.com] Sent: 30 December 2011 11:34 To: wix-users@lists.sourceforge.net Subject: [WiX-users] RemoveExistingProducts after the InstallFinalize action still needed so that Major Upgrades don't remove assembly from GAC ? Hi, There is http://support.microsoft.com/kb/905238 a knowledge base article (mentioned also on the WiX Documentation) that describes the case of an assembly from GAC missing after a major upgrade. One of the solutions was to schedule *RemoveExistingProducts *action to occur after the *InstallFinalize *action. However, after the following test the assembly was still in GAC. The test: Using WiX 3.6, created a new setup project, with version 1.0.0.0 and *MajorUpgrade *element default, containing a dll to install into GAC. Install this small setup. Windows Installer 5.0 Create version 2.0.0.0, change Product Id (*ProductCode*) and leave the *MajorUpgrade *element default. The assembly for GAC remained the same. Checked with Orca and *RemoveExistingProducts *was scheduled after *InstallValidate * Do a major upgrade. The assembly remained in GAC. In the log file there is something like: Does that line from the log mean that the knowledge base article doesn't apply anymore ? Did I miss something and the *RemoveExistingProducts * action still needs to be scheduled after *InstallFinalize *action so that the assemblies from GAC are not removed after a major upgrade ? Thanks, Cristian -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RemoveExistingP roducts-after-the-InstallFinalize-action-still-needed-so-that-Major-Upgrades- don-t-re-tp7137858p7137858.html Sent from the wix-users mailing list archive at Nabble.com. - - Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ 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. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ 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
Re: [WiX-users] Detect VC++ runtime version on target system
1. Not quite sure how to answer that... MsiQueryProductState is a standard Win32 API call that can be done from C++ or from managed code using P/Invoke. 2. I don't know enough about the WiX bootstrapper to answer, but I assume it can detect ProductCodes and install something if that ProductCode is not installed. Phil W -Original Message- From: Helge Kruse [mailto:helge.kr...@gmx.net] Sent: Monday, December 12, 2011 10:29 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Detect VC++ runtime version on target system Phil, Thanks for reply. Do you refer to this 1. Call the MsiQueryProductState http://msdn2.microsoft.com/en-gb/library/aa370363.aspx API 2. Pass in the product code for the package that you want to detect based on the list below 3. Check the return value of this API. If it is anything other than INSTALLSTATE_DEFAULT, the package is not yet installed How do I call this API? Aaron describes this as the procedure in the VS2005 redistributable bootstrapper. - How do I add this to the wixproj file that defines the bootstrapper built with Votive and MSBuild? - How can I ensure in my .MSI that the bootstrapper has been started to install the redistributable if necessary? But this article and the link to the corresponding VS2005 article http://blogs.msdn.com/b/astebner/archive/2007/01/16/mailbag-how-to-detect-the-presence-of-the-vc-8-0-runtime-redistributable-package.aspx show some GUIDs that I found after installing the redistributable version. This could be used to find it in the registry. But I would use a better approach if possible. Regards, Helge Am 12.12.2011 21:53, schrieb Wilson, Phil: You need something like this, not a registry search. http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx Phil W From: Helge Kruse [helge.kr...@gmx.net] Sent: Sunday, December 11, 2011 11:11 AM To:wix-users@lists.sourceforge.net Subject: [WiX-users] Detect VC++ runtime version on target system The WiX help recommends to deploy the Visual C++ runtime using merge modules. I refer to section How To: Install the Visual C++ Redistributable with your installer. While this is possible, I don't want to include the MSM in every MSI I will generate. Instead I prefer to add this to the bootstrapper with Votive and MSBuild. But this would allow installing a C++ program that might will not run, when the bootstrapper is not used but the MSI is ran directly. Therefore I would like to check if the required version of the C++ run time is installed on the target system. This could be done with a RegistrySearch. But this allows only accessing registry values. I would like to do something like this: Property Id=VC80_CRT_762 RegistrySearch Id=Vc80_Crt_762 Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Installations\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_e889b656\downlevel_manifest.8.0.50727.4407 Name=? Type=raw / /Property Condition Message=This application needs a newer version of the VC++ run time. ![CDATA[Installed OR VC80_CRT_76]] /Condition How can the condition distinguish between an empty default value and key not in registry? How can this test achieved? What is the best way to check that the required or a newer version of the VC++ runtime is installed? Regards, Helge -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ 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
Re: [WiX-users] Detect VC++ runtime version on target system
You need something like this, not a registry search. http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx Phil W From: Helge Kruse [helge.kr...@gmx.net] Sent: Sunday, December 11, 2011 11:11 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Detect VC++ runtime version on target system The WiX help recommends to deploy the Visual C++ runtime using merge modules. I refer to section How To: Install the Visual C++ Redistributable with your installer. While this is possible, I don't want to include the MSM in every MSI I will generate. Instead I prefer to add this to the bootstrapper with Votive and MSBuild. But this would allow installing a C++ program that might will not run, when the bootstrapper is not used but the MSI is ran directly. Therefore I would like to check if the required version of the C++ run time is installed on the target system. This could be done with a RegistrySearch. But this allows only accessing registry values. I would like to do something like this: Property Id=VC80_CRT_762 RegistrySearch Id=Vc80_Crt_762 Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Installations\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_e889b656\downlevel_manifest.8.0.50727.4407 Name=? Type=raw / /Property Condition Message=This application needs a newer version of the VC++ run time. ![CDATA[Installed OR VC80_CRT_76]] /Condition How can the condition distinguish between an empty default value and key not in registry? How can this test achieved? What is the best way to check that the required or a newer version of the VC++ runtime is installed? Regards, Helge -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ 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). -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to check programatically that Start Menu entries for my app are present on the system (post installation testing)?
If it's just the product's install state that's needed, I would have thought that using an Msi API such as MsiQueryProductState (ProductCode) might be more useful than just seeing if someshortcuts are there. If you really need to see shortcuts that's just a programming task that involves enumerating the content of Environment.SpecialFolder.StartMenu and seeing if your shortcuts are there. Phil Wilson -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Monday, December 05, 2011 3:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to check programatically that Start Menu entries for my app are present on the system (post installation testing)? Do you want to check for their existence or ensure they are there ? You could run a repair with MsiReinstallProduct() ? Or MsiInstallMissingComponent() if you can list the component codes that are expected. -Original Message- From: Robert Lee [mailto:genrobert...@gmail.com] Sent: 05 December 2011 11:25 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to check programatically that Start Menu entries for my app are present on the system (post installation testing)? It's a management requirement, part of anti-piracy strategy - as there is no built-in DRM, we want to make sure the install state (including licensing information) is there for corporate software auditors to see. How to do it, either in C++ or C#? - - 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 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. -- 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 *** 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). -- 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] Is major update supposed to duplicate the add/remove programs entry?
You cannot make a new MSI file with a new ProductCode, run it and expect that it will just update your existing files. You've changed the ProductCode, making it a completely different product so yes you get two entries in ARP. The other replies cover this anyway, but if you go the major upgrade route with upgrade elements etc it just works, replacing the older installed product with the new one. This is completely automatic and doesn't prompt for the user to uninstall the old one. It sounds like that's what you want. Phil Wilson -Original Message- From: Robert Lee [mailto:genrobert...@gmail.com] Sent: Wednesday, November 30, 2011 3:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is major update supposed to duplicate the add/remove programs entry? I would like to develop an installer so that it would NOT force the user to uninstall the application manually prior to installing new version. Just running the new msi should update everything automatically. As far as I understood the wix book, in order to achieve that, I should set product ID in the markup to *, keep the upgrade code, and increase version number. But when I run the new msi, a new entry is added to add/remove programs. How to prevent that? -- 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 *** 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). -- 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] Directory and Registry Search failing in silent mode
The actual case-sensitive property name is SourceDir: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371857(v=vs.85).aspx SOURCEDIR is likely to be something internal that you should not be using. Phil Wilson -Original Message- From: Parkes, Kevin [mailto:kevin.par...@wacom.eu] Sent: Wednesday, November 30, 2011 4:44 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Directory and Registry Search failing in silent mode Seems I was mistaken about RegistrySearch and it is working correctly (sorry for wasting anyone's time on that). DirectorySearch is, however, still failing on silent install. It seems to be because the search is relative to [SOURCEDIR] but, in silent mode, [SOURCEDIR] is not being set until after AppSearch - actually between RemoveExistingProducts and ProcessComponents. (When run with UI, [SOURCEDIR] is set before Action Start INSTALL.) Apparently AppSearch must be scheduled before CostInitialize so I can't move it to, eg, before ProcessComponents. Why is setting [SOURCEDIR] delayed in silent install, and can I force it to be set sooner? Alternatively is there another way to test for folder [SOURCEDIR]\ABC later than AppSearch? (I simply want to copy the folder and its contents, if they exist, to the target directory.) -Original Message- From: Parkes, Kevin Sent: 29 November 2011 17:23 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Directory and Registry Search failing in silent mode Orca ICE validation flags up a few warnings (mostly about registry) but nothing that looks relevant. InstallExecuteSequence: FindRelatedProducts (25) AppSearch (50) LaunchConditions (100) ... InstallUISequence FatalError (-3) UserExit (-2) ExitDialog (-1) FindRelatedProducts (25) PrepareDlg (49) AppSearch (50) LaunchConditions (100) ... -Original Message- Re: [WiX-users] Directory and Registry Search failing in silent mode From: Peter Shirtcliffe pshirtcliffe@sd... - 2011-11-29 16:40 Seems OK then. Have you tried ICE validation ? Have you compared the UI and Execute sequences in Orca/InstEd ? -Original Message- From: Parkes, Kevin [mailto:Kevin.Parkes@...] Sent: 29 November 2011 15:33 To: wix-users@... Subject: Re: [WiX-users] Directory and Registry Search failing in silent mode I don't think it should be anything to do with user's profile: the Directory search is looking for a sub-folder in the folder containing the MSI ([SOURCEDIR]) and the Registry search is looking in HKEY_CLASSES_ROOT. InstallScope is perMachine The problem does occur with MSI 5 -Original Message- Re: [WiX-users] Directory and Registry Search failing in silent mode From: Peter Shirtcliffe pshirtcliffe@.. - 2011-11-29 14:52 Dave says... Could it be because the things you're looking for only appear in the user's profile - hkey_users and c:\users ? When you switch from UI sequence to execute sequence, the intallation engine switches to the service side and the current user becomes local system and user-specific searches wouldn't work. If you're running a per-user installation, the searches should be redirected but are you ? Whats the value of ALLUSERS ? Is Package/InstallScope set to perUser ? Are you using MSI 5 or something earlier ? -Original Message- From: Parkes, Kevin [mailto:Kevin.Parkes@...] Sent: 29 November 2011 14:20 To: wix-users@... Subject: [WiX-users] Directory and Registry Search failing in silent mode I have properties set by a DirectorySearch and a RegistrySearch both of which work as expected with UI but neither of which is set when run in silent mode: Property Id=ABCFOLDER DirectorySearch Id=ABCSearch Path=[SOURCEDIR]ABC Depth=1 / /Property Property Id=DOTXYZ RegistrySearch Id=DotXYZSearch Root=HKCR Key=.xyz Type=raw / /Property Log file with UI: Action start 11:29:54: AppSearch. AppSearch: Property: DOTXYZ, Signature: DotXYZSearch MSI (c) (D0:A4) [11:29:54:650]: Note: 1: 2262 2: Signature 3: -2147287038 MSI (c) (D0:A4) [11:29:54:730]: Note: 1: 1402 2: HKEY_CLASSES_ROOT\.xyz 3: 2 AppSearch: Property: IPIFOLDER, Signature: ABCSearch MSI (c) (D0:A4) [11:29:54:740]: Note: 1: 2262 2: Signature 3: -2147287038 MSI (c) (D0:A4) [11:29:54:760]: PROPERTY CHANGE: Adding ABCFOLDER property. Its value is 'C:\Users\kparkes\Documents\ABC\'. Action ended 11:29:54: AppSearch. Return value 1. Log file in silent mode: Action start 12:28:43: AppSearch. MSI (s) (44:9C) [12:28:43:152]: Note: 1: 2262 2: Signature 3: -2147287038 MSI (s) (44:9C) [12:28:43:152]: Note: 1: 1402 2: HKEY_CLASSES_ROOT\.xyz 3: 2 MSI (s) (44:9C) [12:28:43:152]: Note: 1: 2262 2: Signature 3: -2147287038 MSI (s) (44:9C) [12:28:43:162]: Doing action: LaunchConditions Action ended 12:28:43: AppSearch. Return value 1. What am I doing wrong? Thanks -- All the data continuously generated in your IT
Re: [WiX-users] 32 bit install with BOTH 64 and 32 bit drivers?
It depends how you intend to do that launch. Launching installers from installers is generally a bad thing. MSI setups can't launch other MSI setups in any reasonable way; your hosting MSI may fail having installed the driver, so what about rolling back or dealing with the driver already installed if you don't roll back. Strictly speaking (Windows Installer SDK) a 32-bit package can contain only 32-bit components, so are you using 63-bit components in your 32-bit install? Phil Wilson -Original Message- From: Michael Tissington [mailto:michael_tissing...@ciqual.com] Sent: Friday, November 25, 2011 10:44 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] 32 bit install with BOTH 64 and 32 bit drivers? Looking a bit more at installing drivers .. I have a utility (both a 64bit and a 32bit version) that runs and does the install of the respective driver. My msi can install the files for all versions of the required drives into respective folders. My question is can a 32 bit Install launch a 64bit application (packaged with the install) ? -- 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 *** 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). -- 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] removing broken installations from Windows XP
MsiZap was basically a friendly front end for the the MSI CleanUp Utility msicuu_.exe, or maybe it was the other way round. Either way, the Windows SDK no longer ships a clean up utility and it's been retired. Any version you find is going to be old and out of date with respect to later versions of the MSI engine. Don't use it. It was retired because it broke things. Phil Wilson -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Tuesday, November 29, 2011 11:42 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] removing broken installations from Windows XP Is there a walk through anywhere of how you would use those tools to do so? -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, November 29, 2011 1:19 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] removing broken installations from Windows XP I'd personally steer away from MSIZap or similar tools (CCleaner does it as well). I don't think any of these will clean up orphaned Component registry entries. If you find the uninstall key in the registry, you should be able to find the locally cached MSI package. I'd make a backup copy of the package and then use a tool like orca or InstEd to repair the MSI so it will properly uninstall. Jacob -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Tuesday, November 29, 2011 1:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] removing broken installations from Windows XP Microsoft used to provide the Windows Clean-up Utility (MSIZAP.EXE was one common name) but I believe they must have removed it from their web site. This might be a viable copy of that same program. They seem to indicate the author is Microsoft Corp. http://www.majorgeeks.com/Windows_Installer_CleanUp_Utility_d4459.html -Original Message- From: Remi [mailto:therealr...@gmail.com] Sent: Tuesday, November 29, 2011 7:26 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] removing broken installations from Windows XP OK, I know now I need some virtual pc software for testing installations. But I still have to clean what I messed up already. Basically I ended up installing some components to some random, inexistent, incorrect path (set in a custom action...). I didn't get any error dialog while installing, but I did during uninstall - it complained something about the bogus path being inaccessible. In my ignorance I run the installer few more times with the same error in my custom action. So I have a few unremovable entries in Add/Remove Programs. How to clean this up? -- 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 -- 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 *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the
Re: [WiX-users] Custom action cannot find installed files
Are you really specifying the entire path? It seems like you are not. There's no reason for Windows to change a fully specified path, but if you specify just a file name Windows will use the current directory and it obviously has no way of knowing that you mean the ProgramFiles folder. It may be that something else is going on, maybe using a property you obtained in the UI sequence but didn't list in SecureCustomProperties, so it disappeared. Phil Wilson -Original Message- From: Marcel Wouters [mailto:marcelwout...@msn.com] Sent: Saturday, November 19, 2011 3:00 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Custom action cannot find installed files I have made a custom action to update a xml file which is installed. I'm passing the path of the file to the custom action with CustomActionData. This works fine, but when I try to open the xml file in the custom action the action is looking in the wrong directory. CustomAction Id=UpdateConfigCustomAction BinaryKey=CustomActionsDLL DllEntry=UpdateConfigFileAction Execute=deferred Return=check Impersonate=no / InstallExecuteSequence Custom Action=SetPropertiesCustomAction Before=UpdateConfigCustomAction / Custom Action=UpdateConfigCustomAction Before=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence For example the path of the xml file is: C:\Program Files(x86)\MyProgram\file.xml but the action is looking at C:\Windows\Installer\.TMP\C:\Program Files(x86)\MyProgram\file.xml If I debug the custom action the value of the string is 'C:\Program Files(x86)\MyProgram\file.xml' but when opening the xml file with for example the XDocument.Load method the path is prefixed with C:\Windows\Installer\***.TMP\ -- 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 *** 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). -- 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] Changing the Windows Service name on an upgrade
If it's an upgrade, you can just uninstall the old service and install it again with your new name. Change the Component guid for the service component and that just works. I don't know of anything that will just change the name that's supported by MSI. The ServiceControl stuff lets you say you want to stop a service during an install, maybe that's what you should look at. Also specify start at install to start it (later) during the install. Services don't normally prompt files in use dialogs AFAIK - is the service associated with a tray app or something like that? Also behavior changes pre and post Vista, when Restart Manager was introduced and the in-use detection algorithms changed. Phil Wilson -Original Message- From: Deepa Choundappan [mailto:deepa...@gmail.com] Sent: Friday, November 11, 2011 2:34 PM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Changing the Windows Service name on an upgrade Hi - Our original version of the msi installed a service like Service Preview - I now need to change this to Service on a subsequent install. On an upgrade - I hit a Files In Use box which sayd The following applications are using files which the installer must update. You can either close the applications and click Try Again, or click Continue so that the installaer continues the installation, and replaces these files when you system restarts. What can I do so that the install can correctly detect that there is only a name change or perhaps shutdown the old service itself before continuining with the installation? -- Regards Deepa -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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). -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Keeping files after uninstall
Beware though because many people get the impression that permanent is a project setting, and consequently they install the same file later with permanent = fale and expect it to uninstall. Permanent means permanent on the system, forever ref counted by MSI to stay there. IMO a better solution is to set the Component guid for the file to be null. MSI will install it but not register a ref count, and it will not remove it when the product is uninstalled. Phil Wilson -Original Message- From: jaczjill [mailto:jaczj...@gmail.com] Sent: Wednesday, November 09, 2011 2:00 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Keeping files after uninstall use permanent=yes Example: Component Id=cmpAddressBookFolder Permanent=yes also DON'T use RemoveFile Id=removeAddressBookFolder Directory=AddressBookFolder Name=*.* On=uninstall / because this is cleaning your folder. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Keeping-files-after-uninstall-tp6975689p6977419.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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). -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix or MSI bug ?
Mmm, odd. I just did a standard AppSearch/FileSearch using only the MSI tables and a search for msi.dll in the System folder does not return a trailing slash on the end of the file name, using MSI 4.5. WiX doesn't get in the middle of a standard file search does it? Phil Wilson -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Tuesday, November 08, 2011 2:19 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix or MSI bug ? Phil the bug is that the path returned by FileSearch is of the format C:\Directory\Filename.ext\ The trailing slash after the filename makes the path returned by FileSearch all but useless unless you use a custom action to remove it first, in which case you may as well just use a custom action to return the correct value in the first place. 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: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: 07 November 2011 17:58 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix or MSI bug ? And most Windows Installer paths end with a \ too, in the path properties. Phil Wilson -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, November 07, 2011 6:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix or MSI bug ? Old bug with FileSearch which has been closed but never actually fixed as far as I can see - http://sourceforge.net/tracker/?func=detailatid=642714aid=1648267group_id=105970 http://sourceforge.net/tracker/index.php?func=detailaid=1273447group_id=105970atid=642714 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: Nicolas Penin [mailto:n.pe...@happly.fr] Sent: 07 November 2011 09:02 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Wix or MSI bug ? Dear all, I believe this is a bug in wix 3.6, but not sure... If I do the following : Property Id=SQLCMDPATH RegistrySearch Id=SqlBinsRegistry Root=HKLM Key=SOFTWARE\Microsoft\Microsoft SQL Server\100\Tools\ClientSetup Type=directory Name=Path FileSearch Name=SQLCMD.EXE / /RegistrySearch /Property I have the appropriate path, except it is terminating with a \ If I change the Type of RegistrySearch to file, the content of SQLCMDPATH is 'C:\' Any idea ? Regards, Nicolas Penin -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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). -- RSA(R
Re: [WiX-users] Wix or MSI bug ?
And most Windows Installer paths end with a \ too, in the path properties. Phil Wilson -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, November 07, 2011 6:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix or MSI bug ? Old bug with FileSearch which has been closed but never actually fixed as far as I can see - http://sourceforge.net/tracker/?func=detailatid=642714aid=1648267group_id=105970 http://sourceforge.net/tracker/index.php?func=detailaid=1273447group_id=105970atid=642714 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: Nicolas Penin [mailto:n.pe...@happly.fr] Sent: 07 November 2011 09:02 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Wix or MSI bug ? Dear all, I believe this is a bug in wix 3.6, but not sure... If I do the following : Property Id=SQLCMDPATH RegistrySearch Id=SqlBinsRegistry Root=HKLM Key=SOFTWARE\Microsoft\Microsoft SQL Server\100\Tools\ClientSetup Type=directory Name=Path FileSearch Name=SQLCMD.EXE / /RegistrySearch /Property I have the appropriate path, except it is terminating with a \ If I change the Type of RegistrySearch to file, the content of SQLCMDPATH is 'C:\' Any idea ? Regards, Nicolas Penin -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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). -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error with InstallUtilLib.dll: CoreBindToRuntimeHost path not found error.
I have heard that there is an issue with VS 2010 merge modules where they always install files to the Module Retargetable Folder instead of the intended one. That may have something to do wth it. Other issues may occurr when InstallUtilLib.dll is 32-bit and you attempt to use it on a 64-bit system. If there is any way you can re-build that merge module, you should do it. Even in the dubious world of using installer classes to install services you never needed to run InstallUtil.exe. The setup will call installer class custom actions without running InstallUtil.exe. There's nothing that special about .NET services, so if possible convert that merge module to WiX and use the built-in ServiceInstall elements that populate the ServiceInstall table in the MSI file. Phil From: Aled Hughes [trestlemon...@gmail.com] Sent: Wednesday, November 02, 2011 10:34 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error with InstallUtilLib.dll: CoreBindToRuntimeHost path not found error. Hi, I have a merge module that was authored using the VisualStudio 2010 installer and this MSM installs a windows server and has a custom action that registers the service using the InstallUtil program. However, when I use that MSM in a MSI authored using WiX 3.5, I get the following error on installation: Error 1001. InstallUtilLib.dll: CorBindToRuntimeHost (hr=0x80070003): The system cannot find the path specified. .Net4 is already installed on the machine. When the MSM was included in a MSI authored using the VS2010 installer tool the problem did not occur. I needed to move from the VS2010 installer to a WiX installer to allow for more flexibility. Any ideas as to what the cause of this is? -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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). -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Keep file on Upgrade?
There are potential issues with the general idea of saving and restoring. If the file has an MSI file hash then the file you copy back won't match the installed file, and that means a repair is likely to restore the one from the MSI file. It might be useful to describe what problem you're trying to solve. People do this kind of thing to preserve settings and data files that were modified, but Windows Installer won't update data files that were modified after installation. If that's the case, an upgrade with RemoveExistingProducts towards the end won't change the file, and you don't need to deal with it. Phil Wilson -Original Message- From: Dirk Räder [mailto:d...@raeder.cc] Sent: Tuesday, November 01, 2011 12:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Keep file on Upgrade? Hi Michael, you could use two Custom Actions to do so - the first (scheduled before installation) copies the file, the second (after InstallFinalize) copies it back and deletes the temporary file. Or you could add use a separate component for that file and add an install condition to the component, something like If Not Exists. If WiX / MSI don't provide the necessary statements, code a CA that tests the file and fills a MSI property. Then check for that property. As you should leave the file handling completely to MSI, I would prefer the second way. 2011/10/31 Michael Tissington michael_tissing...@ciqual.com: I have a text file that has been modified in a folder under ProgramData. When doing an upgrade I need to keep the file If the file exists I'd like to take a copy of it to a temp location, Perform the upgrade and then copy the file back. How can I do this? -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSAreg; Conference 2012 Save #36;700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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). -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now! http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Get installer final status (return code) from custom action
You could write something to monitor or read the Application Event log. There are MsiInstaller entries created when a product is installed (and I think one for failure too). They seem to be event ID 1033, and there's a ProductCode, result and ProductName in the entry. Phil Wilson -Original Message- From: Elanius [mailto:elani...@gmail.com] Sent: Thursday, October 27, 2011 4:44 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Get installer final status (return code) from custom action Hi I am working on installer of our product and I got another requirement from my beloved product manager. So I need collect some statistic about installer and main problem is get final return code of installer. It would be simple task if I had some top level application which calls installer through MsiInstallProduct but I it is not my case. I managed to add Custom Actions on positions -1, -2 and -3 in InstallExecuteSequence so I know if installation ends with success, user exit or some error. But I can not obtain last msi error a mean error code which is normally returner by API function MsiInstallProduc. It have to be stored somewhere because in this time (sequence -3) is obvious that installer is finishing with some error. But question is if it is accessible? thanks for any reply, elanius. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ 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). -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows Installer won't remove existing during upgrade
You may need to look at the log more carefully. If the uninstall of the older version failed it will roll back and reinstall, and that will leave you with both products installed. That's the issue with RemoveExistingProducts -after- InstallFinalize where it's outside the transacted part of the install. Phil Wilson -Original Message- From: Tim Walters [mailto:rea...@gmail.com] Sent: Thursday, October 27, 2011 1:14 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Windows Installer won't remove existing during upgrade I'm trying to properly implement an upgrade (minor version number change which should trigger a replace). However, Windows Installer leaves older versions installed without touching them (Leaves the program files behind and the Uninstall Programs reg entry). I'm using the same upgradecode for all versions and always changing the product and package codes. I've tried to implement this the following way: Upgrade Id=UPGCODE UpgradeVersion Property=DOWNGRADE OnlyDetect=yes Minimum=VERSION IncludeMinimum=no / UpgradeVersion Property=UPGRADE OnlyDetect=no Minimum=VERSION Maximum=VERSION IncludeMinimum=yes IncludeMaximum=no / /Upgrade InstallExecuteSequence RemoveExistingProducts After=InstallFinalize / /InstallExecuteSequence From the logs I can see it runs but I don't know it if attempted to do anything: MSI (c) (74:58) [12:32:12:069]: Doing action: FindRelatedProducts Action 12:32:12: FindRelatedProducts. Searching for related applications Action start 12:32:12: FindRelatedProducts. Action ended 12:32:12: FindRelatedProducts. Return value 1. ... DEBUG: Error 2911: Could not remove the folder C:\Config.Msi\. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2911. The arguments are: C:\Config.Msi\, , MSI (s) (BC:80) [12:32:27:466]: Note: 1: 2318 2: MSI (s) (BC:80) [12:32:27:466]: No System Restore sequence number for this installation. MSI (s) (BC:80) [12:32:27:466]: Unlocking Server MSI (s) (BC:80) [12:32:27:544]: PROPERTY CHANGE: Deleting UpdateStarted property. Its current value is '1'. Action ended 12:32:27: InstallFinalize. Return value 1. MSI (s) (BC:80) [12:32:27:544]: Doing action: RemoveExistingProducts Action 12:32:27: RemoveExistingProducts. Removing applications Action start 12:32:27: RemoveExistingProducts. Action ended 12:32:27: RemoveExistingProducts. Return value 1. Action ended 12:32:27: INSTALL. Return value 1. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ 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). -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Replacing .Netv.3Assemblieswith.Net v.4Assembliesduring Major Upgrade
Just wondering - are you getting a FileVersion value in any of the MsiAssemblyName tables in any of these MSI files? I can't quite get my head around it, but in-place updates of a GACed assembly will happen when FileVersion is there, and if the GAC's location has moved then some parts of Windows Installer could get rather confused. Phil Wilson -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, October 19, 2011 1:56 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Netv.3Assemblieswith.Net v.4Assembliesduring Major Upgrade It might be :) http://msdn.microsoft.com/en-us/library/aa367858%28v=VS.85%29.aspx Action: FileAbsent Installer actually uninstalls component's files and leaves all other resources of the component installed. So the component as a whole is not being removed. A bit of digging turned up this post. http://community.flexerasoftware.com/showthread.php?t=126033 'I opened a case with Microsoft and eventually got to the bottom of my issue (shortcuts not deleting). First, here is what Microsoft had to say about the FileAbsent Action: FileAbsent means that the files will be removed but the class registration (if any) and non-file resources will not be removed. It is caused when there are multiple products referencing the component GUID but each product has its own unique location for the files. The files for the product being uninstalled can be removed from their own product-specific location but the rest of the component resources (presumably shared) can not be removed because the other products still need them.' Not so strange in the normal case but with GACed files, the location should be the same in all MSIs. The GAC doesn't move around. So a few things to look at are: do you have the files in the same component in all installers ? The component definitions should be *exactly* the same in all: component guid and contents. If not, that might be the problem. If that's not the problem, are the components in the same place in the directory hierarchy in all installers ? I imagine that is what gives the location of the components, even though the files go in the GAC. That could matter if youre using * for the guid. -Original Message- From: Gregory Swanson [mailto:gswan...@athoc.com] Sent: 19 October 2011 02:37 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Netv.3Assemblieswith.Net v.4Assembliesduring Major Upgrade I want to clarify what I was trying to say: after running the Major Upgrade and looking at the verbose log, under the RemoveExistingProducts action, I found a line for one of the old components that contains one of the v.3 Assemblies - it looks like Windows Installer is planning to remove it: MSI (s) (38:38) [17:05:07:710]: Component: component80; Installed: Local; Request: Absent; Action: FileAbsent; Client State: Local Thanks, Greg -Original Message- From: Gregory Swanson Sent: Tuesday, October 18, 2011 6:19 PM To: General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] Replacing .Net v.3Assemblieswith.Net v.4Assembliesduring Major Upgrade We do have other applications that share some of these components, and that list is growing. But looking in the SharedDLLs key in the registry, I see that none of the .Net dlls are listed so I guess the SharedDLLRefCount attribute is not needed with .Net dlls. After running the Major Upgrade, the old package is removed from ARP. But the old .Net v.3 Assemblies are left behind in the v.2 GAC, while the new .Net v.4 Assemblies are in the v.4 GAC. Running an uninstall at this point removes everything. Under the RemoveExistingProducts action in the verbose log, I found a line for one of the old components that contains one of the v.3 Assemblies - it looks like Windows Installer is planning to remove it: MSI (s) (38:38) [17:05:07:710]: Component: component80; Installed: Local; Request: Absent; Action: FileAbsent; Client State: Local I don't expect that a single line from a 23 MB log file is much use though. Thanks, Greg -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Tuesday, October 18, 2011 11:42 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Replacing .Net v.3Assemblieswith.Net v.4Assembliesduring Major Upgrade It might not be an issue, but just reading your code I'd tend to avoid the SharedDllRefCount. But, reading that also makes me wonder if there was a particular reason for using that? Do other packages you know of also deliver the same DLL? I'm not sure how to generate an uninstall log when the Major Upgrade is the one doing the uninstall of the prior package. Maybe the registry keys for voicewarmup? Start Registry Editor (Regedt32.exe), and then create the following path and keys in the registry:
Re: [WiX-users] Registry key issues on 64-bit Win 7
The MSI SDK says a 32-bit package consists of only 32-bit components so you're not really playing by those rules. There's also this: http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx If you have 32-bit and 64-bit clients I find it generally works better to explicitly build both architectures, and register the 32-bit one in WoW6432 and the 64-bit one in native, and locate them somewhere other than the program files folder. COM components are potentially shared, so installing a COM Dll into a variable folder like program files means that different packages can put different versions of it in multiple places, and that's not going to work. Phil Wilson. -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: Wednesday, October 12, 2011 6:47 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Registry key issues on 64-bit Win 7 I believe I have some more information about this after further testing. Basically, if I start up a 32bit command prompt (%windir%\SysWoW64\cmd.exe) from my 64bit machine, and run my VBScript, everything works fine. I would have thought that since my .NET class can natively run on either architecture, I should be able to register the DLL via Wix so that it can run from a 64 bit app or from a 32-bit app. However, since the COM server DLL is installed in Program Files (86), I can only write registry entries to the Wow6432Node. Is this a Wix limitation? I suspect if I can duplicate the registry entries (a copy in HKCR and HKCR\Wow6432Node), I can start the COM server without issues in a 32bit or 64bit app. Cheers sanjay -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 11 October 2011 22:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Registry key issues on 64-bit Win 7 I have created a Wix installer for a 32-bit application (not .NET) which installs just fine. Recently, I had to create a COM Server written in .NET consisting of a single DLL which also had to be installed (and used by) my original application. So basically I wrote the COM server in C# (target=Mixed Platforms) with the relevant interface and class decorated with the required COM attributes by following the instructions in this post: http://stackoverflow.com/questions/3360160/how-do-i-create-an-activex- com-in-c Next I harvested the registry entries of the DLL and added the appropriate component into my installer (it installs into Program Files (x86)\Company\ProductName) with the extracted entries. Now, Installing on my 64-Bit Win 7 machine, the component above writes the ProgId entries into HKCR but writes all elements of the form: RegistryValue Root=HKCR Into HKCR\Wow6432Node\CLSID This basically seems to break the COM server (eg, a VB Script fails to create the object). However, if I mark the new component as Win64=yes, the RegistryValue entries get installed into HKLM\Software\Classes and everything works although Wix gives me an error that I am installing a 64-bit component into 32bit INSTALLDIR. Can anybody provide guidance as to what I should be doing? Any help is appreciated. sanajy -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ 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).
Re: [WiX-users] majorupgrade when signing and merge
Two entries in Add/Remove Programs usually means you tried to upgrade a per-system product with a per-user install, or vuice versa (all other things being correct to do the upgrade). A verbose log will say something near the FindRelatedProducts action. Phil Wilson -Original Message- From: Martin Kulov [mailto:mar...@kulov.net] Sent: Thursday, October 06, 2011 3:59 AM To: John Robbins; wix-users Subject: Re: [WiX-users] majorupgrade when signing and merge So I verified that digitally signing the MSI does NOT break MajorUpgrade process and product gets upgraded just fine.Also adding the MSM Merge module DOES break MajorUpgrade process.When I add the following two lines Merge and MergeRef I end up with two installations of my product: Directory Id=INSTALLLOCATION Name=$(var.ProductName) ... Merge Id=Microsoft_VC90_CRT_x86 Language=1033 SourceFile=Microsoft_VC90_CRT_x86.msm DiskId=1 / /Directory Feature Id=F_Complete Title=$(var.ProductName) Setup Level=1 Display=expand Absent=disallow AllowAdvertise=no ConfigurableDirectory=INSTALLLOCATION MergeRef Id=Microsoft_VC90_CRT_x86 / ... /FeatureMoving the merge module in another feature does not help either. Any ideas? Thanks,Martin From: mar...@kulov.net To: j...@wintellect.com; wix-users@lists.sourceforge.net Date: Thu, 6 Oct 2011 09:58:17 + Subject: Re: [WiX-users] majorupgrade when signing and merge Hey John,nice to hear from you :) Yes, I did change the Product Id and Version. I used to publish 3 more upgrades already. However when I digitally signed the MSI, integrated a merge module and changed the Package InstallerVersion from 200 to 300 now the upgrade is not recognizing the old version. I keep the UpgradeCode the same. I will try adding the changes one by one and see what the problem is. Thanks,Martin From: j...@wintellect.com To: wix-users@lists.sourceforge.net; mar...@kulov.net Date: Wed, 5 Oct 2011 17:20:29 -0700 Subject: RE: [WiX-users] majorupgrade when signing and merge Hi Martin, Did you change the Product ID and the version number? Both of those have to change to be called a major upgrade. http://wix.sourceforge.net/manual-wix3/major_upgrade.htm shows how to integrate a major upgrade into your .WXS file. John Wintellect http://www.wintellect.com +1-877-968-5528 -Original Message- From: Martin Kulov [mailto:mar...@kulov.net] Sent: Wednesday, October 05, 2011 2:59 PM To: wix-users Subject: [WiX-users] majorupgrade when signing and merge Hi, I have an MSI installer built few months ago. It used to work fine during MajorUpgrade. Today I signed the MSI with code certificate and also added one Merge Module. However now my MSI file gets installed as a new product and does not upgrade the existing installation as it used to do. As usual I only changed ProductCode and CurrentVersion properties. Does digital signing or adding merge module makes the MSI look like a new product? What else could be the case? Thanks, Martin -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any
Re: [WiX-users] majorupgrade when signing and merge
Some of those VC merge modules have a Property table with ALLUSERS=1, so that
will do it. If you're using a bootstrapper maybe you could run the VC9 redist
executable instead of using merge modules.
Phil Wilson
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Thursday, October 06, 2011 3:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] majorupgrade when signing and merge
Sounds like your original package was per-user. The VC9 merge module very
likely accesses per-machine locations. That merge module must have required
that you change the package to per-machine so that it compiled successfully.
If your source control system does not show any other changes then perhaps the
per-user/per-machine setting wasn't set then WiX might have picked a smart
default based on the contents of the package. I don't know if WiX would really
do that...
Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Martin Kulov [mailto:mar...@kulov.net]
Sent: Thursday, October 06, 2011 2:55 PM
To: wix-users
Subject: Re: [WiX-users] majorupgrade when signing and merge
So I guess you were right. Here is excerpt of the log: MSI (c) (D8:18)
[14:49:27:908]: Doing action: FindRelatedProducts MSI (c) (D8:18)
[14:49:27:908]: Note: 1: 2205 2: 3: ActionText Action 14:49:27:
FindRelatedProducts. Searching for related applications Action start 14:49:27:
FindRelatedProducts.
MSI (c) (D8:18) [14:49:27:908]: FindRelatedProducts: current install is per-
machine. Related install for product '{AB5B1162-D4DE-4C59-BAB3-
020B2323AF98}' is per-user. Skipping...
MSI (c) (D8:18) [14:49:27:908]: FindRelatedProducts: current install is per-
machine. Related install for product '{AB5B1162-D4DE-4C59-BAB3-
020B2323AF98}' is per-user. Skipping...
Action ended 14:49:27: FindRelatedProducts. Return value 1.
I do not get it why adding an MSM merge module will have any effect on the
per-machine vs per-user mode. How can I fix it back to per-machine mode?
Thanks,
Martin Kulov
Microsoft Regional Director
VS ALM MVP, MCT, INETA Speaker
www.kulov.net | (+359) 88 821 3255
From: phil.wil...@invensys.com
To: wix-users@lists.sourceforge.net
Date: Thu, 6 Oct 2011 13:17:06 -0400
Subject: Re: [WiX-users] majorupgrade when signing and merge
Two entries in Add/Remove Programs usually means you tried to upgrade a
per-system product with a per-user install, or vuice versa (all other things
being correct to do the upgrade). A verbose log will say something near the
FindRelatedProducts action.
Phil Wilson
-Original Message-
From: Martin Kulov [mailto:mar...@kulov.net]
Sent: Thursday, October 06, 2011 3:59 AM
To: John Robbins; wix-users
Subject: Re: [WiX-users] majorupgrade when signing and merge
So I verified that digitally signing the MSI does NOT break MajorUpgrade
process and product gets upgraded just fine.Also adding the MSM Merge
module DOES break MajorUpgrade process.When I add the following two
lines Merge and MergeRef I end up with two installations of my product:
Directory Id=INSTALLLOCATION Name=$(var.ProductName)
...
Merge Id=Microsoft_VC90_CRT_x86 Language=1033
SourceFile=Microsoft_VC90_CRT_x86.msm DiskId=1 /
/Directory
Feature Id=F_Complete
Title=$(var.ProductName) Setup
Level=1
Display=expand
Absent=disallow
AllowAdvertise=no
ConfigurableDirectory=INSTALLLOCATION MergeRef
Id=Microsoft_VC90_CRT_x86 /
...
/FeatureMoving the merge module in another feature does not help
either. Any ideas? Thanks,Martin
From: mar...@kulov.net
To: j...@wintellect.com; wix-users@lists.sourceforge.net
Date: Thu, 6 Oct 2011 09:58:17 +
Subject: Re: [WiX-users] majorupgrade when signing and merge
Hey John,nice to hear from you :) Yes, I did change the Product Id and
Version. I used to publish 3 more upgrades already. However when I digitally
signed the MSI, integrated a merge module and changed the Package
InstallerVersion from 200 to 300 now the upgrade is not recognizing the old
version. I keep the UpgradeCode the same. I will try adding the changes one
by one and see what the problem is. Thanks,Martin
From: j...@wintellect.com
To: wix-users@lists.sourceforge.net; mar...@kulov.net
Date: Wed, 5 Oct 2011 17:20:29 -0700
Subject: RE: [WiX-users] majorupgrade when signing and merge
Hi Martin,
Did you change the Product ID and the version number? Both of those
have to change to be called a major upgrade.
http://wix.sourceforge.net/manual-wix3/major_upgrade.htm shows
how to integrate a major upgrade into your .WXS file.
John
Wintellect
Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files.
VBScript is pretty straightforward. Dim installer = CreateObject(WindowsInstaller.Installer) And then Installer.InstallProduct (path to msi, property list etc) for each one. I suspect PowerShell has similar capabilities. Phil Wilson -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Tuesday, October 04, 2011 7:45 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. When calling another process from within a batch file that you want to waiting merely add 'call' in front of it. I do this to utilize multiple batch files with one call. Jon -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Monday, October 03, 2011 6:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. John Have a look at the Start command (help start) which can be used to start and wait in batch files. Michael -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Tuesday, 4 October 2011 8:47 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. I am working through deploying our software for automated testing and appear to have encountered an issue that I am not quite sure what the best way is to solve. I need to deploy multiple MSI files, my initial thought was that I could do this with a batch file, but apparently, the process of running the MSI starts a new process and the batch file continues, so all of the installers after the first one fails. The order of install doesn't matter in my case. I was using PSExec to start the MSIs remotely (both directly and via a batch file). Anyone have any ideas as far as what the best way to do this would be? -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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). -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application
Re: [WiX-users] Known Issues why msiexec.exe goes Zombie for MSI 4.5
During an installation there may be more than those two. New ones may be fired up to host custom actions. I agree, it all sounds normal to me. Phil Wilson -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 1:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Known Issues why msiexec.exe goes Zombie for MSI 4.5 That may be ordinary behaviour you are seeing. There are 2 msiexec processes associated with an installation - the client-side exe and the server-side service process. After the msiexec service has been used for something (installation, repair, etc), it persists for a while (10 minutes maybe ?) in case it is needed again. You can probably put the chainsaw back in the shed :) -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: 03 October 2011 19:24 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Known Issues why msiexec.exe goes Zombie for MSI 4.5 Is there any list of know issues with Windows Installer 4.5/5.0? Occasionally, I see zombie msiexec.exe processes. This occurs even on a successful installer verbose log. It's not common, and it appears to be random. Killing the msiexec.exe zombies usually works. Rebooting always works. Occurs like maybe once a week. During testing. -- John Merryweather Cooper Jack Henry Associates, Inc. (Premier Tech, Inc.) Build Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.commailto:jocoo...@jackhenry.com NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. - - 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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. -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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). -- 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
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Is there anything about that interop that lets you see the equivalent of
MsiViewGetError or MsiGetLastErrorRecord? There's typically more error info
available from those.
Phil Wilson
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 11:45 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why my
custom action is constantly failing me. The action executes on uninstall and
is to browse the install folder and add files to the RemoveFile table (with a
few additional properties too) in the MSI so that the file is removed during
uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row (Either
in the Property Table or the RemoveFile table) I get the exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no avail.
And there is no way the directory property name could be conflicting as it is
part static with a GUID (stripped of the hyphens) appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows Installer
citizen here and use the tools as they are.
--Brian
--
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. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
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).
--
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. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Strange behavior with date modifying of installed files
Windows Installer will set the Modify and Creation dates of data files to be identical when they're installed - is that what you're seeing? That's to identify modified-after-installation files. Maybe sometimes that's a future date. Phil Wilson -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Tuesday, September 27, 2011 4:45 AM To: General discussion for Windows Installer XML toolset.; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Strange behavior with date modifying of installed files WiX / MSI doesn't have any elements/table data to express file timestamps. This is a function of when the file is compressed into the CAB. I don't see anything strange about the behavior as it's expected since windows is aware of UTC and Local time and will use UTC internally but show Local to the user. From: Grigory Konovalov grigory.konova...@confirmit.com Sent: Tuesday, September 27, 2011 4:23 AM To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject: [WiX-users] Strange behavior with date modifying of installed files Hi all, I have noticed a strange behavior during installation. For example, we have a build server with UTC+01.00. I have a production server with UTC-06.00. I run a build on the build server and create an installation. I install the installation on the production server and can see, that modify date of all files are in future. Is such behavior correct? May I change modify date parameter by WIX? Grigory Konovalov Software Engineer grigory.konova...@confirmit.commailto:grigory.konova...@confirmit.com | Phone +7 4852 586 924 | Mobile +7 902 221 6886 Confirmit(r) [everywhere] Software for Market Research and Enterprise Feedback Management Confirmit Ltd., 56 Lisizina str., Yaroslavl, Russia, 150014 www.confirmit.comhttp://www.confirmit.com/ | Main/fax +7 4852 586 924; +7 4852 586 925 The information contained in this email message may be privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this transmission is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please notify the sender immediately. -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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). -- 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. Business sense. IT sense. Common sense.
Re: [WiX-users] Installed software listed in SNMP 'hrSWInstalled' applications
That's a system key that MSI installs will just update. Without knowing exactly
what that snmpwalk thing is doing, I'd guess that it may be ignoring the
MSI-based installs in ...\Uninstall\{guid}. This might be deliberate because
you can enumerate the MSI-based products with MsiEnumProducts(), so why trawl
the registry? If you're on a 64-bit system, it might walk only one of the
Uninstall nodes. Maybe it only enumerates the per-user Uninstall key.
There might be a trick, but I've never seen any of the registry trawlers report
the right information. There is no proper API to report the non-MSI ones.
Phil Wilson
-Original Message-
From: wigyxz-p...@yahoo.com [mailto:wigyxz-p...@yahoo.com]
Sent: Thursday, September 15, 2011 10:14 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Installed software listed in SNMP 'hrSWInstalled'
applications
After some playing with the registry I found that
applications that create registry entries here show up in the
hrSWInstalled output
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
My installer doesn't create that key. I don't know whether it should or not...
From: wigyxz-p...@yahoo.com wigyxz-p...@yahoo.com
To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net
Sent: Wednesday, September 14, 2011 8:54 PM
Subject: [WiX-users] Installed software listed in SNMP 'hrSWInstalled'
applications
I've got some MSI software packages created with WiX that I install on Windows
7 systems with group policy.
I'm using the linux 'snmpwalk' app to query each Windows PC to list the
'hrSWInstalled' applications. I'm seeing some applications listed in the output
(mostly MS applications, but some third party as well), but none of the
applications I've installed with my installers.
Does anyone know what the trick is to get installed applications to show up in
the SNMP output? this may have nothing to do with WiX, but I just have no idea.
thanks!
--
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
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).
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DirectorySearch/FileSearch not executed if msiexec runs with qb ?
/qb means that the user interface sequence isn't run, so make sure your search (I think there'll be an AppSearch standard action) is in the Execute and UI sequences. Phil Wilson -Original Message- From: Marc Bauer [mailto:marc@gmx.net] Sent: Thursday, September 08, 2011 2:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] DirectorySearch/FileSearch not executed if msiexec runs with qb ? Hi I'm trying to copy a file FOO.DB to the APPLICATIONFOLDER. The FOO.DB can optionally copied into the same folder like the MSI, but is not included in the MSI. The FOO.DB is optional; it may be there or not. If I run the setup interactively it just works. If I'm running it with /qb the FOO.DB is not copied to the APPLICATIONFOLDER. Property Id=CUSTOM_PRE_CONFIGURATION Secure=yes DirectorySearch Id=DirSearch Path=[SOURCEDIR] Depth=0 FileSearch Id=FileSearch Name=foo.db / /DirectorySearch /Property Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=APPLICATIONFOLDER Name=$(var.ProductName) Component Id=FOO.DB Guid=GUID CopyFile Id=FOO.DB SourceProperty=CUSTOM_PRE_CONFIGURATION DestinationProperty=APPLICATIONFOLDER / /Component MSI debugging with /qb shows: MSI (s) (80:C8) [22:34:54:130]: Dir (target): Key: CUSTOM_PRE_CONFIGURATION , Object: NULL From the logfile it looks like the FileSearch is not executed at all with /QB. Any idea what I'm doing wrong or if this is a bug? If a bug I need a workaround... Regards Marc -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem runinng custom action. Dll not found error
The problem appears to be that BinaryKey specification. As the docs say the custom action will not be installed into a target directory. You're not running it from your install directory - you're running it streamed out of the MSI file's binary table into some temp folder. It's not a type 18. Phil Wilson -Original Message- From: Leandro Lumerante [mailto:llumera...@yahoo.com.ar] Sent: Thursday, September 01, 2011 11:40 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem runinng custom action. Dll not found error Hi Guys, I'm trying to add a custom action of type 18, following the steps described here http://blogs.technet.com/b/alexshev/archive/2008/02/21/from-msi-to-wix-part-5-custom-actions.aspx The problem is when executing my app, it doesn't find a dll required to run the program. The dll is present in the directory installed, because if I dont close the installer dialog with the error, I can see the files, and execute my program from the command line. It is a simple program, that uses lognet to log the directories and files in the installed folder. I made this to test custom actions. I paste the wix part involving the custom action CustomAction Id=TestApp BinaryKey=TestApp ExeCommand=-switch Execute=deferred Return=check HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=TestApp Before=InstallFinalize / /InstallExecuteSequence and where the files are included Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLLOCATION Name=TestApplication1 Component Id=ProductComponent Guid=570929b6-b02d-4551-a785-f8a88b5fa5d1 File Id=MainAppConf Source=Resources\TestApplication.exe.config Name=TestApplication.exe.config / File Id=log4netdll Source=Resources\log4net.dll Name=log4net.dll / File Id=MainApp Source=Resources\TestApplication.exe Name=TestApplication.exe / /Component /Directory /Directory -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ 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). -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition based on a string in custom action
ARPINSTALLLOCATION is a property that people set to make their install location visible via supported MSI APIs. It doesn't get persisted into the uninstall environment unless you persist it, and the same is true of CUSTOMDIR. What are you trying to accomplish here? Phil Wilson -Original Message- From: Mark [mailto:m...@rcsal.com] Sent: Monday, August 29, 2011 2:10 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Condition based on a string in custom action have tried with and without CDATA tags, but can't get the behavior I want regardless of what I do! ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?define ProductName=myProdName ? ... SetProperty Id=ARPINSTALLLOCATION Value=[CUSTOMDIR] After=CostFinalize / ... Custom Action=myCustAct After=RemoveFoldersInstalled AND NOT UPGRADINGPRODUCTCODE AND (ARPINSTALLLOCATION gt;lt; $(var.ProductName)) /Custom ... The installation works beautifully, myCustAct is properly ignored on installations and upgrades (as expected), but when doing a removal: myCustAct always runs regardless of whether or not ARPINSTALLLOCATION contains the var.ProductName !!! It should only happen when the product name is found in (a part of) the ARPINSTALLLOCATION string ... can someone clue me in on how to correct this to get the behavior I'm after? I've tried: with and without quotes, and while the installation always builds and runs properly, I'm not getting the proper behavior on removal. :( Help? :) -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-based-on-a-string-in-custom-action-tp6739641p6739641.html Sent from the wix-users mailing list archive at Nabble.com. -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ 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). -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX Burn - Use of ARPSYSTEMCOMPONENT To Suppress MSI Files from Add/Remove Programs
ARPSYSTEMCOMPONENT is just a property you set in the property table of the MSI, like any other property. There's no need for anything special to set it. As I understand this property of MSI files, it will prevent the installation from writing any registry entries for the MSI in Add/Remove Programs. No - it still writes the registry entries. It just means you won't see your MSI shown in Add/Remove Programs. Phil Wilson -Original Message- From: Shaun Hayward [mailto:shayw...@omnivex.com] Sent: Monday, August 29, 2011 2:14 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] WiX Burn - Use of ARPSYSTEMCOMPONENT To Suppress MSI Files from Add/Remove Programs With thanks to Tobias and Cody, I'm making progress on WiX Burn with a managed WPF UI. I've used WiX to create an MSI and Burn to create a bootstrapper for it. After installing with the bootstrapper, I have two entries in Add/Remove programs: one for the MSI, one for the bootstrapper. There have been some messages suggesting the use of ARPSYSTEMCOMPONENT in the MSI to suppress its appearance in ARP. As I understand this property of MSI files, it will prevent the installation from writing any registry entries for the MSI in Add/Remove Programs. But I don't see it in the WiX 3.6 MSI, which uses Burn + WPF for deployment. How does Burn suppress the MSI entry in ARP when installing WiX 3.6 and (most importantly) what is the supported or official or recommended way of suppressing MSI entries with our own Burn-based solutions? Many thanks - Shaun The information in this e-mail is intended solely for the addressee and access by anyone else is unauthorized. Omnivex accepts no liability for the content of this e-mail, or for the consequences of any actions taken on the basis of the information provided. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. Omnivex makes no warranties, express or implied and is not responsible for errors or omissions. -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ 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). -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Auto deletion of reg values written by MSI
...and be aware that Permanent is a setting that gets propagated to the system. It's not just a project setting. I mention this because I've come across people who have a follow-up question that goes something like Now I've marked the component as not permanent anymore, why isn't it getting removed?. Phil W From: Rob Hamflett [r...@snsys.com] Sent: Monday, August 22, 2011 12:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Auto deletion of reg values written by MSI Try Component@Permanent='yes' Rob On 19/08/2011 18:19, Pratapa Reddy Sanaga wrote: Hi, Is there a way I can ask the MSI not to delete the registry values it has written to the MSI during uninstallation? I'm looking at the RegistryKey's Action options. create or createAndRemoveOnUninstall both delete the values that are written by RegistryValue element. I need to preserve those registry keys after the uninstallation also. Is there such an option? Thanks, Pratapa. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ 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). -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New file not installed
You'll need to post an entire MSI log of the issue and point out the file(s) that you believe should get installed but are not. Phil Wilson -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Thursday, August 18, 2011 7:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed thank you for the instruction unfortunately this did not fix my problem Kurt -Original Message- From: Tobias S [mailto:tobias.s1...@gmail.com] Sent: Thursday, August 18, 2011 7:07 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed see http://wix.sourceforge.net/manual-wix3/wix_xsd_upgradeversion.htm for description of UpgradeVersion Element. Default for MigrateFeatures is yes so my recommendation is to overwrite it. At first glance you should do it in the UpgradeVersion element where you do the major upgrade: UpgradeVersion Minimum=5.3.0 IncludeMinimum=yes Maximum=$(var.BGProductVersion) IncludeMaximum=no Language=1033 Property=UPGRADEFOUND MigrateFeatures=no / btw: OnlyDetect=yes You are normally using this construct for downgrade prevention meaning when a newer version of product is already installed on system 2011/8/18 Kurt Jensen kurt.jen...@us.ophiropt.com: MigrateFeatures=no I searched WiX and MSDN for documentation and an example. -please- explain how to '...set MigrateFeatures=no...' Kurt -Original Message- From: Tobias S [mailto:tobias.s1...@gmail.com] Sent: Thursday, August 18, 2011 3:15 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed sorry, should be MigrateFeatures=no 2011/8/18 Tobias S tobias.s1...@gmail.com: Is this new component in a feature whose state is not being migrated correctly by MigrateFeatureStates standard action? Try to set MigrateFeatureState=no -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ 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
Re: [WiX-users] New file not installed
Spiricon.Source.Gevicam.UI.dll is not installed; there are a number of things
wrong here:
=
MSI (c) (CC:18) [10:47:26:095]: Disallowing installation of
component:{CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3} since the same component with
higher versioned keyfile exists
MSI (s) (EC:E8) [10:48:21:859]: Executing
op:FileRemove(,FileName=Spiricon.Source.Gevicam.UI.dll,,ComponentId={3917713E-C01A-431E-A832-8E6F261CDBCE})
MSI (s) (EC:18) [10:48:26:172]: Executing
op:ComponentRegister(ComponentId={CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3},
KeyPath=C:\Program Files\Spiricon\BeamGage
Standard\Spiricon.Source.Gevicam.UI.dll,
=
The first and last log entries are saying that a file with the same component
id as Spiricon.Source.Gevicam.UI.dll is already installed with a higher version
, so it won't install it.
The middle log entry says you're removing Spiricon.Source.Gevicam.UI.dll, and
note that it has a different component ID.
It looks like you may have a file versioning issue because Windows is deciding
not to install the new one because a higher versioned one already exists.
However you also broke the sharing rules somehow because the two
Spiricon.Source.Gevicam.UI.dlls (in the old and the new inbstall) have
different component ids.
The story seems to be I'm not installing it because there's a higher version
already on the system and Nobody's using this Component guid any more so I'm
going to remove it
Phil Wilson
949-639-1680
-Original Message-
From: jjbean [mailto:jonks2...@yahoo.co.uk]
Sent: Thursday, August 18, 2011 12:42 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] New file not installed
Here's a clue:
MSI (c) (CC:18) [10:47:26:095]: Disallowing installation of component:
{CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3} since the same component with
higher versioned keyfile exists
...
...
MSI (s) (EC:18) [10:48:26:172]: Executing op:
ComponentRegister(ComponentId={CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3},KeyPa
th=C:\Program Files\Spiricon\BeamGage
Standard\Spiricon.Source.Gevicam.UI.dll,State=3,,Disk=1,SharedDllRefCount=
2,BinaryType=0)
SharedDllRefCount is 2, and this is a new dll? You did say that in an
earlier post didn't you?
The new dll should be in a new component with a unique GUID.
The log reads (although I'm probably not 100% accurate) as if you may have
reused an existing wix component to home a new dll. If this is the case, do
not do this.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/New-file-not-installed-tp6696061p6700572.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
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).
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting the WorkingDirectory of a shortcut to a per-user location
Working direcory is WkDir in the Shortcut table in the MSI file, and the documentation specifically says that you can put %USERPROFILE% in there, so maybe it just works the same way in WiX too. Phil Wilson -Original Message- From: John Daintree [mailto:jo...@dyalog.com] Sent: Wednesday, August 10, 2011 6:00 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Setting the WorkingDirectory of a shortcut to a per-user location Hello all, In an ALLUSER install, I'm trying to set up my desktop icon(s) so that the WorkingDirectory is set to a per-user location. If I do (bits omitted for clarity): Property Id=PERSONALFILES Value=%USERPROFILE%\My Documents\Our Files / Shortcut Id=shortcut.. WorkingDirectory=PERSONALFILES/ Then every user's Working Directory is set to c:\Documents and Settings\john\My Documents\Our Files (as john did the original ALLUSERS install) If I modify the shortcut by hand to contain the literal string %USERPROFILE%\My Documents\Our Files then Windows evaluates the variable as the process starts and the working directory is as I want it. So, in a nutshell, the question is how do I set the WorkingDirectory attribute to contain the literal text %USERPROFILE%? Thanks, John. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ 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). -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Create Database failed
The issue may be that a custom action running elevated during an install on a UAC system means runs with the system account and that may not have the required database permissions. Phil Wilson -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Wednesday, August 10, 2011 4:27 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Create Database failed Hi Not sure what the UAC behaviour is, but our install creates and upgrades databases on 2008, so in theory it is possible. I am assuming you are using SQL Server - you can check if it is permissions type issue by looking in the SQL Management Log - see if there are login problems or other errors around the create. I can't find the original blog for this information, but for a login issue there will be two entries in the SQL log: 2006-02-27 00:02:00.34 Logon Error: 18456, Severity: 14, State: 8. 2006-02-27 00:02:00.34 Logon Login failed for user 'user name'. [CLIENT: ip address] The State in the first entry gives the actual error: ERROR STATE ERROR DESCRIPTION 2 and 5Invalid userid 6 Attempt to use a Windows login name with SQL Authentication 7 Login disabled and password mismatch 8 Password mismatch 9 Invalid password 11 and 12 Valid login but server access failure 13 SQL Server service paused 16Does not have access to Database 18 Change password required Hope this helps Michael -Original Message- From: JesseBearden [mailto:jesse.bear...@oce.com] Sent: Thursday, 11 August 2011 5:46 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Create Database failed I /believe/ my question is: If an installation has InstalledPrivileges=Elevated then are deferred/impersonated custom actions run with elevated privileges on a UAC enabled environment? My issue is: I've written a small msi that creates a database and runs some scripts. This works fine on Windows 2003, but when I tried to run it on Windows 7 with UAC on I get an error that it was unable to create the database due to insufficient privileges. I know the admin group has rights to the database, but admin group doesn't mean a ton with UAC on(Until you elevate). The specific user running the installation does not have rights to the database other than being part of the admin group, which has rights to the database. The installation runs correctly from an elevated prompt. The odd part is that the uninstall correctly drops the database when launched via right click or add/remove programs, and I'd assume that that requires the same rights. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Create-Database-failed-tp6673860p6673860.html Sent from the wix-users mailing list archive at Nabble.com. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ 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
