Re: [WiX-users] Component install state not being recognized correctly
For all the problematic components, i see the following:
MSI (c) (14:9C) [16:11:09:263]: Disallowing installation of component:
{06F9816A-71E7-4B8E-860B-90E3BBF0B06C} since the same component with higher
versioned keyfile exists
MSI (c) (14:9C) [16:11:09:265]: Disallowing installation of component:
{B8D19D8C-27D4-450A-BA47-4FBF7D75C80C} since the same component with higher
versioned keyfile exists
MSI (c) (14:9C) [16:11:09:299]: Disallowing installation of component:
{14D99156-012C-474D-951C-DCAB0765B2A8} since the same component with higher
versioned keyfile exists
Also, for these components i see the following logged:
Installed: Absent; Request: Local; Action: Null; Client State: Unknown
Any help would be very much appreciated.
Thanks,
Kiran Hegde
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Component-install-state-not-being-recognized-correctly-tp7591845p7594367.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX missing 'Start In' property in desktop shortcut
I am working with WiX from last 5 month with no issues. Recently, i am in need to have StartIn property in App Desktop shortcut. By default, its empty. I am working with below code: *Component Id=myapplication.EXE DiskId=1 Guid=D42BBB80-579B-42B3-A65D-130829F2982D File Id=myapplication.EXE Name=My Application.exe Source=D:\My Application\My Application.exe Shortcut Id=desktopShortcut Directory=DesktopFolder Name=My Application WorkingDirectory=INSTALLDIR Icon=DesktopIcon.exe IconIndex=0 Description=My Application Description / Shortcut Id=ExeShortcut Directory=ProgramMenuDir Name=My Application Icon=StartMenuIcon.exe IconIndex=0 / /File/Component* But didn't worked. I have also tried adding Target property: *Shortcut Target= INSTALLDIR Id=desktopShortcut Directory=DesktopFolder Name=Virtual Sim Center Beta WorkingDirectory=INSTALLDIR Icon=DesktopIcon.exe IconIndex=0 Description=My Application Description /* but getting error message: The Shortcut/@Target attribute cannot be specified when the Shortcut element is nested underneath a File element. Please Help. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Immediate Custom Action could not be run in some computers.
Thanks for replying. I'm sure that there is no dependency problems. If I run the msi installer with elevated privilege on that user's computer, the install will finish successfully. It turns out Windows Installer failed to extract the custom action dll to temp directory during the InstallUISequence. When the error message box is shown, there is no MSI209E.tmp under the temp directory. But I tried using GetTempFileName on that user's computer, it succeeded and a temp file is created. On Tue, Apr 22, 2014 at 12:50 AM, Phil Wilson phildgwil...@gmail.comwrote: This is useful for showing C++ dependencies: http://www.dependencywalker.com/ --- Phil Wilson On Mon, Apr 21, 2014 at 9:07 AM, Carter Young ecyo...@grandecom.net wrote: Following Phil's Hunch, see here: http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html Carter Quoting Phil Wilson phildgwil...@gmail.com: 1157 is a missing dependency, so I'd assume that there's a dependency not installed on all computers. If it's a C++ Dll it'll most likely be a missing C run time. --- Phil Wilson On Sun, Apr 20, 2014 at 5:55 AM, uni unigauld...@gmail.com wrote: Hi all, I have sequenced a custom action in my msi after CostFinalize. On most user's computers, it works well. But on some user's computers, when the msi is double clicked directly for installing, it will prompt A DLL required for this install to complete could not be run. I've changed CheckIfAnotherProductExists function to only call MessageBox(0,0,0,0), and it still prompted the error and the message box is not showed. If I remove the CheckIfAnotherProductExists entry in the InstallExecuteSequence table, all goes well. If I run the msi in cmd(run as administrator), it works fine, there should be not dependency problem with my custom action dll. It acts as if it has something to do with the privilege. May be it failed when the custom action's dll is being copied into the temp directory, or maybe LoadLibrary failed under non elevated privilege? Does any one has experienced something like this? The WiX code is as below, === CustomAction Execute=immediate Id=CheckIfAnotherProductExists BinaryKey=MyDll DllEntry=CheckIfAnotherProductExists / Custom Action=CheckIfAnotherProductExists After=CostFinalize /Custom === The log is as below, === Action 14:20:31: CheckIfAnotherProductExists. Action start 14:20:31: CheckIfAnotherProductExists. MSI (c) (C4:B4) [14:20:31:680]: Invoking remote custom action. DLL: C:\Users\administrator\AppData\Local\Temp\MSI209E.tmp, Entrypoint: CheckIfAnotherProductExists MSI (c) (C4:88) [14:20:31:680]: Cloaking enabled. MSI (c) (C4:88) [14:20:31:680]: Attempting to enable all disabled privileges before calling Install on Server MSI (c) (C4:88) [14:20:31:680]: Connected to service for CA interface. CustomAction CheckIfAnotherProductExists returned actual error code 1157 (note this may not be 100% accurate if translation happened inside sandbox) MSI (c) (C4:D8) [14:20:31:740]: Note: 1: 1723 2: CheckIfAnotherProductExists 3: CheckIfAnotherProductExists 4: C:\Users\foxit\AppData\Local\Temp\MSI209E.tmp 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 CheckIfAnotherProductExists, entry: CheckIfAnotherProductExists, library: C:\Users\administrator\AppData\Local\Temp\MSI209E.tmp MSI (c) (C4:D8) [14:20:42:153]: Product: MyProduct -- 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 CheckIfAgentVersion, entry: CheckIfAgentVersion, library: C:\Users\foxit\AppData\Local\Temp\MSI209E.tmp === Any suggestion will be helpful. Gauldoth -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --
Re: [WiX-users] Setting property at a sequence
Thanks Bryan and Phil, Using only 'UPGRADINGPRODUCTCODE' worked to differentiate between Uninstall and Install cycle of an Upgrade. However this condition is false if Uninstalled from Add Remove Programs. I want the custom action to run in below two scenarios: 1. During Uninstall cycle of an Upgrade (only 'UPGRADINGPRODUCTCODE' works) 2. Uninstall from Add Remove Programs (only 'UPGRADINGPRODUCTCODE' does not work) Hence I modified the condition to be as: (Installed) OR (UPGRADINGPRODUCTCODE) It appears to be working fine now in all conditions. Thanks a lot for the help. Aparna Karkare LT Infotech OAI-sys, Enterprise Components and Frameworks Office: 020-6641-6142 Email: akark...@travelers.com -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: Friday, April 25, 2014 12:07 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Setting property at a sequence Bryan has it right. In the older install that is being uninstalled, REMOVE=ALL means it's being uninstalled, and UPGRADINGPRODUCTCODE is also set if it's being uninstalled by an upgrade. If you are in the new product being installed and you used the majorupgrade element, the WIX_UPGRADE_DETECTED property is set as the documentation says. Forget sequence numbers - they irrelevant. What matters is where actions are sequenced relative to other actions, not what the number is. Also, don't make the mistake of assuming that properties like UPGRADINGPRODUCTCODE are set to true or false, or 0 or 1. They are not, so don't use them like that in any conditions. --- Phil Wilson On Fri, Apr 25, 2014 at 7:08 AM, Bryan Wolf brw...@jackhenry.com wrote: Try the UPGRADINGPRODUCTCODE property[1] as well as the property associated with your Major Upgrade[2]. There's no need for all the custom actions. The Major Upgrade property is set for the version to be installed and the UPGRADINGPRODUCTCODE property is set for the version that is being upgraded/removed. So, in other words, if your sequence is being run with UPGRADINGPRODUCTCODE set then you are in a major upgrade removal. If the Major Upgrade property is set then you're performing a major upgrade of another version. [1] http://msdn.microsoft.com/en-us/library/aa372380(v=vs.85).aspx [2] http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.htm l -Original Message- From: Karkare,Aparna [mailto:akark...@travelers.com] Sent: Friday, April 25, 2014 6:25 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Setting property at a sequence Hi, I have a custom action which is sequenced to run at number 1554. When an Upgrade is happening, this custom action runs twice; 1st for Uninstall and then for Install. I want that this custom action should run only for Uninstall iteration and should skip at Install iteration internally when an Upgrade is happening (i.e. when Uninstall and Install both cycles run one after other). I couldn't find any condition which will separate these two scenarios (Uninstall and Install phase of an upgrade). There is no property which changes after the Uninstall cycle is over. REMOVE=ALL is true from the beginning till end of whole upgrade cycle. Hence I wrote another custom action which will set value of a property (UNINSTALLMARKED) at sequence number around 1555 so that when Install starts after Uninstall, I can use this property to differentiate between two scenarios. So My condition looks like below: Custom Action=QtExecHKCRHTTPImportProperty_Cmd Sequence=1554(REMOVE=ALL) AND (EXISTINGVERSION) AND (NOT UNINSTALLMARKED)/Custom EXISTINGVERSION property also is always set right from the beginning as it detects an Upgrade. I assumed when Uninstall cycle starts above condition will be true as 'UNINSTALLMARKED' will not be set at sequence number 1554. But it will be set at 1555. Hence this custom action will get executed for the Uninstall cycle and will be skipped for Install cycle as by then the 'UNINSTALLMARKED'' property will be set. However when I ran an Upgrade (run msi), below are the logs: MSI (s) (14:F4) [06:22:19:824]: Skipping action: QtExecHKCRHTTPImportProperty_Cmd (condition is false) MSI (s) (14:F4) [06:22:19:864]: PROPERTY CHANGE: Adding UNINSTALLMARKED property. Its value is 'UNINSTALLED'. I don't understand if the property is getting set after the custom action then why the condition is false? I believe out of three properties in the condition the culprit is 'UNINSTALLMARKED' as according to logs both other properties are getting set very early in the logs. Is it like even if I see property getting set later in the logs, it actually is set before itself? Below is how I am setting property. CustomAction Id=CA_MarkUninstall Property=UNINSTALLMARKED Value=UNINSTALLED Execute=immediate / Custom Action=CA_MarkUninstall Sequence=1555/Custom I basically need a condition which will
Re: [WiX-users] How implement installer to update single file ? Upgrade? Patch?
-Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Friday, April 25, 2014 11:30 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How implement installer to update single file ? Upgrade? Patch? If you have the old MSI, there are a couple of options (but I am no expert). If the old mis supports doing a /a layout then you can extract the files of the old msi to two folder tress, original and changed, change the files in the 'changed' folder tree, and use torch to create a transform. Or you can use orca in the old msi to find out which component the files is associated. Then create a new msi with only all of the files (resources) of that component, using the same component GUID, and run that msi to update the file. But the component must be identical to the component in the original package with regard to the guid, target path, and all resources included in that component. I am just learning and experimenting with a similar situation, so others can provide more expert advice. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-implement-installer-to-update-single-file-Upgrade-Patch-tp7594344p7594346.html Sent from the wix-users mailing list archive at Nabble.com. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix Visual Studio Unused components does not create an error
Hello, I'm using wix 3.8 in Visual Studio 2010. If I have 2 components in a fragment in a wxs file and I only reference one of them in a feature I get an ICE21 error. If I have a wxs file with components where none of the components are part of a feature I get no error, the components are just silently skipped. Is this the desired behaviour? Is there a way to force an error message in this case? Jan Obrestad -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] within MSI capture user cancelled... [P]
Classification: Public I tried rollback but it isn't between installinitialize and installfinalize so it errors when you start the MSI :( -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: April-27-14 1:13 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] within MSI capture user cancelled... I am probably misunderstanding the UI flow here, but why is anything happening before the user has made an upgrade choices? Typically this would all be in the UI sequence where the system isn't supposed to be affected. In the actual execute sequence this type of recovery is handled with rollback CAs. --- Phil Wilson On Sat, Apr 26, 2014 at 11:19 AM, Steve-Ogilvie steven.ogil...@titus.com wrote: Hi On an upgrade (after the user selected yes to upgrade on a messagebox) I stop our Web App Pool, and our Web Site. However if the user Cancels the install BEFORE choosing to install the upgrade (verify ready screen install button) our application is in limbo because the web app pool and web site are stopped... I want to capture if the user hits Cancel so I can run a custom action to start the web app pool first then the web site using appcmd.exe (not a deferred custom action) I tried using Custom Action=CA_Upgrade_Start_Apppool.SetProperty After=CA_DISPLAY_UPGRADE_DETECTEDWIX_UPGRADE_DETECTED/Custom Custom Action=CA_UPGRADE_START_APPPOOL OnExit=cancel WIX_UPGRADE_DETECTED/Custom but when I try to compile I get a error that ExitUser is already using that OnExit=cancel Error 14 ICE82: This action UserExit has duplicate sequence number -2 in the table InstallUISequence C:\Dev\SetupCommon\Main\WIX_ToolSet_v3.8\src\ext\UIExtension\wixlib\UserExit.wxs 26 1 Admin_Console_Setup InstallUISequence table: Action Condition Sequence CA_UPGRADE_START_APPPOOLWIX_UPGRADE_DETECTED-2 UserExit -2 not sure on how to handle this, any help would be appreciated! thanks, Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/within-M SI-capture-user-cancelled-tp7594359.html Sent from the wix-users mailing list archive at Nabble.com. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message has been marked as Public by Steven Ogilvie on April-28-14 9:48:38 AM. The above classification labels were added to the message by TITUS Message Classification. For more information visit www.titus.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Restart manager, services, unattended installs
Ok, I have discovered something else. For other reasons I've started developing a little notification application for our users. This is to run at login and stay running while they go about their use. It will from time to time remind them of things they should be doing and that sort of thing. Long story short, it stays running, so when it is updated (as I am now testing) it is running. This provokes the RestartManager dialogue when installed interactively and works if OK is selected. It also installs well with /quiet /norestart. What is different between this and the service? Is it because msiexec was called *from* the service in question in the sitation below? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: Douglas, Keith - CoSD/DSCo Sent: April-25-14 1:22 PM To: General discussion about the WiX toolset. Subject: RE: [WiX-users] Restart manager, services, unattended installs Do I have to have created a proper ServiceControl *before* I do the upgrade, or can my new package do everything? In any case, I do have ServiceControl Stop=both and Wait=yes in the *existing* packages (including the one which was causing some people trouble), so something is funny. Is there a problem with the name: some services use an 8 character name, but I've never had any other trouble with EscalationService as a name, so ... As for the restart, there's a situation's explanation missing: how do the command line arguments to msiexec work? (/quiet and /norestart.) Does that work to simply *stop* the restart you mentioned? Or does it fail the install because it can't tell you it is about to do so because of /quiet? Or does it just do it? Do those interact with RestartManager in any way? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: April-25-14 1:05 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Restart manager, services, unattended installs You haven't said (or I missed it) if you're using ServiceControl - you can use that to shut down the service and restart it after the upgrade. In most cases that will mitigate any files-in-use situations because Windows looks at the ServiceControl table to see if the service will be shut down. That may make a difference in your case. If it's a completely silent install, it'll stay silent. There'll be no dialogs, and if a reboot is needed it will just do it - it can't prompt in a silent install, and a reboot is needed to complete the install so it does it. --- Phil Wilson On Fri, Apr 25, 2014 at 8:28 AM, Marc Beaudry mbeau...@matrox.com wrote: Hi Keith, Not sure that the Util:RestartResource does but have you tried something simple like: Property Id=REBOOT Value=ReallySuppress/Property I am using this: Property Id=MSIRESTARTMANAGERCONTROL Value=Disable/ Property Id=REBOOT Value=ReallySuppress/Property And all my reboots seem suppressed. Hope this helps, Marc -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: April-25-2014 9:50 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Restart manager, services, unattended installs Hi Marc, I think I'm finally piecing this together: the only very missing part is the interaction with /quiet - if I am not mistaken. But I have one question for everyone: Util:RestartResource - does one use that to register that one wants to restart an *existing* application / service, or does it flag part of one's installation as sensitive for the changes to *it*? If it is the latter, I will be no further ahead until I install an update which includes that, presumably. (Once I also set MSIRMSHUTDOWN=2 and MSIDISABLERMRESTART=0) My question is the dual to the one on stackoverflow: 8354767. The person there wants to prevent auto-kill; I want to do the opposite (to ensure that the installation succeeds). Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: Marc Beaudry [mailto:mbeau...@matrox.com] Sent: April-24-14 5:31 PM To: 'General discussion about
Re: [WiX-users] Application pool creation
All the assemblies and config files are present after upgrade Le Vendredi 25 avril 2014 17h57, John Cooper jocoo...@jackhenry.com a écrit : Something is definitely wrong with the code. Are all the assemblies and config files present after upgrade? I never see this unless something is missing. -- 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: eric foka [mailto:nanafo...@yahoo.fr] Sent: Friday, April 25, 2014 3:27 PM To: 'General discussion about the WiX toolset.' Subject: [WiX-users] Application pool creation Hi I am using Wix to create an application pool with an identity of a custom account. When I do a major upgrade the application pool is stopped. and I get a service unavailable message when I try to access the website that uses this application pool. the application pool is stopped and I get Service Unavailable message. Can somebody help me for this problem. Thx -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installer runs OK via msiexec but fails when double-clicked
I have an installer that invokes InstallUtilLib.dll via a set of CAs as documented in http://blogs.msdn.com/b/josealmeida/archive/2004/11/08/253831.aspx http://avinashkt.blogspot.co.uk/2007/05/how-to-create-installer-using-wix-which.html If I simply double-click on the MSI or run it using msiexec (NOT as an administrator) then it fails with Error 2869! The relevant files from the logfile (msiexec /Log ...) are Action 17:17:50: Install. DEBUG: Error 2869: The dialog ErrorDlg has the error style bit set, but is not an error dialog The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDlg, , MSI (c) (44:C0) [17:17:52:800]: Product: OpenPKI Tools -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDlg, , Error 1001. MSI (s) (04!EC) [17:17:52:800]: DEBUG: Error 2769: Custom Action Install did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: Install, 1, CustomAction Install returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 17:17:52: InstallFinalize. Return value 3. Action 17:17:52: Rollback. Rolling back action: If I run the installer via msiexec AS AN ADMINISTRATOR it works fine! For reference - the set of CAs, including the custom action Install to which the Error 2769 refers is as follows: - InstallExecuteSequence Custom Action=InstallSetProp After=StartServices$WmiProvidergt;2/Custom Custom Action=Install After=InstallSetProp$WmiProvidergt;2/Custom Custom Action=UninstallSetProp After=MsiUnpublishAssemblies$WmiProvider=2/Custom Custom Action=Uninstall After=UninstallSetProp$WmiProvider=2/Custom Custom Action=CommitSetProp After=Rollback$WmiProvidergt;2/Custom Custom Action=Commit After=CommitSetProp$WmiProvidergt;2/Custom Custom Action=RollbackSetProp After=Install$WmiProvidergt;2/Custom Custom Action=Rollback After=RollbackSetProp$WmiProvidergt;2/Custom /InstallExecuteSequence CustomAction Id=Uninstall BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=deferred / CustomAction Id=UninstallSetProp Property=Uninstall Value=' /installtype=notransaction /action=uninstall /Logfile= [#WmiProviderDLL] [#WmiProviderDLLConfig]' / CustomAction Id=Install BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=deferred / CustomAction Id=InstallSetProp Property=Install Value=' /installtype=notransaction /action=install /Logfile= [#WmiProviderDLL] [#WmiProviderDLLConfig]' / CustomAction Id=Rollback BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=rollback / CustomAction Id=RollbackSetProp Property=Rollback Value=' /installtype=notransaction /action=rollback /Logfile= [#WmiProviderDLL] [#WmiProviderDLLConfig]' / CustomAction Id=Commit BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=commit / CustomAction Id=CommitSetProp Property=Commit Value=' /installtype=notransaction /action=commit /Logfile= [#WmiProviderDLL] [#WmiProviderDLLConfig]' / Am I missing something that should be obvious? It feels as if the CAs are not being run with admin rights (even though I am prompted). All suggestions gratefully received. Apologies in advance if this is a FAQ with a well known answer that I've missed! Regards David -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX missing 'Start In' property in desktop shortcut
The shortcut should be under the Component tag, not the file tag, as described in the Stack Overflow answer to your question there. If that's not working then you could supply a bit more info about what you've tried. --- Phil Wilson On Sun, Apr 27, 2014 at 11:18 PM, Satbir Singh ig.sat...@gmail.com wrote: I am working with WiX from last 5 month with no issues. Recently, i am in need to have StartIn property in App Desktop shortcut. By default, its empty. I am working with below code: *Component Id=myapplication.EXE DiskId=1 Guid=D42BBB80-579B-42B3-A65D-130829F2982D File Id=myapplication.EXE Name=My Application.exe Source=D:\My Application\My Application.exe Shortcut Id=desktopShortcut Directory=DesktopFolder Name=My Application WorkingDirectory=INSTALLDIR Icon=DesktopIcon.exe IconIndex=0 Description=My Application Description / Shortcut Id=ExeShortcut Directory=ProgramMenuDir Name=My Application Icon=StartMenuIcon.exe IconIndex=0 / /File/Component* But didn't worked. I have also tried adding Target property: *Shortcut Target= INSTALLDIR Id=desktopShortcut Directory=DesktopFolder Name=Virtual Sim Center Beta WorkingDirectory=INSTALLDIR Icon=DesktopIcon.exe IconIndex=0 Description=My Application Description /* but getting error message: The Shortcut/@Target attribute cannot be specified when the Shortcut element is nested underneath a File element. Please Help. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Immediate Custom Action could not be run in some computers.
By default immediate custom actions run with limited user rights (even if the user is admin) because the UI sequence isn't elevated by default. So it might be a security issue on UAC systems. --- Phil Wilson On Mon, Apr 28, 2014 at 1:50 AM, Uni Gauldoth unigauld...@gmail.com wrote: Thanks for replying. I'm sure that there is no dependency problems. If I run the msi installer with elevated privilege on that user's computer, the install will finish successfully. It turns out Windows Installer failed to extract the custom action dll to temp directory during the InstallUISequence. When the error message box is shown, there is no MSI209E.tmp under the temp directory. But I tried using GetTempFileName on that user's computer, it succeeded and a temp file is created. On Tue, Apr 22, 2014 at 12:50 AM, Phil Wilson phildgwil...@gmail.comwrote: This is useful for showing C++ dependencies: http://www.dependencywalker.com/ --- Phil Wilson On Mon, Apr 21, 2014 at 9:07 AM, Carter Young ecyo...@grandecom.net wrote: Following Phil's Hunch, see here: http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html Carter Quoting Phil Wilson phildgwil...@gmail.com: 1157 is a missing dependency, so I'd assume that there's a dependency not installed on all computers. If it's a C++ Dll it'll most likely be a missing C run time. --- Phil Wilson On Sun, Apr 20, 2014 at 5:55 AM, uni unigauld...@gmail.com wrote: Hi all, I have sequenced a custom action in my msi after CostFinalize. On most user's computers, it works well. But on some user's computers, when the msi is double clicked directly for installing, it will prompt A DLL required for this install to complete could not be run. I've changed CheckIfAnotherProductExists function to only call MessageBox(0,0,0,0), and it still prompted the error and the message box is not showed. If I remove the CheckIfAnotherProductExists entry in the InstallExecuteSequence table, all goes well. If I run the msi in cmd(run as administrator), it works fine, there should be not dependency problem with my custom action dll. It acts as if it has something to do with the privilege. May be it failed when the custom action's dll is being copied into the temp directory, or maybe LoadLibrary failed under non elevated privilege? Does any one has experienced something like this? The WiX code is as below, === CustomAction Execute=immediate Id=CheckIfAnotherProductExists BinaryKey=MyDll DllEntry=CheckIfAnotherProductExists / Custom Action=CheckIfAnotherProductExists After=CostFinalize /Custom === The log is as below, === Action 14:20:31: CheckIfAnotherProductExists. Action start 14:20:31: CheckIfAnotherProductExists. MSI (c) (C4:B4) [14:20:31:680]: Invoking remote custom action. DLL: C:\Users\administrator\AppData\Local\Temp\MSI209E.tmp, Entrypoint: CheckIfAnotherProductExists MSI (c) (C4:88) [14:20:31:680]: Cloaking enabled. MSI (c) (C4:88) [14:20:31:680]: Attempting to enable all disabled privileges before calling Install on Server MSI (c) (C4:88) [14:20:31:680]: Connected to service for CA interface. CustomAction CheckIfAnotherProductExists returned actual error code 1157 (note this may not be 100% accurate if translation happened inside sandbox) MSI (c) (C4:D8) [14:20:31:740]: Note: 1: 1723 2: CheckIfAnotherProductExists 3: CheckIfAnotherProductExists 4: C:\Users\foxit\AppData\Local\Temp\MSI209E.tmp 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 CheckIfAnotherProductExists, entry: CheckIfAnotherProductExists, library: C:\Users\administrator\AppData\Local\Temp\MSI209E.tmp MSI (c) (C4:D8) [14:20:42:153]: Product: MyProduct -- 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 CheckIfAgentVersion, entry: CheckIfAgentVersion, library: C:\Users\foxit\AppData\Local\Temp\MSI209E.tmp === Any suggestion will be helpful. Gauldoth -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available.
Re: [WiX-users] Installer runs OK via msiexec but fails when double-clicked
I'd back up from the error 2869 and see what's before that. That error is when it's decides to show you an error but doesn't like the error dialog, and the actual error is prior to that. Where did you get that error dialog from? That's a common error in Visual Studio setup projects, so did you import their dialogs into a WiX setup? InstallUtilLib.dll is also a Visual Studio setup project thing. I'd avoid it because it's unsupported since VS dropped setup projects, may have the wrong bitness depending on your install, and I don't know if you're even supposed to redistribute it like that. There's got to be a way to accomplish the task without it. If you just ported the setup from a Visual Studio MSI then I don't know if you'll get proper UAC handling, depending on the version of VS. If the install is set up right the install should explicitly ask for elevation after the UI sequence, because the install needs it. That might be the issue, but look for the error just before the 2869. --- Phil Wilson On Mon, Apr 28, 2014 at 9:58 AM, David Allen d.al...@qub.ac.uk wrote: I have an installer that invokes InstallUtilLib.dll via a set of CAs as documented in http://blogs.msdn.com/b/josealmeida/archive/2004/11/08/253831.aspx http://avinashkt.blogspot.co.uk/2007/05/how-to-create-installer-using-wix-which.html If I simply double-click on the MSI or run it using msiexec (NOT as an administrator) then it fails with Error 2869! The relevant files from the logfile (msiexec /Log ...) are Action 17:17:50: Install. DEBUG: Error 2869: The dialog ErrorDlg has the error style bit set, but is not an error dialog The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDlg, , MSI (c) (44:C0) [17:17:52:800]: Product: OpenPKI Tools -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDlg, , Error 1001. MSI (s) (04!EC) [17:17:52:800]: DEBUG: Error 2769: Custom Action Install did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: Install, 1, CustomAction Install returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 17:17:52: InstallFinalize. Return value 3. Action 17:17:52: Rollback. Rolling back action: If I run the installer via msiexec AS AN ADMINISTRATOR it works fine! For reference - the set of CAs, including the custom action Install to which the Error 2769 refers is as follows: - InstallExecuteSequence Custom Action=InstallSetProp After=StartServices$WmiProvidergt;2/Custom Custom Action=Install After=InstallSetProp$WmiProvidergt;2/Custom Custom Action=UninstallSetProp After=MsiUnpublishAssemblies$WmiProvider=2/Custom Custom Action=Uninstall After=UninstallSetProp$WmiProvider=2/Custom Custom Action=CommitSetProp After=Rollback$WmiProvidergt;2/Custom Custom Action=Commit After=CommitSetProp$WmiProvidergt;2/Custom Custom Action=RollbackSetProp After=Install$WmiProvidergt;2/Custom Custom Action=Rollback After=RollbackSetProp$WmiProvidergt;2/Custom /InstallExecuteSequence CustomAction Id=Uninstall BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=deferred / CustomAction Id=UninstallSetProp Property=Uninstall Value=' /installtype=notransaction /action=uninstall /Logfile= [#WmiProviderDLL] [#WmiProviderDLLConfig]' / CustomAction Id=Install BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=deferred / CustomAction Id=InstallSetProp Property=Install Value=' /installtype=notransaction /action=install /Logfile= [#WmiProviderDLL] [#WmiProviderDLLConfig]' / CustomAction Id=Rollback BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=rollback / CustomAction Id=RollbackSetProp Property=Rollback Value=' /installtype=notransaction /action=rollback /Logfile= [#WmiProviderDLL] [#WmiProviderDLLConfig]' / CustomAction Id=Commit BinaryKey=InstallUtil DllEntry=ManagedInstall Execute=commit / CustomAction Id=CommitSetProp Property=Commit Value=' /installtype=notransaction /action=commit /Logfile= [#WmiProviderDLL] [#WmiProviderDLLConfig]' / Am I missing something that should be obvious? It feels as if the CAs are not being run with admin rights (even though I am prompted). All suggestions gratefully received. Apologies in advance if this is a FAQ with a well known answer that I've missed! Regards David -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium
Re: [WiX-users] How implement installer to update single file ? Upgrade? Patch?
Thank you Phil.
I am trying the Using Patch Creation Properties approach. I made two
subfolders, 3.8.1 contained only the original DLL I wished to replace, and
3.8.2 the updated DLL.
http://wixtoolset.org/documentation/manual/v3/patching/patch_building.html
Should both UpgradeCode and Product ID match the original 3.81 version seen in
Orca?
When both match the original 3.8.1 MSI the patch launches the 3.8.1
repair/remove installer.
msiexec.exe /p patch\patch.msp /l*vx patch.log
When only UpgradeCode matches the Windows Installer displays a dialog with
message:
The upgrade patch cannot be installed because program to be upgraded may be
missing.
===Orca Properties Displayed With Original 3.8.1 MSI===
Table: Property
Manufacturer The Charles Machine Works, Inc.
ProductCode{C80FB86A-42A1-4FB8-B9B2-30DCFF138E3D}
ProductNameTMS Plus
ProductVersion 3.8.1
UpgradeCode{59BF7F9E-FF46-45D5-8050-F1477466A661}
Table: File
_ACE1F72023AD44F5829BCA1329E212FD C__ACE1F72023AD44F5829BCA1329E212FD
REGTMS.DLL|Regtms.dll 40960 1.0.0.2 1033514 80
Table: Component
C__ACE1F72023AD44F5829BCA1329E212FD{CFB9D5A8-65CC-E091-DC21-4F4653B149D6}
TARGETDIR 0 _ACE1F72023AD44F5829BCA1329E212FD
Table: FeatureComponents
DefaultFeature C__ACE1F72023AD44F5829BCA1329E212FD
Table: Feature
DefaultFeature 2 1 TARGETDIR 0
Table: Directory
TARGETDIR SourceDir
Table: CreateFolder
TARGETDIR C__A0F5E19C01BE425EB5FD3CE9A5BBB86D
Table: CustomAction
DIRCA_TARGETDIR307 TARGETDIR [ProgramFilesFolder]TMSPlus
*
* File: product.wxs
*
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=5ABB1D50-4D36-4630-B38B-4748D59EF5EA
Name=TMS Plus Patch Example
Language=1033
Version=3.8.1
Manufacturer=The Charles Machine Works, Inc.
UpgradeCode=59BF7F9E-FF46-45D5-8050-F1477466A661
Package Description=Installs a file that will be patched.
Comments=This Product does not install any executables
InstallerVersion=200
Compressed=yes /
Media Id=1 Cabinet=product.cab EmbedCab=yes /
FeatureRef Id=DefaultFeature/
/Product
Fragment
Feature Id=DefaultFeature Title=Sample Product Feature Level=1
ComponentRef Id=SampleComponent /
/Feature
/Fragment
Fragment
DirectoryRef Id=TARGETDIR
Component Id=SampleComponent
Guid=CFB9D5A8-65CC-E091-DC21-4F4653B149D6 DiskId=1
File Id=_ACE1F72023AD44F5829BCA1329E212FD Name=Regtms.dll
Source=.\$(var.Version)\Regtms.dll /
/Component
/DirectoryRef
/Fragment
Fragment
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=SampleProductFolder Name=TMSPlus
/Directory
/Directory
/Directory
/Fragment
/Wix
*
* File: Patch.wxs
*
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
PatchCreation
Id=FD1DFB39-D96C-4E06-8247-F2A9AD4BFCB4
CleanWorkingFolder=yes
OutputPath=patch.pcp
WholeFilesOnly=yes
PatchInformation
Description=Small Update Patch
Comments=Small Update Patch
ShortNames=no
Languages=1033
Compressed=yes
Manufacturer=Dynamo Corp/
PatchMetadata
AllowRemoval=yes
Description=Small Update Patch
ManufacturerName=The Charles Machine Works, Inc.
TargetProductName=TMS Plus Patch Sample
MoreInfoURL=http://www.ditchwitch.com/;
Classification=Update
DisplayName=TMS Plus Patch Sample/
Family DiskId=5000
MediaSrcProp=Sample
Name=Sample
SequenceStart=5000
UpgradeImage SourceFile=3.8.2\admin\product.msi
Id=SampleUpgrade
TargetImage SourceFile=3.8.1\admin\product.msi Order=2
Id=SampleTarget IgnoreMissingFiles=no /
/UpgradeImage
/Family
PatchSequence PatchFamily=SamplePatchFamily
Sequence=1.0.0.0
Supersede=yes /
/PatchCreation
/Wix
Any direction is much appreciated,
-Ed
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, April 25, 2014 11:30 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How implement installer to update single file ?
Upgrade? Patch?
If you have the old MSI, there are a couple of options (but I am no expert).
If the old mis supports doing a /a layout then you can extract the files of the
old msi to two folder tress, original and changed, change the files in the
'changed' folder tree, and
[WiX-users] [SPAM] Re: How implement installer to update single file ? Upgrade? Patch?
While I have not used that process, my understanding is that you are creating a 'small update' patch for the original version of the two MSI files (used in that process). (The updated version of the two MSI files is not distributed. Only the original MSI and the patch which targets only that original MSI.) So in the case where the original MSI is installed and you apply the patch it sounds like it worked. In the case were you tried to apply the patch using a different ProductCode it makes sense that the error message indicated that it could not find the ProductCode indicated on the installed system, as the original MSI did not use that code. I do not have much experience in this area as I am just working through some of these issues myself. So there may be others who can provide better guidance. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-implement-installer-to-update-single-file-Upgrade-Patch-tp7594344p7594388.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [SPAM] Re: How implement installer to update single file ? Upgrade? Patch?
Are there others experienced in patching/updating that can share an example or offer advice? I followed the Using Patch Creation Properties tutorial which installs an updated sample.txt file. This worked well. http://wixtoolset.org/documentation/manual/v3/patching/patch_building.html Next I copied the working tutorial and started to modify it to do same for updating a DLL instead of the sample.txt file. I have the original 3.8.1 version of the MSI which installs an executable and a DLL. It is only the DLL that I need to replace and not the executable. I suspect my problem may not be setting up matches of the original ids, guids, or references that Orca displays in the original 3.8.1 MSI. 1 - I created a new /3.8.1/product.msi containing the original DLL extracted from the original 3.8.1 version on the MSI. In the product.wxs file I set ProductId and UpgradeCode to match original MSI. 2 - I created a second /3.8.2/product.msi containing the updated DLL. The executable (*.exe) was not changed, only the DLL, so exe was not included. 3 - The patch.msp was created from the patch.wxs from the /3.8.1/product.msi and /3.8.2/product.msi files. My patch has no GUI. When I set my product.wxs ProductId and UpgradeCode to match the original 3.8.1 MSI it launching the patch results in launching of the original installer GUI in repair/remove mode. I tried to do a repair. I confirmed this did *not* update the DLL. I think this is expected when launching original installer. If the patch install would have worked, I expected to see UAC request elevation as it does with the tutorial that installs the pdated sample.txt file. msiexec.exe /p patch\patch.msp /l*vx patch.log Phil it sounds like you are picking this up pretty quickly - I am impressed. I have always struggled with MSI and find it complex. I usually use deployment tools included with Visual Studio, crippled InstallShield versions, Wise Installer, etc. I am trying to take better notes this time as I always have to relearn what I figured out years past. It would like to figure out WiX and start using it with all new projects I have coming up. It sounds like WiX has been around since 2007 and is not likely to disappear. I know I am missing something. Probably multiple things. Any suggestions or patch examples are welcome. -Ed -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Monday, April 28, 2014 1:45 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] [SPAM] Re: How implement installer to update single file ? Upgrade? Patch? While I have not used that process, my understanding is that you are creating a 'small update' patch for the original version of the two MSI files (used in that process). (The updated version of the two MSI files is not distributed. Only the original MSI and the patch which targets only that original MSI.) So in the case where the original MSI is installed and you apply the patch it sounds like it worked. In the case were you tried to apply the patch using a different ProductCode it makes sense that the error message indicated that it could not find the ProductCode indicated on the installed system, as the original MSI did not use that code. I do not have much experience in this area as I am just working through some of these issues myself. So there may be others who can provide better guidance. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-implement-installer-to-update-single-file-Upgrade-Patch-tp7594344p7594388.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any
Re: [WiX-users] Installer runs OK via msiexec but fails when double-clicked
Phil, Many thanks for the comments. To answer your questions ... So far as I recall, there were no other errors recorded in the log file - I'll check again in the morning. So far as I know, the error dialog is standard WiX 3.8. I haven't consciously imported anything from Visual Studio. I created the WiX project within Visual Studio 2010 using the WiX-supplied template and essentially wrote the was from scratch. I hear what you're saying regarding InstalUtilLib.dll! I have got the InstallUtil is evil and harmful message loud and clear. However, I'm trying to install a (.NET) WMI provider and, for that, InstallUtil (in the form of InstallUtilLib.dll) appears to be the only game in town. If anyone can point me to a working example of a viable alternative I'll be only too happy to use it. I've done a reasonable amount of searching and I've tried things like invoking the .NET installer class with no success. (Interestingly, that also appeared to work (ie the installer completed without error - it just didn't install the WMI class properly) when run via msi exec from an elevated shell but threw an exception (from the deferred CA) when run by double-clicking the msi - more or less similar symptoms!) InstallUtilLib.dll currently feels like the Last Chance Saloon. As regards VS MSIs - there haven't been any involved. The install DOES explicitly ask for elevation after the UI sequence. Having said all the above, one thing does occur to me. I have a VC++ project (complete with VS-supplied merge module for the VC++ redistributable) in the same installer. Could that be supplying the error dialog? I'll try removing that and see what happens. Thanks again for the response. I'm very new to WiX (and MSIs) so still trying to get this clear in my head. Regards David On 28 Apr 2014, at 18:34, Phil Wilson phildgwil...@gmail.com wrote: I'd back up from the error 2869 and see what's before that. That error is when it's decides to show you an error but doesn't like the error dialog, and the actual error is prior to that. Where did you get that error dialog from? That's a common error in Visual Studio setup projects, so did you import their dialogs into a WiX setup? InstallUtilLib.dll is also a Visual Studio setup project thing. I'd avoid it because it's unsupported since VS dropped setup projects, may have the wrong bitness depending on your install, and I don't know if you're even supposed to redistribute it like that. There's got to be a way to accomplish the task without it. If you just ported the setup from a Visual Studio MSI then I don't know if you'll get proper UAC handling, depending on the version of VS. If the install is set up right the install should explicitly ask for elevation after the UI sequence, because the install needs it. That might be the issue, but look for the error just before the 2869. --- Phil Wilson On Mon, Apr 28, 2014 at 9:58 AM, David Allen d.al...@qub.ac.uk wrote: I have an installer that invokes InstallUtilLib.dll via a set of CAs as documented in http://blogs.msdn.com/b/josealmeida/archive/2004/11/08/253831.aspx http://avinashkt.blogspot.co.uk/2007/05/how-to-create-installer-using-wix-which.html If I simply double-click on the MSI or run it using msiexec (NOT as an administrator) then it fails with Error 2869! The relevant files from the logfile (msiexec /Log ...) are Action 17:17:50: Install. DEBUG: Error 2869: The dialog ErrorDlg has the error style bit set, but is not an error dialog The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDlg, , MSI (c) (44:C0) [17:17:52:800]: Product: OpenPKI Tools -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDlg, , Error 1001. MSI (s) (04!EC) [17:17:52:800]: DEBUG: Error 2769: Custom Action Install did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: Install, 1, CustomAction Install returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 17:17:52: InstallFinalize. Return value 3. Action 17:17:52: Rollback. Rolling back action: If I run the installer via msiexec AS AN ADMINISTRATOR it works fine! For reference - the set of CAs, including the custom action Install to which the Error 2769 refers is as follows: - InstallExecuteSequence Custom Action=InstallSetProp After=StartServices$WmiProvidergt;2/Custom Custom Action=Install After=InstallSetProp$WmiProvidergt;2/Custom Custom Action=UninstallSetProp After=MsiUnpublishAssemblies$WmiProvider=2/Custom Custom
Re: [WiX-users] Installer runs OK via msiexec but fails when double-clicked
Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar basti...@careercontrol.nl. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installer runs OK via msiexec but fails when double-clicked
Hello, I know you said the installer prompts for elevated but do you have this? InstallPrivileges=elevated InstallScope=perMachine/ In the package ID section in your product.wxs file. On Mon, Apr 28, 2014 at 5:46 PM, b.ras...@leonit.nl wrote: Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar basti...@careercontrol.nl. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- They may forget what you said but they will never forget how you made them feel. -- Anonymous -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
