Re: [WiX-users] ExecSecureObjects action need very long time
Hi,
I'm one step further.
The action setAccessRights is not involved - I had removed it for my
tests.
So I just found
DirectoryRef Id=Directory.ProgramData.Contest
Component Id=Component.Directory.ProgramData.Contest Guid=
{9AAF8540-6580-42A7-ACD0-F7806BAD12F5}
CreateFolder Directory=Directory.ProgramData.Contest
util:PermissionEx User=Everyone GenericAll=yes /
/CreateFolder
/Component
/DirectoryRef
A colleague has introduced the PermissionEx util :-)
Is there a way to exclude some special subfolders?
Thanks,
Thomas
Von:thomas.deboben@rohde-schwarz.com
An: General discussion about the WiX toolset.
wix-users@lists.sourceforge.net,
Datum: 06.07.2015 11:38
Betreff:Re: [WiX-users] ExecSecureObjects action need very long
time
I just added a false condition to my setAccessRights action so the action
was skipped., but still the ExecSecureObjects action does took much
longer with many files in my ProgramData folder. :-(
How can I control ExecSecureObjects?
Thanks,
Thomas
Von:thomas.deboben@rohde-schwarz.com
An: General discussion about the WiX toolset.
wix-users@lists.sourceforge.net,
Datum: 06.07.2015 11:05
Betreff:Re: [WiX-users] ExecSecureObjects action need very long
time
Hi Rob,
in the scenarion where the QA has reported this behaviour my
setAccessRights action had a bug and did not do anything, so no ACLs where
changed :-(
But how is setAccessRightsinvolved and what will this action do?
If I could find a way to set a condition for the setAccessRights action to
false in the way I don't change ACLs a second time would this prevent
ExecSecureObjects checking my folder?
Thanks,
Thomas
Von:Rob Mensching r...@firegiant.com
An: General discussion about the WiX toolset.
wix-users@lists.sourceforge.net,
Datum: 02.07.2015 11:36
Betreff:Re: [WiX-users] ExecSecureObjects action need very long
time
Yeah, okay then. Resetting the ACLs on lots and lots of files can take
lots and lots of time.
_
Short replies here. Complete answers over there:
http://www.firegiant.com/
-Original Message-
From: thomas.deboben@rohde-schwarz.com [
mailto:thomas.deboben@rohde-schwarz.com]
Sent: Thursday, July 2, 2015 2:22 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] ExecSecureObjects action need very long time
Hi Rob,
on one system yes 1.3 million files so the installer run 40 min. After
removing these files the installer performed fine again.
On the other system where I added the trace infos onle 215 files with
55MB.
Cheers,
Thomas
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExecSecureObjects action need very long time
Hi Rob, in the scenarion where the QA has reported this behaviour my setAccessRights action had a bug and did not do anything, so no ACLs where changed :-( But how is setAccessRightsinvolved and what will this action do? If I could find a way to set a condition for the setAccessRights action to false in the way I don't change ACLs a second time would this prevent ExecSecureObjects checking my folder? Thanks, Thomas Von:Rob Mensching r...@firegiant.com An: General discussion about the WiX toolset. wix-users@lists.sourceforge.net, Datum: 02.07.2015 11:36 Betreff:Re: [WiX-users] ExecSecureObjects action need very long time Yeah, okay then. Resetting the ACLs on lots and lots of files can take lots and lots of time. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: thomas.deboben@rohde-schwarz.com [ mailto:thomas.deboben@rohde-schwarz.com] Sent: Thursday, July 2, 2015 2:22 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] ExecSecureObjects action need very long time Hi Rob, on one system yes 1.3 million files so the installer run 40 min. After removing these files the installer performed fine again. On the other system where I added the trace infos onle 215 files with 55MB. Cheers, Thomas -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExecSecureObjects action need very long time
I just added a false condition to my setAccessRights action so the action was skipped., but still the ExecSecureObjects action does took much longer with many files in my ProgramData folder. :-( How can I control ExecSecureObjects? Thanks, Thomas Von:thomas.deboben@rohde-schwarz.com An: General discussion about the WiX toolset. wix-users@lists.sourceforge.net, Datum: 06.07.2015 11:05 Betreff:Re: [WiX-users] ExecSecureObjects action need very long time Hi Rob, in the scenarion where the QA has reported this behaviour my setAccessRights action had a bug and did not do anything, so no ACLs where changed :-( But how is setAccessRightsinvolved and what will this action do? If I could find a way to set a condition for the setAccessRights action to false in the way I don't change ACLs a second time would this prevent ExecSecureObjects checking my folder? Thanks, Thomas Von:Rob Mensching r...@firegiant.com An: General discussion about the WiX toolset. wix-users@lists.sourceforge.net, Datum: 02.07.2015 11:36 Betreff:Re: [WiX-users] ExecSecureObjects action need very long time Yeah, okay then. Resetting the ACLs on lots and lots of files can take lots and lots of time. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: thomas.deboben@rohde-schwarz.com [ mailto:thomas.deboben@rohde-schwarz.com] Sent: Thursday, July 2, 2015 2:22 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] ExecSecureObjects action need very long time Hi Rob, on one system yes 1.3 million files so the installer run 40 min. After removing these files the installer performed fine again. On the other system where I added the trace infos onle 215 files with 55MB. Cheers, Thomas -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExecSecureObjects action need very long time
Hi Rob, on one system yes 1.3 million files so the installer run 40 min. After removing these files the installer performed fine again. On the other system where I added the trace infos onle 215 files with 55MB. Cheers, Thomas Von:Rob Mensching r...@firegiant.com An: General discussion about the WiX toolset. wix-users@lists.sourceforge.net, Datum: 02.07.2015 11:11 Betreff:Re: [WiX-users] ExecSecureObjects action need very long time Lots of files in the folder? _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: thomas.deboben@rohde-schwarz.com [ mailto:thomas.deboben@rohde-schwarz.com] Sent: Thursday, July 2, 2015 1:30 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] ExecSecureObjects action need very long time Hi, no one there who could give me a hint? Best regards, Thomas -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExecSecureObjects action need very long time
Hi, no one there who could give me a hint? Best regards, Thomas -Original Message- [WiX-users] ExecSecureObjects action need very long time From: Thomas.Deboben.ext@ro... - 2015-06-17 12:26:11 Hi all, I'm having a time problem with my installer. On some systems (not all) the installer need very long time on the Action ExecSecureObjects. From the trace I only see MSI (s) (0C:EC) [14:13:47:715]: Executing op: ActionStart(Name=ExecSecureObjects,,) MSI (s) (0C:EC) [14:13:47:715]: Executing op: CustomActionSchedule(Action=ExecSecureObjects,ActionType=3073,Source=BinaryData,Target=ExecSecureObjects,CustomActionData=C:\ProgramData\Rohde-Schwarz\Contest\CreateFolderEveryone268435456) MSI (s) (0C:60) [14:13:47:717]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI711C.tmp, Entrypoint: ExecSecureObjects MSI (s) (0C:EC) [14:21:31:914]: Executing op: ActionStart(Name=RegisterProduct,Description=Registering product,Template=[1]) My first thought was that my custon action where I set the user access rights for C:\ProgramData\Rohde-Schwarz\Contest to everyone but the lauch time for this action is under a minute As well I find the entry MSI (s) (0C!C0) [14:13:37:075]: Doing action: ExecSecureObjects Action start 14:13:37: ExecSecureObjects. Action ended 14:13:37: ExecSecureObjects. Return value 1. MSI (s) (0C:EC) [14:13:37:078]: Doing action: RegisterUser How can I figure out what is causing this delay? Best regards, Thomas -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn - InstallAnywhere ExePackage
Hi, I guess I have to go the same way for the PostgreSQL installer (made with bitrock). How do you have created the stub EXE? Is ther something within the WIX toolset or do I have to create a C# project? Best regards, Thomas Von:jhennessey jack.hennes...@hyland.com An: wix-users@lists.sourceforge.net Datum: 29.08.2012 07:32 Betreff:Re: [WiX-users] Burn - InstallAnywhere ExePackage UPDATE: OK, using the recommendation of creating a stub EXE I have got this working. Here's what I did in case anyone else needs to handle this type of installer. 1. Created a stub executable that manages the installation and removal of the package. The stub exe does a few things: a) Parses some command line parameters (to pass the install / uninstall). b) Launches the specified executable. c) Returns the exit code from the launched process (so burn knows if it failed or succeeded). 2. In order to determine if the actual package was installed, I used a burn file search (since I knew where the uninstall.exe file should be) and used that variable for the ExePackage/@DetectCondition. This way the package would be installed if the file wasn't found. 3. Added a Payload element for the real install package. In the end here is an example of what my WiX authoring looked like: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Fragment util:FileSearch Path=[ProgramFilesFolder]MyCompany\MyProduct\uninstall\uninstall.exe Variable=ThirdPartyUninstallExecutable/ PackageGroup Id=ThirdPartyProduct ExePackage Id=ExePackageStub_ThirdPartyProduct DisplayName=Third Party Product Description=Third Party Product PerMachine=yes SourceFile=C:\Visual Studio Projects\Bootstrapper1\ExePackageStub\ExePackageStub.exe DetectCondition=ThirdPartyUninstallExecutable InstallCommand='-ExeFile ThirdPartyInstall.exe -ExeCommandLine -i silent -DUSER_INSTALL_DIR=\[ProgramFilesFolder]MyCompany\MyProduct\ -DREGISTER_UNINSTALLER_WINDOWS=FALSE' UninstallCommand='-ExeFile [ThirdPartyUninstallExecutable] -ExeCommandLine -i silent' Payload SourceFile=C:\Visual Studio Projects\Bootstrapper1\ThirdParty\ThirdPartyInstall.exe / /ExePackage /PackageGroup /Fragment /Wix So, as you can see, I used the ExePackage/@InstallCommand and ExePackage/@UninstallCommand to pass my stub EXE the information I needed to run the install or uninstall. If you are installing an InstallAnywhere package the -DREGISTER_UNINSTALLER_WINDOWS=FALSE switch prevents it from adding an entry in ARP. Another tip, for the exe stub, if you are using the http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx CreateProcess function be sure that the first part of the command line is the full path to the executable you are launching. Hope this helps someone (and thanks for the initial suggestion)! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-InstallAnywhere-ExePackage-tp7580040p7580152.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. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Antwort: Re: ERROR1603
Hi, I've just posted the following comment to Rob's blog. -- Hi all, the first thing I do with an MSI log is to open with the Microsoft tool Windows Installer Verbose Log Analyzer (WiLogUtl.exe). One Problem is that WiLogUtl.exe support only MSI logs up to MSI version 3.0.0.0. So if I have a log file from a newer version I first change the version in the first line of the log file using notepad or any better editor. As example the first line is === Verbose logging started: 1/20/2012 8:58:55 Build type: SHIP UNICODE 3.01.4001.5512 Calling process: C:\WINDOWS\system32\msiexec.exe === so I change 3.01.4001.5512 to 3.0.0.0 and save the log file. Now WiLogUtl.exe will be able to handle the log file. Just open the log file an press the Analyze button. Now you get a Detailed Log File View dialog from where you could check states, properties etc. My prefered option is the HTML Log. Allow Blocked Content is required. Now you could use the buttons First Error, Last Error, Previous Error and Next Error to navigate. For better reading the lines are formated in different colors. When jumping to an error you have to scroll some lines up to find the reason of the error like Rob said in his blog. - Cheers, Thomas Von:James Green jgr...@mango-solutions.com An: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Datum: 25.01.2012 17:21 Betreff:Re: [WiX-users] ERROR1603 http://robmensching.com/blog/posts/2010/8/2/The-first-thing-I-do-with-an-MSI-log Thanks Rob, probably the most useful piece of info I've heard regarding MSI's. I knew about the logs but not value 3. Cheers, James LEGAL NOTICE This message is intended for the use of the named recipient(s) only and may contain confidential and / or privileged information. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised use of the information contained in this message is prohibited. Mango Business Solutions Limited is registered in England under No. 4560258 with its registered office at Suite 3, Middlesex House, Rutherford Close, Stevenage, Herts, SG1 2EF, UK. PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS EMAIL -- 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 https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Component GUID * - same for two different builds
Hi, I have a problem with an automatic generated GUID. We use Component Id=Component.RegistryHKLM Guid=* for our registry component. Now we build two different Versions on two different build systems but get the same GUID generated in both setups. :-( The problem is, that we can install both versions side by side. The registry key contain the version to seperate the values for both versions like RegistryValue Action=write Id=ContestInstallDir Key=SOFTWARE\ Company\Product\[VERSION] Name=InstallDir Root=HKLM Type=string Value=[INSTALLLOCATION]$(var.VERSION)\bin / But when I now uninstall one of these version the registry values will not be removed as the component with same name and GUID is referenced from the other version as well. What is the way the GUID will be generated or what can I do to get a different GUID generated for the different versions? Many thanks, Thomas -- 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
[WiX-users] ComboBox - display mismatch between value and text
Hi, I'm in trouble with a combobox in a custom installer dialog. ComboBox Property=TESTSYSTEM ListItem Value=CMW500 Text=CMW500 / ListItem Value=TS8950GW Text=TS8950GW / ListItem Value=TS8980FTA Text=TS8980FTA/NET / ListItem Value=TS8980IB Text=TS8980IB / ListItem Value=TS8980S Text=TS8980S / ListItem Value=TS8980S-TSRRM Text=TS8980S/TS-RRM / ListItem Value=TS-RRM Text=TS-RRM / /ComboBox If I open the combobox I get a list filled with the text strings and the property will be set to the value string when leaving the dialog by pressing the next button. Fine so far. What I now realized is a strange behaviour. If I select TS8980FTA/NET I see this as choosen text. But when pressing Next and Back again I see TS8980FTA in the combobox. Same when I set the TESTSYSTEM property to this value before. If I select the entry TS8980S/TS-RRM I get displayed TS8980S-TSRRM in the combobox and if I open the combobox list again TS8980S/TS-RRM is not marked as the seolected entry. Can someone explain to me what happen here and how I could fix it? I use wix 3.6.2221.0 at the moment. Chear and many thanks, Thomas -- 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
[WiX-users] Major Upgrade - Ask user if he would like to upgrade
Hi, after some discussions I've changed my mind and have implemented the code to support major upgrades. But when I now launch the second package to upgrade the first I get no hint that this will be an upgrade installation. How could I bring up a message or change the welcome dialog to ask the user if he would like to upgrade from the first package to the second? Cheers, Thomas -- 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
[WiX-users] Antwort: Re: util:RemoveFolderEx with condition?
Hi, I use a trick now and it works, but it's not the fine way, I think. In util:RemoveFolderEx On=uninstall Property=AppDataCommonFolder/ I have to place my property containing the full path to my folder. I have an action where I set this property. CustomAction Id=setAppDataCommonFolder Property= AppDataCommonFolder Value=[CommonAppDataFolder]Company\Product\Common\ Execute=immediate / Now I have a second action where I clean this property, or set a stupid value. ;-) CustomAction Id=cleanAppDataCommonFolderProperty= AppDataCommonFolder Value=Don't remove AppDataCommonFolder Execute= immediate / In the ExecuteSequence I launch the cleanAppDataCommonFolder based on a condition. The property REMOVECOMMONFILES will be set by the custom dialog with 1 if the checkbox is set. Custom Action=cleanAppDataCommonFolderBefore= WixRemoveFoldersExNOT REMOVECOMMONFILES=1/Custom So the property AppDataCommonFolder will only have a valid value if the checkbox in the dialog is checked. Cheers, Thomas -- 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
[WiX-users] util:RemoveFolderEx with condition?
Hi, I'm just working on a task where I have to cleanup a folder where the application will create files and folders during runtime. There for I've added a RemoveFolderEx element. util:RemoveFolderEx On= uninstall Property=AppDataCommonFolder/ This works fine so far, but for one folder the user should be able to set in a dialog if this folder should be deleted or not. For this I set a property based on a checkbox. Now I can't find a way how to set a condition based on my property to the RemoveFolderEx element. Is it possible or do I work into the wrong way? Cheers, Thomas -- 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] Changing registry key name for uninstall
Hi, I also would like to change the registry key under uninstall from the ProductID to the ProductName. We have a company wide tool to check for installed applications and it would be much easier to maintain when using the product name instead of the productcode. When I wrote msi setups for my old company we used InstallShield and here I got my installers registered over the product name. So I don't see a problem from msi side. Cheers, Thomas Von:Dario Griffo dariogri...@gmail.com An: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Datum: 06.08.2011 23:27 Betreff:Re: [WiX-users] Changing registry key name for uninstall Sorry, my bad, i want this change to be done during the installation process, so once my product is installed the registry name is not a guid, is a name On 2011-08-06 7:02 AM, avinashreddy539 avinashreddy...@gmail.com wrote: create a customaction which will execute at uninstalling process and change the registry key at uninstall process. You can a put a condition for that customaction like this *Installed AND NOT UPGRADINGPRODUCTCODE* -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Changing-registry-key-name-for-uninstall-tp6657882p6659292.html Sent from the wix-users mailing list archive at Nabble.com. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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 The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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
[WiX-users] What happend to minor upgrade using wix
Hi, I'm trying to get my installers to support minor upgrades. I will not change the productcode and also will not support major upgrades so I don't want to add an upgradecode which seams to break minor upgrades. But if I have installed version 1.0.0.1 with msiexec /i I neet to launch the version 1.0.0.2 with REINSTALL=ALL and REINSTALLMODE. :-( If I create a new release like 1.1.0.0 or 2.0.0.0 I will change the productcode but will not allow an upgrade from 1.0.*.* as these versions should be installed side by side. Creating setups with InstallShield in the past I was able to launch version 1.0.0.2 without these properties and the setup came up with a messagebox if I would like to upgrade. I feel confused. Is it now really needed to write a bootstrapper? If yes, is there an example somewhere? Cheers, Thomas -- 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
[WiX-users] Antwort: Re: What happend to minor upgrade using wix
Hi Mat, thanks for the hint with the tree version numbers. I will try by changing the third number. Just to clarify. I had used in InstallShield pure MSI packages. Cheers, Thomas Von:Skildum, Mathew mathew.skil...@aspect.com An: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Datum: 04.11.2011 15:28 Betreff:Re: [WiX-users] What happend to minor upgrade using wix The main problem I see here is your versioning scheme. MSI only supports the first three places in the version number (X.X.X) and ignores the fourth position. Any version changes need to take place in the first three positions for MSI to recognize a version change. For more information please refer to the MSI, and Microsoft, documentation on versions and use of versioning. You cannot compare what you do in legacy InstallShield (InstallScript) and MSI as they are two different install engines. InstallScript based installs use all four places in the version when it does version compares. When moving from InstallScript to MSI (WIX), or any install engine for that matter, you must be aware of the behavior differences and adjust your development rules accordingly. Mat Skildum -- 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] Std Bootstrapper failed: Error 0x800b010a
a new WiX-user and just try to build a bootstrapper to customize
a
PostgreSQL installation.
I use WIX 3.6.1915.0 in VS2010.
I've added two ExePackages into a chain (64bit and 32bit package).
Later I will pass additional parameters to these packages given from
custom dialogs.
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Bundle Name=PostgreSQL_Bootstrapper
Manufacturer=Thomas Deboben
UpgradeCode=5ba5b32d-01d0-49b5-a683-1f24e09216af
Version=1.0.0.0
BootstrapperApplicationRef Id=
WixStandardBootstrapperApplication.RtfLicense /
WixVariable Id=WixStdbaLicenseRtf Value=lic\license.rtf /
WixVariable Id=WixStdbaLogo Value=img\logo.bmp /
Chain
!-- TODO: Define the list of chained packages. --
ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows_x64.exe
InstallCommand=--mode unattended --datadir
C:\PGData
InstallCondition=VersionNT64 = v5.1
/
ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows.exe
InstallCommand=--mode unattended --datadir
C:\PGData
InstallCondition=NOT VersionNT64 AND VersionNT =
v5.0
/
!-- Note: The following PackageGroupRef is required to pull in
generated authoring from project references. --
PackageGroupRef Id=Bundle.Generated.Packages/
/Chain
/Bundle
/Wix
The build succeeded with one warning (Warning 1 Unable to
reset
acls on destination files. light.exe 0 1
Bootstrapper1).
When I launch the Bootstrapper executable I get the Error 0x800b010a
when
the nested installer should be executed.
What have I done wrong?
Thanks in advance,
Thomas
Here is the full log:
[01B4:05BC][2011-07-21T09:23:22.373+01:00]: Burn v3.6.1915.0, path:
Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe, cmdline:
''
[01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable
'BundleTag' to value ''
[01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable
'WixBundleName' to value 'PostgreSQL_Bootstrapper'
[01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable
'WixBundleLog' to value
'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322.log'
[01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable
'WixBundleOriginalSource' to value
'Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe'
[01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect 2 packages
[01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package:
postgresql_9.0.4_1_windows_x64.exe, state: Absent, cached: No
[01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package:
postgresql_9.0.4_1_windows.exe, state: Absent, cached: No
[01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect complete, result:
0x0
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Plan 2 packages, action:
Install
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Condition 'VersionNT64
AND
VersionNT = v5.0' evaluates to false.
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Planned package:
postgresql_9.0.4_1_windows_x64.exe, state: Absent, default
requested:
Absent, ux requested: Absent, execute: None, rollback: None, cache:
No,
uncache: No, dependency: Unregister
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Condition 'NOT
VersionNT64
AND
VersionNT = v5.0' evaluates to true.
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Setting string variable
'WixBundleLog_postgresql_9.0.4_1_windows.exe' to value
'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322_0_postgresql_9.0.4_1_windows.exe.log'
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Setting string variable
'WixBundleRollbackLog_postgresql_9.0.4_1_windows.exe' to value
'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322_0_postgresql_9.0.4_1_windows.exe_rollback.log'
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Planned package:
postgresql_9.0.4_1_windows.exe, state: Absent, default requested:
Present,
ux requested: Present, execute: Install, rollback: Uninstall, cache:
Yes,
uncache: No, dependency: Register
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Plan complete, result:
0x0
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Apply begin
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Caching executable from:
'Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe' to:
'C:\Documents and Settings\Administrator\Local Settings\Application
Data\Package
Cache\{3a1f9531-496d-4e2d-9f2d-04e6296ccb74}\PostgreSQL_Bootstrapper.exe'
[01B4:05BC][2011-07-21T09:23:25.701+01:00]: Registering bundle
dependency
key: {3a1f9531-496d-4e2d-9f2d-04e6296ccb74}, version 1.0.0.0
[01B4:0478][2011-07-21T09:23:57.514+01:00]: Error 0x800b010a: Failed
authenticode verification of payload:
C:\DOCUME~1\ADMINI~1
[WiX-users] Antwort: Re: Std Bootstrapper failed: Error 0x800b010a
(signature is valid and trusted). Is there a way to launch it on a system without internet connection? Thanks, Thomas Rob Mensching r...@robmensching.com 21.07.2011 17:18 Bitte antworten an General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net An General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Kopie Thema Re: [WiX-users] Std Bootstrapper failed: Error 0x800b010a 0x800B010A == A certificate chain could not be built to a trusted root authority. Is the exe signed? Is the signature valid and trusted on the machine? On Thu, Jul 21, 2011 at 2:48 AM, thomas.debo...@rohde-schwarz.com wrote: Hello, I'm a new WiX-user and just try to build a bootstrapper to customize a PostgreSQL installation. I use WIX 3.6.1915.0 in VS2010. I've added two ExePackages into a chain (64bit and 32bit package). Later I will pass additional parameters to these packages given from custom dialogs. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Bundle Name=PostgreSQL_Bootstrapper Manufacturer=Thomas Deboben UpgradeCode=5ba5b32d-01d0-49b5-a683-1f24e09216af Version=1.0.0.0 BootstrapperApplicationRef Id= WixStandardBootstrapperApplication.RtfLicense / WixVariable Id=WixStdbaLicenseRtf Value=lic\license.rtf / WixVariable Id=WixStdbaLogo Value=img\logo.bmp / Chain !-- TODO: Define the list of chained packages. -- ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows_x64.exe InstallCommand=--mode unattended --datadir C:\PGData InstallCondition=VersionNT64 = v5.1 / ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows.exe InstallCommand=--mode unattended --datadir C:\PGData InstallCondition=NOT VersionNT64 AND VersionNT = v5.0 / !-- Note: The following PackageGroupRef is required to pull in generated authoring from project references. -- PackageGroupRef Id=Bundle.Generated.Packages/ /Chain /Bundle /Wix The build succeeded with one warning (Warning 1 Unable to reset acls on destination files. light.exe 0 1 Bootstrapper1). When I launch the Bootstrapper executable I get the Error 0x800b010a when the nested installer should be executed. What have I done wrong? Thanks in advance, Thomas Here is the full log: [01B4:05BC][2011-07-21T09:23:22.373+01:00]: Burn v3.6.1915.0, path: Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe, cmdline: '' [01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable 'BundleTag' to value '' [01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable 'WixBundleName' to value 'PostgreSQL_Bootstrapper' [01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable 'WixBundleLog' to value 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322.log' [01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable 'WixBundleOriginalSource' to value 'Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe' [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect 2 packages [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package: postgresql_9.0.4_1_windows_x64.exe, state: Absent, cached: No [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package: postgresql_9.0.4_1_windows.exe, state: Absent, cached: No [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect complete, result: 0x0 [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Plan 2 packages, action: Install [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Condition 'VersionNT64 AND VersionNT = v5.0' evaluates to false. [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Planned package: postgresql_9.0.4_1_windows_x64.exe, state: Absent, default requested: Absent, ux requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: Unregister [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Condition 'NOT VersionNT64 AND VersionNT = v5.0' evaluates to true. [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Setting string variable 'WixBundleLog_postgresql_9.0.4_1_windows.exe' to value 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322_0_postgresql_9.0.4_1_windows.exe.log' [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Setting string variable 'WixBundleRollbackLog_postgresql_9.0.4_1_windows.exe' to value 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322_0_postgresql_9.0.4_1_windows.exe_rollback.log' [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Planned package: postgresql_9.0.4_1_windows.exe, state: Absent, default requested: Present, ux requested: Present, execute: Install, rollback: Uninstall
Re: [WiX-users] Std Bootstrapper failed: Error 0x800b010a
Hi Rob, yes, the exe is signed, but I run the bootstrapper on a VMWare image without a connection to the internet :-( I have run it now on my host system and the bootstrapper was able to launch the chained installer (signature is valid and trusted). Is there a way to launch it on a system without internet connection? Thanks, Thomas Rob Mensching r...@robmensching.com 21.07.2011 17:18 Bitte antworten an General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net An General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Kopie Thema Re: [WiX-users] Std Bootstrapper failed: Error 0x800b010a 0x800B010A == A certificate chain could not be built to a trusted root authority. Is the exe signed? Is the signature valid and trusted on the machine? On Thu, Jul 21, 2011 at 2:48 AM, thomas.debo...@rohde-schwarz.com wrote: Hello, I'm a new WiX-user and just try to build a bootstrapper to customize a PostgreSQL installation. I use WIX 3.6.1915.0 in VS2010. I've added two ExePackages into a chain (64bit and 32bit package). Later I will pass additional parameters to these packages given from custom dialogs. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Bundle Name=PostgreSQL_Bootstrapper Manufacturer=Thomas Deboben UpgradeCode=5ba5b32d-01d0-49b5-a683-1f24e09216af Version=1.0.0.0 BootstrapperApplicationRef Id= WixStandardBootstrapperApplication.RtfLicense / WixVariable Id=WixStdbaLicenseRtf Value=lic\license.rtf / WixVariable Id=WixStdbaLogo Value=img\logo.bmp / Chain !-- TODO: Define the list of chained packages. -- ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows_x64.exe InstallCommand=--mode unattended --datadir C:\PGData InstallCondition=VersionNT64 = v5.1 / ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows.exe InstallCommand=--mode unattended --datadir C:\PGData InstallCondition=NOT VersionNT64 AND VersionNT = v5.0 / !-- Note: The following PackageGroupRef is required to pull in generated authoring from project references. -- PackageGroupRef Id=Bundle.Generated.Packages/ /Chain /Bundle /Wix The build succeeded with one warning (Warning 1 Unable to reset acls on destination files. light.exe 0 1 Bootstrapper1). When I launch the Bootstrapper executable I get the Error 0x800b010a when the nested installer should be executed. What have I done wrong? Thanks in advance, Thomas Here is the full log: [01B4:05BC][2011-07-21T09:23:22.373+01:00]: Burn v3.6.1915.0, path: Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe, cmdline: '' [01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable 'BundleTag' to value '' [01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable 'WixBundleName' to value 'PostgreSQL_Bootstrapper' [01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable 'WixBundleLog' to value 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322.log' [01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable 'WixBundleOriginalSource' to value 'Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe' [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect 2 packages [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package: postgresql_9.0.4_1_windows_x64.exe, state: Absent, cached: No [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package: postgresql_9.0.4_1_windows.exe, state: Absent, cached: No [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect complete, result: 0x0 [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Plan 2 packages, action: Install [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Condition 'VersionNT64 AND VersionNT = v5.0' evaluates to false. [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Planned package: postgresql_9.0.4_1_windows_x64.exe, state: Absent, default requested: Absent, ux requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: Unregister [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Condition 'NOT VersionNT64 AND VersionNT = v5.0' evaluates to true. [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Setting string variable 'WixBundleLog_postgresql_9.0.4_1_windows.exe' to value 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322_0_postgresql_9.0.4_1_windows.exe.log' [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Setting string variable 'WixBundleRollbackLog_postgresql_9.0.4_1_windows.exe' to value 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322_0_postgresql_9.0.4_1_windows.exe_rollback.log' [01B4:05BC][2011-07-21T09:23:24.295+01:00]: Planned package: postgresql_9.0.4_1_windows.exe, state: Absent, default requested: Present, ux requested: Present
Re: [WiX-users] Std Bootstrapper failed: Error 0x800b010a
Hi Tobias, thanks for your hints. But the real problem is not VMWare. Our real target system will be restricted testsystem without internet connection. So I really need a way to launch the bootstrapper on a system without internet connection. Cheers, Thomas Tobias S tobias.s1...@gmail.com 22.07.2011 11:40 Bitte antworten an General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net An General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Kopie Thema Re: [WiX-users] Std Bootstrapper failed: Error 0x800b010a VMWares seem to be somehow tricky regarding retrieving the revocation lists to verify the signatures. If your company policies allow does it work if you connect the VM directly to the internet ? Did you try different settings for Network Adapter like Host-only + Connect at power on disabled ? Ipconfig /release on console ? Just some thoughts... Did you try to sign the exe with a test certificate and deploy these testing certificates to that VM ? Sorry I'm not so common with such certificates but in my understanding this should make the testing certificate valid on that VM. Regards Tobias 2011/7/22 thomas.debo...@rohde-schwarz.com: Hi Rob, yes, the exe is signed, but I run the bootstrapper on a VMWare image without a connection to the internet :-( I have run it now on my host system and the bootstrapper was able to launch the chained installer (signature is valid and trusted). Is there a way to launch it on a system without internet connection? Thanks, Thomas Rob Mensching r...@robmensching.com 21.07.2011 17:18 Bitte antworten an General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net An General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Kopie Thema Re: [WiX-users] Std Bootstrapper failed: Error 0x800b010a 0x800B010A == A certificate chain could not be built to a trusted root authority. Is the exe signed? Is the signature valid and trusted on the machine? On Thu, Jul 21, 2011 at 2:48 AM, thomas.debo...@rohde-schwarz.com wrote: Hello, I'm a new WiX-user and just try to build a bootstrapper to customize a PostgreSQL installation. I use WIX 3.6.1915.0 in VS2010. I've added two ExePackages into a chain (64bit and 32bit package). Later I will pass additional parameters to these packages given from custom dialogs. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Bundle Name=PostgreSQL_Bootstrapper Manufacturer=Thomas Deboben UpgradeCode=5ba5b32d-01d0-49b5-a683-1f24e09216af Version=1.0.0.0 BootstrapperApplicationRef Id= WixStandardBootstrapperApplication.RtfLicense / WixVariable Id=WixStdbaLicenseRtf Value=lic\license.rtf / WixVariable Id=WixStdbaLogo Value=img\logo.bmp / Chain !-- TODO: Define the list of chained packages. -- ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows_x64.exe InstallCommand=--mode unattended --datadir C:\PGData InstallCondition=VersionNT64 = v5.1 / ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows.exe InstallCommand=--mode unattended --datadir C:\PGData InstallCondition=NOT VersionNT64 AND VersionNT = v5.0 / !-- Note: The following PackageGroupRef is required to pull in generated authoring from project references. -- PackageGroupRef Id=Bundle.Generated.Packages/ /Chain /Bundle /Wix The build succeeded with one warning (Warning 1 Unable to reset acls on destination files. light.exe 0 1 Bootstrapper1). When I launch the Bootstrapper executable I get the Error 0x800b010a when the nested installer should be executed. What have I done wrong? Thanks in advance, Thomas Here is the full log: [01B4:05BC][2011-07-21T09:23:22.373+01:00]: Burn v3.6.1915.0, path: Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe, cmdline: '' [01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable 'BundleTag' to value '' [01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable 'WixBundleName' to value 'PostgreSQL_Bootstrapper' [01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable 'WixBundleLog' to value 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322.log' [01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable 'WixBundleOriginalSource' to value 'Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe' [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect 2 packages [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package: postgresql_9.0.4_1_windows_x64.exe, state: Absent, cached: No [01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package: postgresql_9.0.4_1_windows.exe, state: Absent, cached: No [01B4:05BC][2011-07-21T09:23
[WiX-users] Std Bootstrapper failed: Error 0x800b010a
Hello,
I'm a new WiX-user and just try to build a bootstrapper to customize a
PostgreSQL installation.
I use WIX 3.6.1915.0 in VS2010.
I've added two ExePackages into a chain (64bit and 32bit package).
Later I will pass additional parameters to these packages given from
custom dialogs.
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Bundle Name=PostgreSQL_Bootstrapper
Manufacturer=Thomas Deboben
UpgradeCode=5ba5b32d-01d0-49b5-a683-1f24e09216af
Version=1.0.0.0
BootstrapperApplicationRef Id=
WixStandardBootstrapperApplication.RtfLicense /
WixVariable Id=WixStdbaLicenseRtf Value=lic\license.rtf /
WixVariable Id=WixStdbaLogo Value=img\logo.bmp /
Chain
!-- TODO: Define the list of chained packages. --
ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows_x64.exe
InstallCommand=--mode unattended --datadir C:\PGData
InstallCondition=VersionNT64 = v5.1
/
ExePackage SourceFile=pkg\postgresql-9.0.4-1-windows.exe
InstallCommand=--mode unattended --datadir C:\PGData
InstallCondition=NOT VersionNT64 AND VersionNT = v5.0
/
!-- Note: The following PackageGroupRef is required to pull in
generated authoring from project references. --
PackageGroupRef Id=Bundle.Generated.Packages/
/Chain
/Bundle
/Wix
The build succeeded with one warning (Warning 1 Unable to reset
acls on destination files. light.exe 0 1 Bootstrapper1).
When I launch the Bootstrapper executable I get the Error 0x800b010a when
the nested installer should be executed.
What have I done wrong?
Thanks in advance,
Thomas
Here is the full log:
[01B4:05BC][2011-07-21T09:23:22.373+01:00]: Burn v3.6.1915.0, path:
Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe, cmdline: ''
[01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable
'BundleTag' to value ''
[01B4:05BC][2011-07-21T09:23:22.389+01:00]: Setting string variable
'WixBundleName' to value 'PostgreSQL_Bootstrapper'
[01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable
'WixBundleLog' to value
'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322.log'
[01B4:05BC][2011-07-21T09:23:22.404+01:00]: Setting string variable
'WixBundleOriginalSource' to value
'Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe'
[01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect 2 packages
[01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package:
postgresql_9.0.4_1_windows_x64.exe, state: Absent, cached: No
[01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detected package:
postgresql_9.0.4_1_windows.exe, state: Absent, cached: No
[01B4:05BC][2011-07-21T09:23:22.451+01:00]: Detect complete, result: 0x0
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Plan 2 packages, action:
Install
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Condition 'VersionNT64 AND
VersionNT = v5.0' evaluates to false.
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Planned package:
postgresql_9.0.4_1_windows_x64.exe, state: Absent, default requested:
Absent, ux requested: Absent, execute: None, rollback: None, cache: No,
uncache: No, dependency: Unregister
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Condition 'NOT VersionNT64 AND
VersionNT = v5.0' evaluates to true.
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Setting string variable
'WixBundleLog_postgresql_9.0.4_1_windows.exe' to value
'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322_0_postgresql_9.0.4_1_windows.exe.log'
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Setting string variable
'WixBundleRollbackLog_postgresql_9.0.4_1_windows.exe' to value
'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PostgreSQL_Bootstrapper_20110721092322_0_postgresql_9.0.4_1_windows.exe_rollback.log'
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Planned package:
postgresql_9.0.4_1_windows.exe, state: Absent, default requested: Present,
ux requested: Present, execute: Install, rollback: Uninstall, cache: Yes,
uncache: No, dependency: Register
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Plan complete, result: 0x0
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Apply begin
[01B4:05BC][2011-07-21T09:23:24.295+01:00]: Caching executable from:
'Z:\ddrive\Transfer\PostgreSQL\PostgreSQL_Bootstrapper2.exe' to:
'C:\Documents and Settings\Administrator\Local Settings\Application
Data\Package
Cache\{3a1f9531-496d-4e2d-9f2d-04e6296ccb74}\PostgreSQL_Bootstrapper.exe'
[01B4:05BC][2011-07-21T09:23:25.701+01:00]: Registering bundle dependency
key: {3a1f9531-496d-4e2d-9f2d-04e6296ccb74}, version 1.0.0.0
[01B4:0478][2011-07-21T09:23:57.514+01:00]: Error 0x800b010a: Failed
authenticode verification of payload:
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\postgresql_9.0.4_1_windows.exe
[01B4:0478][2011-07-21T09:23:57.514+01:00]: Error 0x800b010a: Failed to
verify payload signature: C:\Documents and Settings
