Re: [WiX-users] Bundle registered in ARP after prerequesitesare installed
Thank you for your reply. I know, that it can be that simple to use the WixNetFxExtension. Unfortunately I need to also install on machines that have no internet access and so I can't use it. That's why I copied some part from the WixNetFxExtension and adjusted it to use the .Net exe I put on the disk. Nonetheless I tried your approach. The result is the same: If I install .Net an ARP entry for my bundle is created and if I cancel the custom bootstrapper and start it again, it comes up in maintenance mode because WixBundleInstalled is 1. I even tried with the WiX v3.7 setup itself and it showed the same behavior. -Ursprüngliche Nachricht- Von: Pally Sandher [mailto:pally.sand...@iesve.com] Gesendet: Dienstag, 12. Februar 2013 17:01 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Bundle registered in ARP after prerequesitesare installed http://wix.sourceforge.net/manual-wix3/install_dotnet.htm Chain PackageGroupRef Id=NetFx40ClientRedist/ ...your msi stuff goes here... /Chain End. Yes it's that simple using WiXNetFXExtension. All the extra code you have is just duplicating effort causing you problems. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Ogrodowski, Sabine (ehem. Frauenhoffer) [mailto:sabine.ogrodow...@haufe-lexware.com] Sent: 12 February 2013 15:13 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Bundle registered in ARP after prerequesites are installed When we install our bundle on a machine that has no .Net 4 installed, it gets installed by the prerequisites installer. Afterwards our custom bootstrapper starts up, and the wix variable WixBundleInstalled is 0, which is correct. Unfortunately at this point there already exists an entry for our bootstrapper in ARP. So when we cancel installation and restart our bootstrapper, WixBundleInstalled returns 1 and we start in maintenance mode, although our bundle isn't installed. Here is what I use to install .net 4: Fragment util:RegistrySearchRef Id=NETFRAMEWORK40CLIENT/ ?define NetFx40EulaLink = http://go.microsoft.com/fwlink/?LinkID=188993 ? WixVariable Id=WixMbaPrereqPackageId Value=NetFx40Client / WixVariable Id=WixMbaPrereqLicenseUrl Value=$(var.NetFx40EulaLink) / PackageGroup Id=NetFx40Client ExePackage InstallCommand=/q /norestart /ChainingPackage quot;[WixBundleName]quot; RepairCommand=/q /norestart /repair /ChainingPackage quot;[WixBundleName]quot; UninstallCommand=/uninstall /q /norestart /ChainingPackage quot;[WixBundleName]quot; PerMachine=yes DetectCondition=NETFRAMEWORK40CLIENT Id=NetFx40Client Vital=yes Permanent=yes Protocol=netfx4 Compressed=no Cache=no SourceFile=..\dotnet_4_0\dotNetFx40_Client_x86_x64.exe Name=data\dotnet\dotNetFx40_Client_x86_x64.exe /ExePackage /PackageGroup /Fragment What would I have to change to get this scenario to work? -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle registered in ARP after prerequesitesare installed
On 13/02/2013 08:01, Ogrodowski, Sabine (ehem. Frauenhoffer) wrote: Thank you for your reply. I know, that it can be that simple to use the WixNetFxExtension. Unfortunately I need to also install on machines that have no internet access and so I can't use it. That's why I copied some part from the WixNetFxExtension and adjusted it to use the .Net exe I put on the disk. Nonetheless I tried your approach. The result is the same: If I install .Net an ARP entry for my bundle is created and if I cancel the custom bootstrapper and start it again, it comes up in maintenance mode because WixBundleInstalled is 1. I even tried with the WiX v3.7 setup itself and it showed the same behavior. I'm fairly sure this is a known bug, with a ticket on Sourceforge. I found a similar issue today: if I run 2 copies of the installer, the second as the first is in the process of installing, the 2nd will fail and cause no ARP entry to be created once the first finishes. -- Bruce -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle registered in ARP afterprerequesitesare installed
I found this bug on this topic, but it is marked as closed, so I thought it should work... http://sourceforge.net/p/wix/bugs/2635/ -Ursprüngliche Nachricht- Von: Bruce Cran [mailto:br...@cran.org.uk] Gesendet: Mittwoch, 13. Februar 2013 10:15 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Bundle registered in ARP afterprerequesitesare installed On 13/02/2013 08:01, Ogrodowski, Sabine (ehem. Frauenhoffer) wrote: Thank you for your reply. I know, that it can be that simple to use the WixNetFxExtension. Unfortunately I need to also install on machines that have no internet access and so I can't use it. That's why I copied some part from the WixNetFxExtension and adjusted it to use the .Net exe I put on the disk. Nonetheless I tried your approach. The result is the same: If I install .Net an ARP entry for my bundle is created and if I cancel the custom bootstrapper and start it again, it comes up in maintenance mode because WixBundleInstalled is 1. I even tried with the WiX v3.7 setup itself and it showed the same behavior. I'm fairly sure this is a known bug, with a ticket on Sourceforge. I found a similar issue today: if I run 2 copies of the installer, the second as the first is in the process of installing, the 2nd will fail and cause no ARP entry to be created once the first finishes. -- Bruce -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fragments and Binary elements...
Your last approach is correct. In general, you: Place resources in a fragment in a separate file. Add the file to the project. Reference resources from your main wxs file (or any wxs file that it already references) using an xxxRef. When candle runs, it compiles the wxs file into a wixobj because it is in the project. When light runs, it will see the ref to the fragment and pull in the relevant wixobj created by candle. FragmentRefs are deprecated - just reference the fragment contents. It sounds like you're doing it right. You might have made a mistake somewhere. Try it with a minimal project if necessary to see how it works. -Original Message- From: Tristen Fielding [mailto:tfield...@tradestation.com] Sent: 12 February 2013 22:55 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Fragments and Binary elements... We have a very large wix project and we would like to break it apart. One of the things we would like to do is move several of our Binary element to a fragment but we can't seem to figure out how to make it work. We have something like define in the master.wxs file: Binary Id=WixUI_Bmp_Dialog SourceFile=$(var.MEDIAPATH)\side_panel.bmp / Binary Id=WixUI_Bmp_Banner SourceFile=$(var.MEDIAPATH)\WizardHeader.bmp / Binary Id=WixUI_Bmp_BannerJpn SourceFile=$(var.MEDIAPATH)\WizardHeaderJpn.bmp / Binary Id=WixUI_Bmp_Footer SourceFile=$(var.MEDIAPATH)\WizardFooter.bmp / Binary Id=FirstProgressBMP SourceFile=$(var.MEDIAPATH)\1_awards12_A.bmp / Binary Id=SecondProgressBMP SourceFile=$(var.MEDIAPATH)\2_awards12_B.bmp / Binary Id=ThirdProgressBMP SourceFile=$(var.MEDIAPATH)\3_awards12_C.bmp / Binary Id=FourthProgressBMP SourceFile=$(var.MEDIAPATH)\4_awards12_D.bmp / So we tried simply to move these definition into a new file and wrapped them with a Fragment element. When we built the project the project didn't complain but the binaries weren't in the binaries table. So, we then tried to reference these elements using BinaryRef and FragmentRef but we got error instead. What is the right way to reference these Binary elements in the master.wxs file? Thanks. Tristen Fielding Sr. Software Developer / Program Lead TradeStation Group, Inc. http://www.TradeStation.comhttp://www.tradestation.com/ 8050 SW 10th Street, Suite 2000 Plantation, FL 33324 Tel. 954.652.7320 Fax 954.652.5320 TradeStation Group, Inc. is the parent company of four operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), IBFX, Inc. (Member NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Forex products and services are offered by TradeStation Forex, a division of IBFX, Inc. - - Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat.exe
That, or add the generated wxs file to your project in visual studio. -Original Message- From: Yawar Khan [mailto:yawar.k...@live.com] Sent: 13 February 2013 07:14 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Heat.exe SET WIX=toolset-directory SET WORKING=working-directory *To harvest* %WIX%/bin/heat.exe dir %WORKING%\..\exe\plugin -cg pluginFiles -gg -scom -sreg -sfrag -srd -dr INSTALLLOCATION -var var.PluginProjectDir -out ..\Fragments\pluginFilesFragment.wxs [You may use/skip -sreg, -sfrag, -dr, -var according to your need] *Candle it* %WIX%/bin/candle.exe -dPluginProjectDir=%WORKING%\..\exe\plugin ..\Fragments\pluginFilesFragment.wxs *In setup.wxs add* Feature Id=PluginFeature Title=MySetup Level=1 ComponentGroupRef Id=pluginFiles / /Feature *Light it to build msi* %WIX%/bin/light.exe -o ..\wix-setups\setup setup.wixobj pluginFilesFragment.wixobj -ext WixUtilExtension -ext WixUIExtension -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-exe-tp7583 483p7583536.html Sent from the wix-users mailing list archive at Nabble.com. - - Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Detect Complete- freezed
Hi, Some times uninstallation works, but second setup installation does not started without uninstall first setup or restart. Could you provide any solution for this? Thanks, Kannan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Detect-Complete-freezed-tp7583517p7583546.html Sent from the wix-users mailing list archive at Nabble.com. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching with multiple instances
Hi, I'm having issues trying to get a patch built with WiX (using the Patch Creation Properties method) to apply to an MSI (also built with WiX) that has been multi instance transformed. I've logged my efforts to get it working on StackOverflow: http://stackoverflow.com/questions/14814014/msi-multi-instance-installation-with-patches Whenever I try and install the patch the Windows Installer immediately fails with The upgrade patch cannot be installed by the Windows Installer service because the program to upgraded may be missing, or the upgrade patch may update a different version of the program. - so I'm assuming I need to do something to the patch to make it work with the product code my instance is setup with. I thought I'd only need to set AllowProductCodeMismatches=yes on the PatchCreation element, but that doesn't seem to have made the patch installable - it will still install against a none-multi instance install though. Is there anything else I need to do? I've tried suggestions to modify the patch after build so that includes the new product code, but that doesn't seem to fix the issue either. Thanks, Gareth Oakley gareth.oak...@appsense.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Prerequisites (.NET Framework)
Thanks for this good explanations! Regarding this: You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. How do I specify that? //Sam On Tue, Feb 12, 2013 at 6:04 PM, Pally Sandher pally.sand...@iesve.comwrote: For MSI UI - http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm see the DisplayInternalUI attribute. To list your MSI in Programs Features and not the Burn bundle - http://wix.sourceforge.net/manual-wix3/wix_xsd_bundle.htm see the DisableModify and DisableRemove attributes. Also you will need to set the Visible attribute to yes on your MsiPackage element . You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: 12 February 2013 16:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Prerequisites (.NET Framework) Ok, but I have this issue, or maybe its just the way it works... I have set the Msi project to use: UIRef Id=WixUI_InstallDir/ And then I have added the license agreement rtf-file to it. But when I have added this to the Bootstrapper project: *BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense /* Chain PackageGroupRef Id= Netfx4Full/ ...your msi stuff goes here... /Chain I end up in not getting the Msi UI at all, and in Controlpanel - Programs I just see my bootstrapper projectname... Not the original Msi name and version... I thought that the Bootstrapper just would do its checks, and then handover to the Msi UI, and not display any thing to the user if all is Okay (.NET version are the right.). Thanks! //Sam On Tue, Feb 12, 2013 at 3:37 PM, Pally Sandher pally.sand...@iesve.com wrote: You need 2 projects. You have 2 outputs, an MSI a Burn executable which wraps the MSI and deals with your pre-reqs. You can configure your burn package not to register itself or to not register your MSI. See the Burn documentation - http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm BTW all that extra code Steven posted is completely superfluous. All you literally need in your Burn bundle XML is Chain PackageGroupRef Id= Netfx4Full/ ...your msi stuff goes here... /Chain As WiXNetFxExtension has all the authoring required to do all the checks downloading etc. (and has been checked tested by everyone who uses it on a daily basis). Personally I use PackageGroupRef Id=NetFx40ClientRedist/ because I hate those 'on-demand' installer bundle things. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: 12 February 2013 14:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Prerequisites (.NET Framework) Thanks Steven, I try to get it to work. Also a question regarding, how to arrange things. I have two projects, one that gives me a MSI as output, Its just plain msi-file, no check for .NET framework. The other is a Bootstrapper Project, it hava a reference to the MSI-project. Is this the best way to do it? Or can I keep it in one project? How? Otherwise I seems to end up with two products / versions, one inner and one outer? Br, Sam On Tue, Feb 12, 2013 at 3:10 PM, Steven Ogilvie steven.ogil...@titus.com wrote: You can have a copy of .NET with your package OR use the DownloadUrl= element within the exepackage so if required, the .NET install is downloaded THEN installed... Steve -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: February-12-13 9:03 AM To: General discussion for Windows Installer XML toolset.
Re: [WiX-users] questions on bootstrapper
Burn only fails back to the MBA prerequisite BA if it can't create the
AppDomain it needs. Look at BootstrapperApplicationCreate in
src\ext\BalExtension\mba\host\host.cpp.
Introducing additional dependencies for a BA seems wrong to me. If you are
using this custom dependency to modify machine state, you could accomplish this
by adding the dependency earlier in the chain and having a later MsiPackage
that could use custom actions to interact with the newly installed dependency.
-Original Message-
From: Nan Zang [mailto:naz...@microsoft.com]
Sent: Wednesday, February 13, 2013 1:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] questions on bootstrapper
After some investigation, it seemsdefine Id=WixMbaPrereqPackageId will
accomplish what I need, however, I cannot get it work.
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
xmlns:bal=http://schemas.microsoft.com/wix/BalExtension;
Bundle Name=My Test Application Version=1.0.0.0 Manufacturer=Microsoft
UpgradeCode=C82A383C-751A-43B8-90BF-A250F7BC2863
BootstrapperApplicationRef Id=ManagedBootstrapperApplicationHost
Payload SourceFile=..\TestBA\BootstrapperCore.config/
Payload SourceFile=..\TestBA\bin\Release\TestBA.dll/
Payload SourceFile=C:\Program Files (x86)\WiX Toolset
v3.6\SDK\Microsoft.Deployment.WindowsInstaller.dll/
/BootstrapperApplicationRef
Chain
PackageGroupRef Id='OrgIdSignInAssistant' /
MsiPackage SourceFile=..\DummyInstaller\bin\debug\DummyInstaller.msi
Id=DummyInstallernPackageId Cache=yes Visible=no/
/Chain
/Bundle
Fragment
WixVariable Id=WixMbaPrereqPackageId Value=OrgIdSignInAssistant /
WixVariable Id=WixMbaPrereqLicenseUrl Value=Eula.rtf /
PackageGroup Id=OrgIdSignInAssistant
MsiPackage Id=OrgIdSignInAssistant Cache=no Compressed=yes
Permanent=yes Vital=yes
SourceFile=E:\rmsonline\private\externals\IDCRL\7.250.4303.0\MSI\msoidcrl.msi
/
/PackageGroup
/Fragment
/Wix
This is the log, this is modfied from the sample code. There is no prerequisite
step gets invoked, Anything wrong here?
[1F40:1700][2013-02-12T23:07:48]: Burn v3.6.3303.0, Windows v6.1 (Build 7601:
Service Pack 1), path:
C:\Users\nazang\Desktop\RMSSetupBA\BootstrapperSetup\bin\Debug\BootstrapperSetup.exe,
cmdline: '/install /log setup.log /runas:administrator -burn.unelevated
BurnPipe.{F434AAE5-B80D-43FF-8859-670E1B3D483E}
{E175F3B6-186C-445D-A861-3BDC024177A4} 12900'
[1F40:1700][2013-02-12T23:07:48]: Setting string variable 'WixBundleLog' to
value 'e:\wix\Dev\wix37\setup.log'
[1F40:1700][2013-02-12T23:07:48]: Setting string variable
'WixBundleOriginalSource' to value
'C:\Users\nazang\Desktop\RMSSetupBA\BootstrapperSetup\bin\Debug\BootstrapperSetup.exe'
[1F40:1700][2013-02-12T23:07:48]: Setting string variable 'WixBundleName' to
value 'My Test Application'
[1F40:1700][2013-02-12T23:07:48]: Loading managed bootstrapper application.
[1F40:1700][2013-02-12T23:07:49]: Creating BA thread to run asynchronously.
[1F40:3B48][2013-02-12T23:07:49]: Launching custom TestBA UX
[1F40:1700][2013-02-12T23:07:49]: Detect 2 packages
[1F40:1700][2013-02-12T23:07:49]: Detected related bundle:
{4d72440b-3501-4b0c-9ee3-2fae6b7e4716}, type: Upgrade, scope: PerMachine,
version: 1.0.0.0, operation: None
[1F40:1700][2013-02-12T23:07:49]: Detected related bundle:
{63379848-f823-4d73-9364-83bebc1528b2}, type: Upgrade, scope: PerMachine,
version: 1.0.0.0, operation: None
[1F40:1700][2013-02-12T23:07:49]: Detected related bundle:
{886235b4-2f08-4c05-916f-d75266a07525}, type: Upgrade, scope: PerMachine,
version: 1.0.0.0, operation: None
[1F40:1700][2013-02-12T23:07:49]: Detected package: OrgIdSignInAssistant,
state: Absent, cached: None
[1F40:1700][2013-02-12T23:07:49]: Detected package: DummyInstallernPackageId,
state: Present, cached: Complete
[1F40:1700][2013-02-12T23:07:49]: Detect complete, result: 0x0
From: Nan Zang
Sent: Tuesday, February 12, 2013 8:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] questions on bootstrapper
Jocob,
Thank you for your detailed answer. I have another question related to 1.
Besides .Net 3.5, I need another dependency (eg. CredUI.msi) for my BA UX. I
need to use this dependency in one of my BA UX. Is there possible I get it
installed automatically before my BAUX gets launched. I tried the chained
package approach, and found the installation of the credUI.msi will be invoked
when the MSI is launched. That doesn't meet my requirement. Is that possible to
invoke the installation action early?
Thanks,
Nan
From: Hoover, Jacob
Sent: Tuesday, February 12, 2013 7:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]
[WiX-users] Anybody have an example for installing an Isolated Shell
Hi, Does anybody have an example on how to install an Isolated Shell (of Visual Studio) using WiX? http://msdn.microsoft.com/en-us/library/vstudio/bb685691(v=vs.100).aspx There are some examples I can find on the web, but they're pretty much all out-dated. Met vriendelijke groet / kind regards, Wilbert van Dolleweerd http://gplus.to/WilbertVanDolleweerd -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Why does changing INSTALLFOLDER cause InstallDirDlg to break
I am trying to combine InstallScopeDlg and InstallDirDlg into a single UI and have been trying to get it to set INSTALLFOLDER then call the InstallDirDlg which causes an error. I am changing the property with the following. Publish Dialog=InstallScopeDlg Control=Next Property=INSTALLFOLDER Value=[WixPerUserFolder] Order=4WixAppFolder = WixPerUserFolder/Publish Then if I publish to InstallDirDlg after changing this it breaks. I am open to a better way of doing this also as I have just started using WiX. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Why-does-changing-INSTALLFOLDER-cause-InstallDirDlg-to-break-tp7583551.html Sent from the wix-users mailing list archive at Nabble.com. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fragments and Binary elements...
Thanks for your feedback. We are using Wix3.5 (currently looking at moving to 3.7). Unfortunately, using BinaryRef caused an error with candle. However, we tried adding a empty Component to the fragment file and then referenced the dummy component from within the master.wxs file, which forced everything else to be included. This work-a-round worked perfectly. Tristen Fielding -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, February 13, 2013 6:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Fragments and Binary elements... Your last approach is correct. In general, you: Place resources in a fragment in a separate file. Add the file to the project. Reference resources from your main wxs file (or any wxs file that it already references) using an xxxRef. When candle runs, it compiles the wxs file into a wixobj because it is in the project. When light runs, it will see the ref to the fragment and pull in the relevant wixobj created by candle. FragmentRefs are deprecated - just reference the fragment contents. It sounds like you're doing it right. You might have made a mistake somewhere. Try it with a minimal project if necessary to see how it works. -Original Message- From: Tristen Fielding [mailto:tfield...@tradestation.com] Sent: 12 February 2013 22:55 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Fragments and Binary elements... We have a very large wix project and we would like to break it apart. One of the things we would like to do is move several of our Binary element to a fragment but we can't seem to figure out how to make it work. We have something like define in the master.wxs file: Binary Id=WixUI_Bmp_Dialog SourceFile=$(var.MEDIAPATH)\side_panel.bmp / Binary Id=WixUI_Bmp_Banner SourceFile=$(var.MEDIAPATH)\WizardHeader.bmp / Binary Id=WixUI_Bmp_BannerJpn SourceFile=$(var.MEDIAPATH)\WizardHeaderJpn.bmp / Binary Id=WixUI_Bmp_Footer SourceFile=$(var.MEDIAPATH)\WizardFooter.bmp / Binary Id=FirstProgressBMP SourceFile=$(var.MEDIAPATH)\1_awards12_A.bmp / Binary Id=SecondProgressBMP SourceFile=$(var.MEDIAPATH)\2_awards12_B.bmp / Binary Id=ThirdProgressBMP SourceFile=$(var.MEDIAPATH)\3_awards12_C.bmp / Binary Id=FourthProgressBMP SourceFile=$(var.MEDIAPATH)\4_awards12_D.bmp / So we tried simply to move these definition into a new file and wrapped them with a Fragment element. When we built the project the project didn't complain but the binaries weren't in the binaries table. So, we then tried to reference these elements using BinaryRef and FragmentRef but we got error instead. What is the right way to reference these Binary elements in the master.wxs file? Thanks. Tristen Fielding Sr. Software Developer / Program Lead TradeStation Group, Inc. http://www.TradeStation.comhttp://www.tradestation.com/ 8050 SW 10th Street, Suite 2000 Plantation, FL 33324 Tel. 954.652.7320 Fax 954.652.5320 TradeStation Group, Inc. is the parent company of four operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), IBFX, Inc. (Member NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Forex products and services are offered by TradeStation Forex, a division of IBFX, Inc. - - Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall
Re: [WiX-users] Install Prerequisites (.NET Framework)
But even though setting: Bundle ... DisableModify=yes DisableRemove=yes MsiPackage ... *DisplayInternalUI=yes Visible=yes*/ I stil get the Bootstrapper UI visible first. Then When I click Install I got the MSI UI visible in front of Bootstrapper UI. And when MSI UI are finnish the Bootstrapper UI are closed. My intention are just not see anything of the Bootstrapper UI if the .NET Framework are present. Just like the old Visual Studio Setup/Deploy projects... //Sam On Wed, Feb 13, 2013 at 3:49 PM, Sam Boman s...@samb.se wrote: Thanks for this good explanations! Regarding this: You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. How do I specify that? //Sam On Tue, Feb 12, 2013 at 6:04 PM, Pally Sandher pally.sand...@iesve.comwrote: For MSI UI - http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm see the DisplayInternalUI attribute. To list your MSI in Programs Features and not the Burn bundle - http://wix.sourceforge.net/manual-wix3/wix_xsd_bundle.htm see the DisableModify and DisableRemove attributes. Also you will need to set the Visible attribute to yes on your MsiPackage element . You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: 12 February 2013 16:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Prerequisites (.NET Framework) Ok, but I have this issue, or maybe its just the way it works... I have set the Msi project to use: UIRef Id=WixUI_InstallDir/ And then I have added the license agreement rtf-file to it. But when I have added this to the Bootstrapper project: *BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense /* Chain PackageGroupRef Id= Netfx4Full/ ...your msi stuff goes here... /Chain I end up in not getting the Msi UI at all, and in Controlpanel - Programs I just see my bootstrapper projectname... Not the original Msi name and version... I thought that the Bootstrapper just would do its checks, and then handover to the Msi UI, and not display any thing to the user if all is Okay (.NET version are the right.). Thanks! //Sam On Tue, Feb 12, 2013 at 3:37 PM, Pally Sandher pally.sand...@iesve.com wrote: You need 2 projects. You have 2 outputs, an MSI a Burn executable which wraps the MSI and deals with your pre-reqs. You can configure your burn package not to register itself or to not register your MSI. See the Burn documentation - http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm BTW all that extra code Steven posted is completely superfluous. All you literally need in your Burn bundle XML is Chain PackageGroupRef Id= Netfx4Full/ ...your msi stuff goes here... /Chain As WiXNetFxExtension has all the authoring required to do all the checks downloading etc. (and has been checked tested by everyone who uses it on a daily basis). Personally I use PackageGroupRef Id=NetFx40ClientRedist/ because I hate those 'on-demand' installer bundle things. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: 12 February 2013 14:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Prerequisites (.NET Framework) Thanks Steven, I try to get it to work. Also a question regarding, how to arrange things. I have two projects, one that gives me a MSI as output, Its just plain msi-file, no check for .NET framework. The other is a Bootstrapper Project, it hava a reference to the MSI-project. Is this the best way to do it? Or can I keep it in one project? How?
Re: [WiX-users] Why does changing INSTALLFOLDER cause InstallDirDlg to break
Probably because WiXUI doesn't have any idea what your INSTALLFOLDER property is or does. If you're trying to set the contents of the PathEdit in InstallDirDlg you should probably use the WIXUI_INSTALLDIR property associated with it as detailed in the manual - http://wix.sourceforge.net/manual-wix3/WixUI_installdir.htm Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: joshh [mailto:joshuadeanh...@gmail.com] Sent: 13 February 2013 15:41 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Why does changing INSTALLFOLDER cause InstallDirDlg to break I am trying to combine InstallScopeDlg and InstallDirDlg into a single UI and have been trying to get it to set INSTALLFOLDER then call the InstallDirDlg which causes an error. I am changing the property with the following. Publish Dialog=InstallScopeDlg Control=Next Property=INSTALLFOLDER Value=[WixPerUserFolder] Order=4WixAppFolder = WixPerUserFolder/Publish Then if I publish to InstallDirDlg after changing this it breaks. I am open to a better way of doing this also as I have just started using WiX. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Why-does-changing-INSTALLFOLDER-cause-InstallDirDlg-to-break-tp7583551.html Sent from the wix-users mailing list archive at Nabble.com. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Prerequisites (.NET Framework)
You have to write your own Bootstrapper Application to replace the use of WiXBalExtension in that case - http://wix.sourceforge.net/manual-wix3/bootstrapper_application.htm Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: 13 February 2013 16:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Prerequisites (.NET Framework) But even though setting: Bundle ... DisableModify=yes DisableRemove=yes MsiPackage ... *DisplayInternalUI=yes Visible=yes*/ I stil get the Bootstrapper UI visible first. Then When I click Install I got the MSI UI visible in front of Bootstrapper UI. And when MSI UI are finnish the Bootstrapper UI are closed. My intention are just not see anything of the Bootstrapper UI if the .NET Framework are present. Just like the old Visual Studio Setup/Deploy projects... //Sam On Wed, Feb 13, 2013 at 3:49 PM, Sam Boman s...@samb.se wrote: Thanks for this good explanations! Regarding this: You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. How do I specify that? //Sam On Tue, Feb 12, 2013 at 6:04 PM, Pally Sandher pally.sand...@iesve.comwrote: For MSI UI - http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm see the DisplayInternalUI attribute. To list your MSI in Programs Features and not the Burn bundle - http://wix.sourceforge.net/manual-wix3/wix_xsd_bundle.htm see the DisableModify and DisableRemove attributes. Also you will need to set the Visible attribute to yes on your MsiPackage element . You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: 12 February 2013 16:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Prerequisites (.NET Framework) Ok, but I have this issue, or maybe its just the way it works... I have set the Msi project to use: UIRef Id=WixUI_InstallDir/ And then I have added the license agreement rtf-file to it. But when I have added this to the Bootstrapper project: *BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense /* Chain PackageGroupRef Id= Netfx4Full/ ...your msi stuff goes here... /Chain I end up in not getting the Msi UI at all, and in Controlpanel - Programs I just see my bootstrapper projectname... Not the original Msi name and version... I thought that the Bootstrapper just would do its checks, and then handover to the Msi UI, and not display any thing to the user if all is Okay (.NET version are the right.). Thanks! //Sam On Tue, Feb 12, 2013 at 3:37 PM, Pally Sandher pally.sand...@iesve.com wrote: You need 2 projects. You have 2 outputs, an MSI a Burn executable which wraps the MSI and deals with your pre-reqs. You can configure your burn package not to register itself or to not register your MSI. See the Burn documentation - http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm BTW all that extra code Steven posted is completely superfluous. All you literally need in your Burn bundle XML is Chain PackageGroupRef Id= Netfx4Full/ ...your msi stuff goes here... /Chain As WiXNetFxExtension has all the authoring required to do all the checks downloading etc. (and has been checked tested by everyone who uses it on a daily basis). Personally I use PackageGroupRef Id=NetFx40ClientRedist/ because I hate those 'on-demand' installer bundle things. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment**
Re: [WiX-users] Install Prerequisites (.NET Framework)
Okay, I see we have to go that path! Sorry to repeat, but this question also: You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. How do I specify that? On Wed, Feb 13, 2013 at 5:28 PM, Pally Sandher pally.sand...@iesve.comwrote: You have to write your own Bootstrapper Application to replace the use of WiXBalExtension in that case - http://wix.sourceforge.net/manual-wix3/bootstrapper_application.htm Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: 13 February 2013 16:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Prerequisites (.NET Framework) But even though setting: Bundle ... DisableModify=yes DisableRemove=yes MsiPackage ... *DisplayInternalUI=yes Visible=yes*/ I stil get the Bootstrapper UI visible first. Then When I click Install I got the MSI UI visible in front of Bootstrapper UI. And when MSI UI are finnish the Bootstrapper UI are closed. My intention are just not see anything of the Bootstrapper UI if the .NET Framework are present. Just like the old Visual Studio Setup/Deploy projects... //Sam On Wed, Feb 13, 2013 at 3:49 PM, Sam Boman s...@samb.se wrote: Thanks for this good explanations! Regarding this: You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. How do I specify that? //Sam On Tue, Feb 12, 2013 at 6:04 PM, Pally Sandher pally.sand...@iesve.com wrote: For MSI UI - http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm see the DisplayInternalUI attribute. To list your MSI in Programs Features and not the Burn bundle - http://wix.sourceforge.net/manual-wix3/wix_xsd_bundle.htm see the DisableModify and DisableRemove attributes. Also you will need to set the Visible attribute to yes on your MsiPackage element . You should probably set the Burn bundle as related to the MSI so when a user uninstalls the MSI it also uninstalls the Burn bundle. Otherwise the user's system will have the (invisible) Burn bundle still registered which could cause problems if they attempt to reinstall or install a newer release at a later time etc. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sam Boman [mailto:s...@samb.se] Sent: 12 February 2013 16:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Prerequisites (.NET Framework) Ok, but I have this issue, or maybe its just the way it works... I have set the Msi project to use: UIRef Id=WixUI_InstallDir/ And then I have added the license agreement rtf-file to it. But when I have added this to the Bootstrapper project: *BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense /* Chain PackageGroupRef Id= Netfx4Full/ ...your msi stuff goes here... /Chain I end up in not getting the Msi UI at all, and in Controlpanel - Programs I just see my bootstrapper projectname... Not the original Msi name and version... I thought that the Bootstrapper just would do its checks, and then handover to the Msi UI, and not display any thing to the user if all is Okay (.NET version are the right.). Thanks! //Sam On Tue, Feb 12, 2013 at 3:37 PM, Pally Sandher pally.sand...@iesve.com wrote: You need 2 projects. You have 2 outputs, an MSI a Burn executable which wraps the MSI and deals with your pre-reqs. You can configure your burn package not to register itself or to not register your MSI. See the Burn documentation - http://wix.sourceforge.net/manual-wix3/authoring_bundle_intro.htm BTW all that extra code Steven posted is completely superfluous. All you literally need in your Burn bundle
[WiX-users] RegistrySearch returning strange value
Hi all, I ran into the strangest problem on a customer's machine today. He was installing a new version (MAJOR upgrade) of our software which has the authoring below. We set INSTALLDIR from UPGRADEDIR if a previous version is installed (SetUpgradeInstallDir custom action) and make the installation folder read-only (conditioned on UPGRADEDIR) on the [Admin]FolderForm to force the new version to be installed to the same location. On this particular customer's computer, UPGRADEDIR was set to some other application (in fact a Canon software component). This would happen even if I uninstalled the older version of my application and the Canon software. My first thought was that for some reason our UpgradeCode was the same as the Canon software; though we should be able to have GUID collision like that. But after downloading and examining the Canon software's installer, it does not even appear to be Windows Installer based. I am going to modify the conditions to also require PREVIOUSVERSIONSINSTALLED to be non-NULL to determine that this is an upgrade, but why would the RegistrySearch return some other application's Uninstall key? WiX version is 3.0. Installation target is Win7 64-bit. Application/installer is 32-bit. Thanks in advance for any insight you can provide. Bill !-- Find previous installation folder for upgrade after uninstall -- Property Id=UPGRADEDIR RegistrySearch Id=FindInstallLocation Root=HKLM Key=Software\Microsoft\Windows\CurrentVersion\Uninstall\[PREVIOUSVERSIO NSINSTALLED] Name=InstallLocation Type=raw / /Property CustomAction Id=SetUpgradeInstallDir Return=check Execute=oncePerProcess Property=INSTALLDIR Value=[UPGRADEDIR]/ Upgrade Id=$(var.UpgradeCode) UpgradeVersion Minimum=$(var.version) Property=NEWERPRODUCTFOUND OnlyDetect=yes IncludeMinimum=yes / UpgradeVersion Minimum=1.0.0 Maximum=$(var.version) RemoveFeatures=ALL Property=PREVIOUSVERSIONSINSTALLED IncludeMinimum=yes / /Upgrade InstallExecuteSequence . . . Custom Action=SetARPInstallLocation Before=RegisterProductNOT Installed/Custom AppSearch After=FindRelatedProducts/ Custom Action=SetUpgradeInstallDir After=AppSearch![CDATA[UPGRADEDIR ]]/Custom . . . /InstallExecuteSequence InstallUISequence AppSearch After=FindRelatedProducts/ Custom Action=ERRCA_UIANDADVERTISED Before=AppSearch![CDATA[ProductState=1]]/Custom Custom Action=SetUpgradeInstallDir After=AppSearch![CDATA[UPGRADEDIR ]]/Custom . . . /InstallUISequence --**-- This email and any files transmitted with it are confidential and intended solely for the use of Signalscape, Inc. and the addressed individual or entity. If you have received this email in error please delete it. Information in this email may be subject to the Privacy Act of 1974 and any unauthorized review, use, disclosure, or distribution is strictly prohibited. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Finding out the number of cores during install?
Hi During the install of our product we need to know how many cores the CPU has. Does Wix have this capability?. Thanks - Stephen Turner AudioScience, Inc. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Solved! RE: RegistrySearch returning strange value
Solved! It seems that (an older version) of Canon Easy Web-Print EX which shipped with the (in our case) Pixma MG8120 was putting its Uninstall values directly beneath the Uninstall key instead of in its own product-specific key and didn't clear them on uninstall. So for a new install of our product, [PREVIOUSVERSIONSINSTALLED] resolved to an empty string thus causing my AppSearch to resolve to HKLM:Software\Microsoft\Windows\CurrentVersion\Uninstall\@InstallLocatio n where it happily found the erroneous InstallLocation value. The current version of the Canon software on their web site creates the correct Uninstall key/value hierarchy so I was unable to reproduce it on my machine. These people ran into the same issue but were unable to figure it out.. http://community.mediabrowser.tv/permalinks/2650/cronos-install-error Is there any way to get AppSearch to log what path it is searching or at what path it found a valid value? That would have helped tremendously in this case. -Original Message- From: Arnette, Bill [mailto:bi...@signalscape.com] Sent: Wednesday, February 13, 2013 11:42 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] RegistrySearch returning strange value Hi all, I ran into the strangest problem on a customer's machine today. He was installing a new version (MAJOR upgrade) of our software which has the authoring below. We set INSTALLDIR from UPGRADEDIR if a previous version is installed (SetUpgradeInstallDir custom action) and make the installation folder read-only (conditioned on UPGRADEDIR) on the [Admin]FolderForm to force the new version to be installed to the same location. On this particular customer's computer, UPGRADEDIR was set to some other application (in fact a Canon software component). This would happen even if I uninstalled the older version of my application and the Canon software. My first thought was that for some reason our UpgradeCode was the same as the Canon software; though we should be able to have GUID collision like that. But after downloading and examining the Canon software's installer, it does not even appear to be Windows Installer based. I am going to modify the conditions to also require PREVIOUSVERSIONSINSTALLED to be non-NULL to determine that this is an upgrade, but why would the RegistrySearch return some other application's Uninstall key? WiX version is 3.0. Installation target is Win7 64-bit. Application/installer is 32-bit. Thanks in advance for any insight you can provide. Bill !-- Find previous installation folder for upgrade after uninstall -- Property Id=UPGRADEDIR RegistrySearch Id=FindInstallLocation Root=HKLM Key=Software\Microsoft\Windows\CurrentVersion\Uninstall\[PREVIOUSVERSIO NSINSTALLED] Name=InstallLocation Type=raw / /Property CustomAction Id=SetUpgradeInstallDir Return=check Execute=oncePerProcess Property=INSTALLDIR Value=[UPGRADEDIR]/ Upgrade Id=$(var.UpgradeCode) UpgradeVersion Minimum=$(var.version) Property=NEWERPRODUCTFOUND OnlyDetect=yes IncludeMinimum=yes / UpgradeVersion Minimum=1.0.0 Maximum=$(var.version) RemoveFeatures=ALL Property=PREVIOUSVERSIONSINSTALLED IncludeMinimum=yes / /Upgrade InstallExecuteSequence . . . Custom Action=SetARPInstallLocation Before=RegisterProductNOT Installed/Custom AppSearch After=FindRelatedProducts/ Custom Action=SetUpgradeInstallDir After=AppSearch![CDATA[UPGRADEDIR ]]/Custom . . . /InstallExecuteSequence InstallUISequence AppSearch After=FindRelatedProducts/ Custom Action=ERRCA_UIANDADVERTISED Before=AppSearch![CDATA[ProductState=1]]/Custom Custom Action=SetUpgradeInstallDir After=AppSearch![CDATA[UPGRADEDIR ]]/Custom . . . /InstallUISequence --**-- This email and any files transmitted with it are confidential and intended solely for the use of Signalscape, Inc. and the addressed individual or entity. If you have received this email in error please delete it. Information in this email may be subject to the Privacy Act of 1974 and any unauthorized review, use, disclosure, or distribution is strictly prohibited. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ 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 are confidential and
Re: [WiX-users] Question on multiple targets for Upgrade ID?
That error is just enforcing an ICE rule that says you cannot use the same
property name in multiple upgrade table entries. You need a unique property
name for each of the upgrade rows.
Phil W
-Original Message-
From: Vern Graner [mailto:v...@txis.com]
Sent: Tuesday, February 12, 2013 9:26 AM
To: WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] Question on multiple targets for Upgrade ID?
Phil:
Thanks for getting back with me. I reviewed the link you sent and you are
right, it seems like I should be able to use multiple upgrade tags in the
same MSI as shown here:
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=*
UpgradeCode=$(var.ProductUpgradeCode)
Name=MultiProduct Suite test
Version=$(var.ProductVersion)
Manufacturer=Test Company
Language=1033
Package InstallerVersion=200 Compressed=yes
Comments=Windows Installer Package /
Media Id=1 Cabinet=product.cab EmbedCab=yes /
Upgrade Id=29EB2608-6ACA-54F3-8309-CA2B3BBCF9FC
UpgradeVersion Minimum=$(var.ProductVersion)
OnlyDetect=yes
Property=NEWERVERSIONDETECTED /
UpgradeVersion Minimum=0.0.0
Maximum=$(var.ProductVersion)
IncludeMinimum=yes
IncludeMaximum=no
Property=OLDERVERSIONBEINGUPGRADED /
/Upgrade
Upgrade Id=B7841B45-0177-4319-AF4A-594EE33B059C
UpgradeVersion Minimum=$(var.ProductVersion)
OnlyDetect=yes
Property=NEWERVERSIONDETECTED /
UpgradeVersion Minimum=0.0.0
Maximum=$(var.ProductVersion)
IncludeMinimum=yes
IncludeMaximum=no
Property=OLDERVERSIONBEINGUPGRADED /
/Upgrade
Upgrade Id=63CCD546-72A6-9C4E-BF0D-7BCDEE05EE9A
UpgradeVersion Minimum=$(var.ProductVersion)
OnlyDetect=yes
Property=NEWERVERSIONDETECTED /
UpgradeVersion Minimum=0.0.0
Maximum=$(var.ProductVersion)
IncludeMinimum=yes
IncludeMaximum=no
Property=OLDERVERSIONBEINGUPGRADED /
/Upgrade
Condition Message=A newer version of this software is already
installed.
NOT NEWERVERSIONDETECTED
/Condition
Produces the following when compiled in WiX edit:
- Starting C:\Program Files\WixEdit\wix-3.0.5419.0\candle.exe
-nologo K:\MSI Packages\MSI_Prompt\UPGRADE-TEST.XML -out K:\MSI
Packages\MSI_Prompt\UPGRADE-TEST.wixobj -ext WixUIExtension at
2/12/2013 9:51:46 AM
UPGRADE-TEST.XML
Done in: 296 ms
- Starting C:\Program Files\WixEdit\wix-3.0.5419.0\light.exe -nologo
K:\MSI Packages\MSI_Prompt\UPGRADE-TEST.wixobj -out K:\MSI
Packages\MSI_Prompt\UPGRADE-TEST.msi -ext WixUIExtension at 2/12/2013
9:51:46 AM
K:\MSI Packages\MSI_Prompt\UPGRADE-TEST.XML(30) : error LGHT0204 :
ICE61: Upgrade.ActionProperty NEWERVERSIONDETECTED may be used in only one
record of the Upgrade table.
K:\MSI Packages\MSI_Prompt\UPGRADE-TEST.XML(33) : error LGHT0204 :
ICE61: Upgrade.ActionProperty OLDERVERSIONBEINGUPGRADED may be used in only
one record of the Upgrade table.
- Finished
Error in light
On 2/11/2013 8:50 PM, Phil Wilson wrote:
There's nothing about the underlying Upgrade table in the MSI file
that prevents one product from upgrading several.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372379(v=vs.
85).as
px
Phil
-Original Message-
From: Vern Graner [mailto:v...@txis.com]
Sent: Monday, February 11, 2013 5:02 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Question on multiple targets for Upgrade ID?
Hi all. I'm hoping someone here can answer this- A quick summary:
The company for which I work had a suite of products that were widely
distributed with their own individual MSIs- each with a unique Upgrade
Code (i.e. Product1 w/UpgradeCode1, Product2 w/UpgradeCode2, Product3
w/UpgradeCode3.
They now are bundling all three of these individual products into a
new single product suite. They would like to have this new suite MSI
search for and replace ALL of the earlier individual product MSIs it
finds.
I have created an MSI that will take an Upgrade ID={GUID} and will
find and replace a *single* product, but I need this to find/remove
all three products before proceeding with the suite install. Is this even
possible?
Thanks in advance for any insight you folks can offer!
Vern
--
Vern Graner CNE/CNA/SSE| If the network is down, then you're
Senior Systems Engineer| obviously incompetent so why are we
Texas Information Services | paying
Re: [WiX-users] Finding out the number of cores during install?
No, it doesn't. But I've already answered that on Stack Overflow for you. From: Stephen Turner sgtur...@audioscience.com Sent: Wednesday, February 13, 2013 12:29 PM To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject: [WiX-users] Finding out the number of cores during install? Hi During the install of our product we need to know how many cores the CPU has. Does Wix have this capability?. Thanks - Stephen Turner AudioScience, Inc. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] C# Custom Actions - Cannot Trace
I am learning to use wix and have come across an issue that doesn't seem to make sense to me. I have created 2 CustomActions one in c++ and one in c#. (Purely for experimental purposes) Both CAs simply contain a MessageBox. (To prove they are being called). And both are called correctly. The difference between the two is I can trace the C++ one but not the C# one. I use attach to process in both cases, but the c# one does not recognize its PDB. Here is what I have tried so far: - Used MSIBreak, nothing happens. But found posts of this issue with Windows 7 not working very well - Tried this too, which should be the proper way to do this but I get nothing. Record record = new Record(2); record[0] = [1]; record[1] = My MSI Message; session.Message(InstallMessage.Info, record); I have searched without any success, I am convinced this is something obvious I am not seeing. How do you attach to a process to be able to trace a c# CA. My message box according to the debugger is running through Run32dll as expected. Thanks for the advice Marc -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Actions - Cannot Trace
For C# using DTF it's MMsiBreak. For C/C++ it's MsiBreak. Also you have to restart the machine after setting the env var for the service control manager to pick up the environment change and pass it along to the Windows Installer service. I've debugged many DTF custom actions it's entirely possible to attach a debugger to the messagebox. That said, I find it easier to unit test the class and then create the custom action class as a very thin veneer around it. Testing inside MSI's is just too much friction for my taste. From: Marc Beaudry mbeau...@matrox.com Sent: Wednesday, February 13, 2013 3:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] C# Custom Actions - Cannot Trace I am learning to use wix and have come across an issue that doesn't seem to make sense to me. I have created 2 CustomActions one in c++ and one in c#. (Purely for experimental purposes) Both CAs simply contain a MessageBox. (To prove they are being called). And both are called correctly. The difference between the two is I can trace the C++ one but not the C# one. I use attach to process in both cases, but the c# one does not recognize its PDB. Here is what I have tried so far: - Used MSIBreak, nothing happens. But found posts of this issue with Windows 7 not working very well - Tried this too, which should be the proper way to do this but I get nothing. Record record = new Record(2); record[0] = [1]; record[1] = My MSI Message; session.Message(InstallMessage.Info, record); I have searched without any success, I am convinced this is something obvious I am not seeing. How do you attach to a process to be able to trace a c# CA. My message box according to the debugger is running through Run32dll as expected. Thanks for the advice Marc -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Project Haveresting in WiX 3.7
Hi I know EnableProjectHarvest was set to false by default in 3.6 due to harvesting complications. To enable it you had to go and set it to true. But this doesn't appear to work for 3.7. What is the state of harvesting in 3.7? For me it works fine in 3.5, (and in 3.6), and I would like to upgrade to WiX 3.7 but I can't if I cannot get the harvesting to work. Thanks in advance. Darrin Robertson Tech Design Development Specialist | Design Development Standards | Enterprise Services | ASB creating futures 4148070 direct | 90070 extension | darrin.robert...@asb.co.nzmailto:darrin.robert...@asb.co.nz | asb.co.nz This email may contain information which is confidential and/or subject to legal privilege. If you are not the intended recipient, please immediately notify the sender and delete the email. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] problem on setting passing selected feature from burn to msi
My MSI has two dummy feature as listed below.
Feature Id=FULLPRODUCTION Title=RMSSetupInstaller
ComponentGroupRef Id=ProductComponents /
/Feature
Feature Id=ADMINCONFIGURATIONTOOL Title=RMSAdminInstaller
ComponentGroupRef Id=AdminComponents /
/Feature
And I am using customize UI to collect user feature selection, then pass it
into through Engine by using following code
this.Bootstrapper.Engine.StringVariables[ADDLOCAL] =
featureList;
this.Bootstrapper.Engine.Plan(LaunchAction.Install);
This is my log, the addlocal variable doesn't seem work. Anything I am
missing here? Thank you for help.
[3B40:1788][2013-02-13T19:02:26]: Detected package: NetFX40, state: Present,
cached: None
[3B40:1788][2013-02-13T19:02:26]: Detected package:
RMSSetupInstallationPackageId, state: Absent, cached: None
[3B40:1788][2013-02-13T19:02:26]: Detected package:
RMSSetupInstallationPackageId, feature: FULLPRODUCTION, state: Absent
[3B40:1788][2013-02-13T19:02:26]: Detected package:
RMSSetupInstallationPackageId, feature: ADMINCONFIGURATIONTOOL, state: Absent
[3B40:1788][2013-02-13T19:02:26]: Detect complete, result: 0x0
[3B40:25E8][2013-02-13T19:02:38]: Add property name ADDLOCAL with
valueADMINCONFIGURATIONTOOL
[3B40:25E8][2013-02-13T19:02:38]: Setting string variable 'ADDLOCAL' to value
'ADMINCONFIGURATIONTOOL'
[3B40:1788][2013-02-13T19:02:38]: Plan 2 packages, action: Install
[3B40:1788][2013-02-13T19:02:38]: Skipping dependency registration on package
with no dependency providers: NetFX40
[3B40:1788][2013-02-13T19:02:38]: Plan 2 msi features for package:
RMSSetupInstallationPackageId
[3B40:1788][2013-02-13T19:02:38]: Planned feature: FULLPRODUCTION, state:
Absent, default requested: Unknown, ba requested: Unknown, execute action:
None, rollback action: None
[3B40:1788][2013-02-13T19:02:38]: Planned feature: ADMINCONFIGURATIONTOOL,
state: Absent, default requested: Unknown, ba requested: Unknown, execute
action: None, rollback action: None
[3B40:1788][2013-02-13T19:02:38]: Setting string variable
'WixBundleRollbackLog_RMSSetupInstallationPackageId' to value
'e:\wix\Dev\wix37\setup_0_RMSSetupInstallationPackageId_rollback.log'
[3B40:1788][2013-02-13T19:02:38]: Setting string variable
'WixBundleLog_RMSSetupInstallationPackageId' to value
'e:\wix\Dev\wix37\setup_0_RMSSetupInstallationPackageId.log'
[3B40:1788][2013-02-13T19:02:38]: Planned package: NetFX40, state: Present,
default requested: Present, ba requested: Present, execute: None, rollback:
None, cache: No, uncache: No, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Planned package:
RMSSetupInstallationPackageId, state: Absent, default requested: Present, ba
requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache:
Yes, dependency: Register
[3B40:1788][2013-02-13T19:02:38]: Planned related bundle:
{4d72440b-3501-4b0c-9ee3-2fae6b7e4716}, type: Upgrade, default requested: None,
ba requested: None, execute: None, rollback: None, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Planned related bundle:
{63379848-f823-4d73-9364-83bebc1528b2}, type: Upgrade, default requested: None,
ba requested: None, execute: None, rollback: None, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Planned related bundle:
{886235b4-2f08-4c05-916f-d75266a07525}, type: Upgrade, default requested: None,
ba requested: None, execute: None, rollback: None, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Planned related bundle:
{f08b430f-3d9c-4d8e-a160-708f9be5827e}, type: Upgrade, default requested: None,
ba requested: None, execute: None, rollback: None, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Plan complete, result: 0x0
[3B40:1788][2013-02-13T19:02:38]: Apply begin
[3554:1888][2013-02-13T19:02:38]: Creating a system restore point.
[3554:1888][2013-02-13T19:02:38]: System restore disabled, system restore point
not created.
[3554:1888][2013-02-13T19:02:38]: Caching bundle from:
'C:\Users\nazang\AppData\Local\Temp\{34d831eb-4e21-4fed-9502-58ee48298d6f}\.be\BootstrapperSetup.exe'
to: 'C:\ProgramData\Package
Cache\{34d831eb-4e21-4fed-9502-58ee48298d6f}\BootstrapperSetup.exe'
[3554:1888][2013-02-13T19:02:38]: Registering bundle dependency provider:
{34d831eb-4e21-4fed-9502-58ee48298d6f}, version: 1.0.0.0
[3554:21F0][2013-02-13T19:02:38]: Verified acquired payload:
RMSSetupInstallationPackageId at path: C:\ProgramData\Package
Cache\.unverified\RMSSetupInstallationPackageId, moving to:
C:\ProgramData\Package
Cache\{5DE269D0-9B2D-4AAE-A330-56410E9AFA11}v1.0.0.0\RMSSetupInstaller.msi.
[3554:21F0][2013-02-13T19:02:38]: Verified acquired payload:
cab889C4727BDD85A0DB399FF3308DF872E at path: C:\ProgramData\Package
Cache\.unverified\cab889C4727BDD85A0DB399FF3308DF872E, moving to:
C:\ProgramData\Package
Cache\{5DE269D0-9B2D-4AAE-A330-56410E9AFA11}v1.0.0.0\cab1.cab.
[3554:1888][2013-02-13T19:02:39]: Applying execute package:
Re: [WiX-users] Heat Website Harvester Status?
Hi Aaron, Did you find the solution ... I was looking for solution for website Harvesting. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-Website-Harvester-Status-tp3177602p7583566.html Sent from the wix-users mailing list archive at Nabble.com. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] msi.dll crashes during transaction.Commit()
Hello Guys,
We have a very intermittent bug in the installer that we are developing.
We have a bootstrapper that uses WiX 3.5 and has the following code:
/var transactionSession = new Transaction(ANTON,
TransactionAttributes.None);
foreach (var msiPackage in msiPackageList)
{
Installer.InstallProduct(msiPackage, string.Empty);
}
transactionSession.Commit();
transactionSession.Close();/
This simply creates a transaction session, installs several msis from the
list, and then commits the transaction. However in some cases, msi.dll
crashes during the transaction Commit() call.
*Exception message in transaction.Commit:*
/The Windows Installer Service could not be accessed. This can occur if the
Windows Installer is not correctly installed. Contact your support personnel
for assistance./
*Event logs:*
/Faulting application name: msiexec.exe, version: 5.0.7601.17514, time
stamp: 0x4ce792c4
Faulting module name: msi.dll, version: 5.0.7601.17514, time stamp:
0x4ce7b902
Exception code: 0xc005
Fault offset: 0x00027b88
Faulting process id: 0xe0c
Faulting application start time: 0x01cd4a967dd25cb4
Faulting application path: C:\Windows\system32\msiexec.exe
Faulting module path: C:\Windows\system32\msi.dll
Report Id: 756b0d09-b68b-11e1-86f9-001b21740788/
All the MSIs are created from InstallShield basic msi project. Any ideas
what might be causing this?
Your help is appreciated guys :)
Cheers,
Anton
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/msi-dll-crashes-during-transaction-Commit-tp7583567.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] problem on setting passing selected feature from burn to msi
I think I found the issue.
In bundle msipackage definition I need to define the following. Property to
make it work
msiproperty name=ADDLOCAL value=[ADDLOCAL]/
Sent from my Windows Phone
From: Nan Zangmailto:naz...@microsoft.com
Sent: 2/13/2013 7:15 PM
To: General discussion for Windows Installer XML toolset.
(wix-users@lists.sourceforge.net)mailto:wix-users@lists.sourceforge.net
Subject: [WiX-users] problem on setting passing selected feature from burn to
msi
My MSI has two dummy feature as listed below.
Feature Id=FULLPRODUCTION Title=RMSSetupInstaller
ComponentGroupRef Id=ProductComponents /
/Feature
Feature Id=ADMINCONFIGURATIONTOOL Title=RMSAdminInstaller
ComponentGroupRef Id=AdminComponents /
/Feature
And I am using customize UI to collect user feature selection, then pass it
into through Engine by using following code
this.Bootstrapper.Engine.StringVariables[ADDLOCAL] =
featureList;
this.Bootstrapper.Engine.Plan(LaunchAction.Install);
This is my log, the addlocal variable doesn't seem work. Anything I am
missing here? Thank you for help.
[3B40:1788][2013-02-13T19:02:26]: Detected package: NetFX40, state: Present,
cached: None
[3B40:1788][2013-02-13T19:02:26]: Detected package:
RMSSetupInstallationPackageId, state: Absent, cached: None
[3B40:1788][2013-02-13T19:02:26]: Detected package:
RMSSetupInstallationPackageId, feature: FULLPRODUCTION, state: Absent
[3B40:1788][2013-02-13T19:02:26]: Detected package:
RMSSetupInstallationPackageId, feature: ADMINCONFIGURATIONTOOL, state: Absent
[3B40:1788][2013-02-13T19:02:26]: Detect complete, result: 0x0
[3B40:25E8][2013-02-13T19:02:38]: Add property name ADDLOCAL with
valueADMINCONFIGURATIONTOOL
[3B40:25E8][2013-02-13T19:02:38]: Setting string variable 'ADDLOCAL' to value
'ADMINCONFIGURATIONTOOL'
[3B40:1788][2013-02-13T19:02:38]: Plan 2 packages, action: Install
[3B40:1788][2013-02-13T19:02:38]: Skipping dependency registration on package
with no dependency providers: NetFX40
[3B40:1788][2013-02-13T19:02:38]: Plan 2 msi features for package:
RMSSetupInstallationPackageId
[3B40:1788][2013-02-13T19:02:38]: Planned feature: FULLPRODUCTION, state:
Absent, default requested: Unknown, ba requested: Unknown, execute action:
None, rollback action: None
[3B40:1788][2013-02-13T19:02:38]: Planned feature: ADMINCONFIGURATIONTOOL,
state: Absent, default requested: Unknown, ba requested: Unknown, execute
action: None, rollback action: None
[3B40:1788][2013-02-13T19:02:38]: Setting string variable
'WixBundleRollbackLog_RMSSetupInstallationPackageId' to value
'e:\wix\Dev\wix37\setup_0_RMSSetupInstallationPackageId_rollback.log'
[3B40:1788][2013-02-13T19:02:38]: Setting string variable
'WixBundleLog_RMSSetupInstallationPackageId' to value
'e:\wix\Dev\wix37\setup_0_RMSSetupInstallationPackageId.log'
[3B40:1788][2013-02-13T19:02:38]: Planned package: NetFX40, state: Present,
default requested: Present, ba requested: Present, execute: None, rollback:
None, cache: No, uncache: No, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Planned package:
RMSSetupInstallationPackageId, state: Absent, default requested: Present, ba
requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache:
Yes, dependency: Register
[3B40:1788][2013-02-13T19:02:38]: Planned related bundle:
{4d72440b-3501-4b0c-9ee3-2fae6b7e4716}, type: Upgrade, default requested: None,
ba requested: None, execute: None, rollback: None, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Planned related bundle:
{63379848-f823-4d73-9364-83bebc1528b2}, type: Upgrade, default requested: None,
ba requested: None, execute: None, rollback: None, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Planned related bundle:
{886235b4-2f08-4c05-916f-d75266a07525}, type: Upgrade, default requested: None,
ba requested: None, execute: None, rollback: None, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Planned related bundle:
{f08b430f-3d9c-4d8e-a160-708f9be5827e}, type: Upgrade, default requested: None,
ba requested: None, execute: None, rollback: None, dependency: None
[3B40:1788][2013-02-13T19:02:38]: Plan complete, result: 0x0
[3B40:1788][2013-02-13T19:02:38]: Apply begin
[3554:1888][2013-02-13T19:02:38]: Creating a system restore point.
[3554:1888][2013-02-13T19:02:38]: System restore disabled, system restore point
not created.
[3554:1888][2013-02-13T19:02:38]: Caching bundle from:
'C:\Users\nazang\AppData\Local\Temp\{34d831eb-4e21-4fed-9502-58ee48298d6f}\.be\BootstrapperSetup.exe'
to: 'C:\ProgramData\Package
Cache\{34d831eb-4e21-4fed-9502-58ee48298d6f}\BootstrapperSetup.exe'
[3554:1888][2013-02-13T19:02:38]: Registering bundle dependency provider:
{34d831eb-4e21-4fed-9502-58ee48298d6f}, version: 1.0.0.0
[3554:21F0][2013-02-13T19:02:38]: Verified acquired payload:
RMSSetupInstallationPackageId at path: C:\ProgramData\Package
