[WiX-users] WiX 3.6 beta installation failed
Hi, Is there any way now to download full package for WiX 3.6.beta installation (which doesn't try to download something during the installation)? I tried to install Wix36.exe but it failed with the following error: Error 0x80070002: Failed to download payload from URL:'http://wix.sourceforge.net/releases/data/ProjectAggregator2.msi' (By the way I have already ProjectAggregator2 installed). Thanks, Maksim -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to display the list of features to be installed
The first 4 properties under Feature Installation Options Properties would be the place to start. http://msdn.microsoft.com/en-us/library/aa370905%28VS.85%29.aspx#feature_inst allation_options_properties -Original Message- From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com] Sent: 24 October 2011 19:07 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to display the list of features to be installed Dear All, We would like to display before entering the Execute sequence the list of features that the user selects to install, but do not know what the best approach would be. Specifically, the implementation involves getting the feature install status and organizing the features to install into a list. If you have any idea, please let us know. Thanks a lot, Miaohsi *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). - - The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users 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. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.6 beta installation failed
Hi, this is most likely because there is an issue at wix.sourceforce.org; When you go to that site you'll see a message like 'This project has been temporarily blocked for exceeding its bandwidth threshold' So maybe someone has the power to fix this??? I can't download the last weekly build also... Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: maksim.vazhe...@emc.com [mailto:maksim.vazhe...@emc.com] Verzonden: 25 October 2011 08:27 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] WiX 3.6 beta installation failed Hi, Is there any way now to download full package for WiX 3.6.beta installation (which doesn't try to download something during the installation)? I tried to install Wix36.exe but it failed with the following error: Error 0x80070002: Failed to download payload from URL:'http://wix.sourceforge.net/releases/data/ProjectAggregator2.msi' (By the way I have already ProjectAggregator2 installed). Thanks, Maksim -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX 3.6 beta and virus checker
Dear All,
I am not able to install the new 3.6 beta exe file (Wix36.exe) because my virus
checker (Trend Micro OfficeScan) terminates the installer when it tries to
write to the RunOnce registry key.
I was able to download and run WiX 3.6 from the wix36-binaries.zip archive,
however my minimal test installer also falls foul of Trend for the same reason.
(I include my .wxs files below)
I've never seen this for any other package I've installed. Does anyone know
about this or have a workaround?
Peter
bfirst.wxs
==
?xml version=1.0?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Bundle Version=1.0 Name=First Wix 3.6
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.RtfLicense /
Chain
MsiPackage SourceFile=first.msi /
/Chain
/Bundle
/Wix
first.wxs
=
?xml version='1.0'?
Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'
Product Id='{1427C75A-90A8-46e4-B0A7-1BBA7DEEF0F3}' Name='Test Package'
Language='1033'
Version='1.0.0.0' Manufacturer='Microsoft Corporation'
UpgradeCode='{1DF5EE00-3C58-4a94-B57C-63AC18E85A6F}'
Package Description='My first Windows Installer package'
Comments='This is my first attempt at creating a Windows
Installer database'
Manufacturer='Microsoft Corporation' InstallerVersion='200'
Compressed='yes' /
Directory Id='TARGETDIR' Name='SourceDir'
Component Id='MyComponent'
Guid='{87D198BF-6B84-4bd8-811E-8831A89FC721}' /
/Directory
Feature Id='MyFeature' Title='My 1st Feature' Level='1'
ComponentRef Id='MyComponent' /
/Feature
/Product
/Wix
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] BA: Shutdown() or Quit()?
The documentation for Burn says that a BA should call Shutdown() when it's finished. However, there doesn't seem to be such a method, while Quit() does exist. Has this been renamed at some point and the documentation is lagging behind? -- Bruce Cran -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Leave an entire feature behind at uninstall
What about a separate mini-install that has the components you want to leave behind like the both SQL Server and the ATI Catalyst packages do? -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 24, 2011 11:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Leave an entire feature behind at uninstall 1. Don't try to leave a Feature behind. It'll drive you crazy. 2. I'd probably try this... or use no GUID if you don't want to manage the data at all. 3. Custom actions are an admission of failure: http://robmensching.com/blog/posts/2007/8/17/Zataoca-Custom-actions-are-generally-an-admission-of-failuresmile/ On Mon, Oct 24, 2011 at 11:12 AM, Uma Harano uhar...@esri.com wrote: Hi, As part of a setup logic, I need to leave behind a big chunk of resources on disk at uninstall. The resources are data files and I have been asked to leave them behind at uninstall. When the setup is run again on the machine where this data is left behind, the user has the option to use the existing data (so it will not get installed again) or install the data (over write the data or install it to a new location). Can someone recommend the approach I should take to solve this? * A feature that installs this data. Hide the feature at uninstall so that it doesn't get removed. But this orphans components and could potentially cause issues, correct? * Set the component bit(msidbComponentAttributesPermanent) to not uninstall to every component of the data feature (there are MANY components for this data - so I am worried about this) * Install data to a different location all the time. Copy the data to the data location based on the user choice (Using a custom action) Thanks! Uma- -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Leave an entire feature behind at uninstall
That was my initial plan - make an exe sort of thing that gets run separately. The use no GUID option that Rob mentions is perfect for me - I think I will pursue that option and see how it goes. This forum is great - thank you so much for these great suggestions. Uma- -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Tuesday, October 25, 2011 7:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Leave an entire feature behind at uninstall What about a separate mini-install that has the components you want to leave behind like the both SQL Server and the ATI Catalyst packages do? -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 24, 2011 11:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Leave an entire feature behind at uninstall 1. Don't try to leave a Feature behind. It'll drive you crazy. 2. I'd probably try this... or use no GUID if you don't want to manage the data at all. 3. Custom actions are an admission of failure: http://robmensching.com/blog/posts/2007/8/17/Zataoca-Custom-actions-are-generally-an-admission-of-failuresmile/ On Mon, Oct 24, 2011 at 11:12 AM, Uma Harano uhar...@esri.com wrote: Hi, As part of a setup logic, I need to leave behind a big chunk of resources on disk at uninstall. The resources are data files and I have been asked to leave them behind at uninstall. When the setup is run again on the machine where this data is left behind, the user has the option to use the existing data (so it will not get installed again) or install the data (over write the data or install it to a new location). Can someone recommend the approach I should take to solve this? * A feature that installs this data. Hide the feature at uninstall so that it doesn't get removed. But this orphans components and could potentially cause issues, correct? * Set the component bit(msidbComponentAttributesPermanent) to not uninstall to every component of the data feature (there are MANY components for this data - so I am worried about this) * Install data to a different location all the time. Copy the data to the data location based on the user choice (Using a custom action) Thanks! Uma- -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BA: Shutdown() or Quit()?
Yeah, one of the two is wrong. smile/ On Tue, Oct 25, 2011 at 6:26 AM, Bruce Cran br...@cran.org.uk wrote: The documentation for Burn says that a BA should call Shutdown() when it's finished. However, there doesn't seem to be such a method, while Quit() does exist. Has this been renamed at some point and the documentation is lagging behind? -- Bruce Cran -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] RegistrySearch fails, returns C: or Empty
Hello all, I am having some problems with an installation using Wix v3 During install of application I run Property Id=SETUPFOLDER RegistrySearch Id=SETUPFOLDER Root=HKCU Key=SOFTWARE\$(var.Company)\$(var.Product)\Common Name=SetupFolder Type=raw / /Property SETUPFOLDER is later used for setting the target of a shortcut in the start menu. This works when I install or reinstall by running my bootstrapper setup.exe which then starts the MSI package. But when applying patches for instance or bypassig the setup.exe and running the MSI directly, then the registry search returns C: or is just empty. When I check that path in registry using regedit then I do find the correct value there but for some reason the RegistrySearch fails and I can't figure out why. Notable is that this error does not exist in Windows XP, but now as I have been porting it to Windows 7 I noticed this problem. So basically the code should work, but it doesn't do that in Win7 (only works if I go through the bootstrapper exe) Any suggestions? Thanks! Leo -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RegistrySearch fails, returns C: or Empty
What does the verbose log file show? On Tue, Oct 25, 2011 at 8:10 AM, Leo Koivuniemi universalserial...@gmail.com wrote: Hello all, I am having some problems with an installation using Wix v3 During install of application I run Property Id=SETUPFOLDER RegistrySearch Id=SETUPFOLDER Root=HKCU Key=SOFTWARE\$(var.Company)\$(var.Product)\Common Name=SetupFolder Type=raw / /Property SETUPFOLDER is later used for setting the target of a shortcut in the start menu. This works when I install or reinstall by running my bootstrapper setup.exe which then starts the MSI package. But when applying patches for instance or bypassig the setup.exe and running the MSI directly, then the registry search returns C: or is just empty. When I check that path in registry using regedit then I do find the correct value there but for some reason the RegistrySearch fails and I can't figure out why. Notable is that this error does not exist in Windows XP, but now as I have been porting it to Windows 7 I noticed this problem. So basically the code should work, but it doesn't do that in Win7 (only works if I go through the bootstrapper exe) Any suggestions? Thanks! Leo -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.6 beta and virus checker
Wow, that's a pretty aggressive virus checker. How do you install software
that requires a reboot with that thing turned on?
Can you open a bug with this information in it? I'm not exactly sure what
we'll do about it but we should at least track the issue.
On Tue, Oct 25, 2011 at 2:37 AM, Peter Hull peterhul...@hotmail.com wrote:
Dear All,
I am not able to install the new 3.6 beta exe file (Wix36.exe) because my
virus checker (Trend Micro OfficeScan) terminates the installer when it
tries to write to the RunOnce registry key.
I was able to download and run WiX 3.6 from the wix36-binaries.zip archive,
however my minimal test installer also falls foul of Trend for the same
reason. (I include my .wxs files below)
I've never seen this for any other package I've installed. Does anyone know
about this or have a workaround?
Peter
bfirst.wxs
==
?xml version=1.0?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Bundle Version=1.0 Name=First Wix 3.6
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.RtfLicense /
Chain
MsiPackage SourceFile=first.msi /
/Chain
/Bundle
/Wix
first.wxs
=
?xml version='1.0'?
Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'
Product Id='{1427C75A-90A8-46e4-B0A7-1BBA7DEEF0F3}' Name='Test Package'
Language='1033'
Version='1.0.0.0' Manufacturer='Microsoft Corporation'
UpgradeCode='{1DF5EE00-3C58-4a94-B57C-63AC18E85A6F}'
Package Description='My first Windows Installer package'
Comments='This is my first attempt at creating a Windows
Installer database'
Manufacturer='Microsoft Corporation' InstallerVersion='200'
Compressed='yes' /
Directory Id='TARGETDIR' Name='SourceDir'
Component Id='MyComponent'
Guid='{87D198BF-6B84-4bd8-811E-8831A89FC721}' /
/Directory
Feature Id='MyFeature' Title='My 1st Feature' Level='1'
ComponentRef Id='MyComponent' /
/Feature
/Product
/Wix
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
virtually, Rob Mensching - http://RobMensching.com LLC
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.6 beta installation failed
Hmm, I thought we fixed the bandwidth problem by removing most of this content. Albert, can you refresh your browser to see if you're just hitting a cached page or not. Maksim, can you look in your %TEMP% folder and paste in the failing log file? I'd like to understand why the project aggregator is being downloaded if you already have it installed (I thought we fixed tha bug). I'll look for a work around at the same time. On Tue, Oct 25, 2011 at 1:36 AM, Albert van Peppen alb...@insad.nl wrote: Hi, this is most likely because there is an issue at wix.sourceforce.org; When you go to that site you'll see a message like 'This project has been temporarily blocked for exceeding its bandwidth threshold' So maybe someone has the power to fix this??? I can't download the last weekly build also... Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. -Oorspronkelijk bericht- Van: maksim.vazhe...@emc.com [mailto:maksim.vazhe...@emc.com] Verzonden: 25 October 2011 08:27 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] WiX 3.6 beta installation failed Hi, Is there any way now to download full package for WiX 3.6.beta installation (which doesn't try to download something during the installation)? I tried to install Wix36.exe but it failed with the following error: Error 0x80070002: Failed to download payload from URL:' http://wix.sourceforge.net/releases/data/ProjectAggregator2.msi' (By the way I have already ProjectAggregator2 installed). Thanks, Maksim -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RegistrySearch fails, returns C: or Empty
Hi, thanks for fast reply! In the MSI log I can see that it actually finds the correct SETUPFOLDER path from registry, but then there are some rows saying: Ignoring disallowed property SETUPFOLDER But I can see that it finds the correct path because further down in the log I have something like AppSearch: Property: SETUPFOLDER, Signature: SETUPFOLDER MSI (c) (F0:80) [17:32:47:087]: Note: 1: 2262 2: Signature 3: -2147287038 MSI (c) (F0:80) [17:32:47:087]: PROPERTY CHANGE: Adding SETUPFOLDER property. Its value is '\\rrdb\xxx\xxx\Setup'. And then an .ini file is written and it now the log (almost at the very end) says: MSI (s) (3C:44) [17:34:07:697]: Executing op: IniWriteRemoveValue(Section=INSTANCE,Key=SetupFolder,,Mode=0) WriteIniValues: File: xxx.ini, Section: INSTANCE, Key: SetupFolder, Value: Note that the value: is empty. And then at the very very end of the log file it states the properties: Property(C): SETUPFOLDER = \\rrdb\xxx\xxx\Setup So again it has the correct value but it does not want to use it when specifying the target of the shortcut. Hope this gives you some idea... Thankful for help! 2011/10/25 Rob Mensching r...@robmensching.com What does the verbose log file show? On Tue, Oct 25, 2011 at 8:10 AM, Leo Koivuniemi universalserial...@gmail.com wrote: Hello all, I am having some problems with an installation using Wix v3 During install of application I run Property Id=SETUPFOLDER RegistrySearch Id=SETUPFOLDER Root=HKCU Key=SOFTWARE\$(var.Company)\$(var.Product)\Common Name=SetupFolder Type=raw / /Property SETUPFOLDER is later used for setting the target of a shortcut in the start menu. This works when I install or reinstall by running my bootstrapper setup.exe which then starts the MSI package. But when applying patches for instance or bypassig the setup.exe and running the MSI directly, then the registry search returns C: or is just empty. When I check that path in registry using regedit then I do find the correct value there but for some reason the RegistrySearch fails and I can't figure out why. Notable is that this error does not exist in Windows XP, but now as I have been porting it to Windows 7 I noticed this problem. So basically the code should work, but it doesn't do that in Win7 (only works if I go through the bootstrapper exe) Any suggestions? Thanks! Leo -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Add/Remove Programs doesn't refresh sometimes
Bob Arnson-6 wrote: Nope. ARP/PF doesn't do a wholesale refresh of the program list for MSI packages. When you click Uninstall and it succeeds, it just deletes that one entry. Okay. I wonder what the difference is between doing an uninstall via the usual method and doing an uninstall via Change Remove. I tried a few times and the first method triggers refresh and the second doesn't. It sounds like it's not on the MSI side of the wall, so I won't worry about it. Just makes me curios. Thanks, Bob :) - John -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Add-Remove-Programs-doesn-t-refresh-sometimes-tp6918973p6929327.html Sent from the wix-users mailing list archive at Nabble.com. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RegistrySearch fails, returns C: or Empty
Hi again, I believe I solved it (haven't done enough testing yet though!)! It seems that the property had to be set as Secure=yes since otherwise UAC will not allow it. Will get back to you if I find that it is not solved. But I just tried an installation that earlier did not work and now it did! Thanks for all help so far anyway! Leo 2011/10/25 Leo Koivuniemi universalserial...@gmail.com Hi, thanks for fast reply! In the MSI log I can see that it actually finds the correct SETUPFOLDER path from registry, but then there are some rows saying: Ignoring disallowed property SETUPFOLDER But I can see that it finds the correct path because further down in the log I have something like AppSearch: Property: SETUPFOLDER, Signature: SETUPFOLDER MSI (c) (F0:80) [17:32:47:087]: Note: 1: 2262 2: Signature 3: -2147287038 MSI (c) (F0:80) [17:32:47:087]: PROPERTY CHANGE: Adding SETUPFOLDER property. Its value is '\\rrdb\xxx\xxx\Setup'. And then an .ini file is written and it now the log (almost at the very end) says: MSI (s) (3C:44) [17:34:07:697]: Executing op: IniWriteRemoveValue(Section=INSTANCE,Key=SetupFolder,,Mode=0) WriteIniValues: File: xxx.ini, Section: INSTANCE, Key: SetupFolder, Value: Note that the value: is empty. And then at the very very end of the log file it states the properties: Property(C): SETUPFOLDER = \\rrdb\xxx\xxx\Setup So again it has the correct value but it does not want to use it when specifying the target of the shortcut. Hope this gives you some idea... Thankful for help! 2011/10/25 Rob Mensching r...@robmensching.com What does the verbose log file show? On Tue, Oct 25, 2011 at 8:10 AM, Leo Koivuniemi universalserial...@gmail.com wrote: Hello all, I am having some problems with an installation using Wix v3 During install of application I run Property Id=SETUPFOLDER RegistrySearch Id=SETUPFOLDER Root=HKCU Key=SOFTWARE\$(var.Company)\$(var.Product)\Common Name=SetupFolder Type=raw / /Property SETUPFOLDER is later used for setting the target of a shortcut in the start menu. This works when I install or reinstall by running my bootstrapper setup.exe which then starts the MSI package. But when applying patches for instance or bypassig the setup.exe and running the MSI directly, then the registry search returns C: or is just empty. When I check that path in registry using regedit then I do find the correct value there but for some reason the RegistrySearch fails and I can't figure out why. Notable is that this error does not exist in Windows XP, but now as I have been porting it to Windows 7 I noticed this problem. So basically the code should work, but it doesn't do that in Win7 (only works if I go through the bootstrapper exe) Any suggestions? Thanks! Leo -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Add/Remove Programs doesn't refresh sometimes
ARP/PF can and does list things that are not MSI products. Could some of those non-MSI products use an external API to perform the wholesale refresh? Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: john.burak [mailto:john.bu...@telvent.com] Sent: Tuesday, October 25, 2011 9:03 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Add/Remove Programs doesn't refresh sometimes Bob Arnson-6 wrote: Nope. ARP/PF doesn't do a wholesale refresh of the program list for MSI packages. When you click Uninstall and it succeeds, it just deletes that one entry. Okay. I wonder what the difference is between doing an uninstall via the usual method and doing an uninstall via Change Remove. I tried a few times and the first method triggers refresh and the second doesn't. It sounds like it's not on the MSI side of the wall, so I won't worry about it. Just makes me curios. Thanks, Bob :) - John -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/Add-Remove-Programs-doesn-t-refresh- sometimes-tp6918973p6929327.html Sent from the wix-users mailing list archive at Nabble.com. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Add/Remove Programs doesn't refresh sometimes
Edwin G. Castro wrote: ARP/PF can and does list things that are not MSI products. Could some of those non-MSI products use an external API to perform the wholesale refresh? That was the only guess I had. On closer inspection, I bet Notepad++ isn't using Windows Installer. I guess the question is, is it Windows Installer's fault for the inconsistency within my single MSI (one method of uninstall refreshes, another doesn't)? If so, I probably can't fix it per se. On the other hand, if it's something about the MSI file, then maybe I could. - John -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Add-Remove-Programs-doesn-t-refresh-sometimes-tp6918973p6929590.html Sent from the wix-users mailing list archive at Nabble.com. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Add/Remove Programs doesn't refresh sometimes
I can't think of anything I know about the MSI database schema that would change ARP/PF refresh. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: john.burak [mailto:john.bu...@telvent.com] Sent: Tuesday, October 25, 2011 10:06 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Add/Remove Programs doesn't refresh sometimes Edwin G. Castro wrote: ARP/PF can and does list things that are not MSI products. Could some of those non-MSI products use an external API to perform the wholesale refresh? That was the only guess I had. On closer inspection, I bet Notepad++ isn't using Windows Installer. I guess the question is, is it Windows Installer's fault for the inconsistency within my single MSI (one method of uninstall refreshes, another doesn't)? If so, I probably can't fix it per se. On the other hand, if it's something about the MSI file, then maybe I could. - John -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/Add-Remove-Programs-doesn-t-refresh- sometimes-tp6918973p6929590.html Sent from the wix-users mailing list archive at Nabble.com. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn UI
Is it possible to use the standard WiX authored MSI dialogs as the UI for Burn? Neil Neil Sleightholm X2 Systems Limited n...@x2systems.commailto:n...@x2systems.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat -generate
Bob Arnson-6 wrote: On 24-Oct-11 10:10, David L. Beckwith wrote: I was hoping output from heat payloadgroups and containers would help me understand how to create such an animal. Where do you suggest I look for clues on how to take a legacy install and containerize it? Maybe you could explain what containerize means...g Hopefully I'll use the correct terminology I'll try to describe what I would like to do and what steps I did to get there. Some of the documentation in Rob's blogs, etc. imply I can do what I want and some of what I've done leads me to believe it is possible. I just don't know how. Basically, I have a legacy install program that I would like chained. Specifically, it is Microsoft's Point of Service for dotNet. There is no ClickOnce install, instead it is delivered as a self extracting zip. It has a setup bootstapper with a scad full of files in different directories including an MSI. I'm under the impression I can create a container or payloadgroup that contains all these files. Once in a container, I can then include it in the chain and execute the setup. That is where heat came in. I wanted it to traverse the tree and give me a container with all the files. But only -generate component works (not container nor payloadgroup). If it did, I could probably figure it out from there. I want this payload to be external from the burn generated bootstrapper (i.e. not compressed) because it will only be installed once, but not for updates. I've been able to use burn and take the MSI and external files it needs to a payloadgroup and create a standalone bootstrapper. I can then add this into the chain (I have five other packages chained that work great). However, this introduces other issues (multiple UACs), another line item in the installed product list among other issues. I can also add it as a chain internal to the bootstrapper, but this doubles the size of my install for something that may not be needed. Thus, it is close to what I need. Suggestions? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-generate-tp6909632p6929758.html Sent from the wix-users mailing list archive at Nabble.com. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Starting WiX, when will 3.6 out of beta
Hi, Sorry if this is an FAQ, please send me a pointer. I want to introduce WiX in our company. As I read about WiX 3.6 and burn it looks like much more powerful as WiX 3.5. More interesting: I don't want to introduce a tools where the user interface will change after a short period of time when it has just convinced the other guys. Therefore I would like to know, when I can use WiX 3.6 in a production environment. Do I have to expect a lot of bugs and behavior changes? It's already worth to learn the new WiX 3.6 if I just want to install my VC++ and .NET programs or should I stay with 3.5? Kind regards, Andreas -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn UI
On 25/10/2011 18:47, Neil Sleightholm wrote: Is it possible to use the standard WiX authored MSI dialogs as the UI for Burn? I asked about this yesterday: the BA that comes with Burn has a toggle to show the MSI UI, but it will still show its own interface too. You'd need to write your own BA to do this. See the thread Burn: bootstrap a single MSI, not showing BA UI at all for Rob's answer :) -- Bruce Cran -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Action state not set during modify?
I'm got an installer working off a modified version of the Mondo UI (wix 3.5) that has three different features, and each feature has a custom dialog screen that gathers information on how to configure those features. When the installer is run in maintenance mode as a change/modify, I want the user to go from the feature tree page (where they modified which features to have installed) to the dialogs for every feature that will end up being installed. I'm having problems getting the conditions correct on the Customize dialog's Next button though. When doing a first time install, the condition only needs to be Feature1=3 for it to work (I've set it up so you can't install as advertised or from source, so I should only have to deal with 2 and 3 for action state). However it looks like action state doesn't getting set during modify - is this true? Taking a look at the log, I see this: MSI (c) (74:9C) [13:49:51:024]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedFeature property. Its current value is 'Feature1'. Its new value: 'Feature2'. MSI (c) (74:9C) [13:49:51:759]: Note: 1: 2727 2: MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedAction property. Its current value is '3'. Its new value: '2'. MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedCost property. Its current value is '0'. Its new value: '-976568'. That is from me running the installer to install Feature1 and Feature2, then running it again and deselecting Feature2 in the feature tree. Based on those lines from the log, it looks like it should know that Feature1's action state is set to 3...but I'm not seeing that behavior. When I have the condition just as Feature1=3, I hit next and nothing happens. There is also the Installed state value, but that alone won't help. If a feature is getting uninstalled (in which case !Feature1=3), it would work if I could also check to see if the feature wasn't being uninstalled (!Feature1=3 AND NOT Feature1=2), but that's not working either... I've been googling around and seen people reference Installed, MaintenanceMode=Modify, and WixUI_InstallMode = Change, but as far as I can tell those are all on the product level, not a feature level, which doesn't help. Is there some basic concept about install/action state that I'm missing? Or am I going about the modify logic all wrong? Thanks, Adam -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.6 beta and virus checker
From: r...@robmensching.com Date: Tue, 25 Oct 2011 08:26:40 -0700 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX 3.6 beta and virus checker Wow, that's a pretty aggressive virus checker. How do you install software that requires a reboot with that thing turned on? It's my work system so I don't have access to/can't change the policies it is using. I've installed loads of things in the past based on InstallShield, InnoSetup etc, and never seen this error message. I can't remember if any of them required a reboot but I have installed updates from Microsoft Update which did, and I had no problem. It may be that Trend has rules to allow certain 'well-known' bootstrappers to execute, or maybe none of them do the same registry access as you do. I'm guessing it's the function UpdateResumeMode in burn\engine\registration.cpp, do you agree? Can you open a bug with this information in it? I'm not exactly sure what we'll do about it but we should at least track the issue. Yes I will do when I'm back in work. I am a bit surprised nobody has seen this; I would have thought that there would be many other corporate users with Trend OfficeScan and a similar config. Pete -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Action state not set during modify?
They get set too late. At the earliest, CostFinalize, and some states are really good until InstallValidate. Your dialogs are occurring before that, more than likely. -- John Merryweather Cooper Jack Henry Associates, Inc. (Premier Tech) Build Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.com -Original Message- From: Adam Kadzban [mailto:mightyshorta...@gmail.com] Sent: Tuesday, October 25, 2011 2:26 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Action state not set during modify? I'm got an installer working off a modified version of the Mondo UI (wix 3.5) that has three different features, and each feature has a custom dialog screen that gathers information on how to configure those features. When the installer is run in maintenance mode as a change/modify, I want the user to go from the feature tree page (where they modified which features to have installed) to the dialogs for every feature that will end up being installed. I'm having problems getting the conditions correct on the Customize dialog's Next button though. When doing a first time install, the condition only needs to be Feature1=3 for it to work (I've set it up so you can't install as advertised or from source, so I should only have to deal with 2 and 3 for action state). However it looks like action state doesn't getting set during modify - is this true? Taking a look at the log, I see this: MSI (c) (74:9C) [13:49:51:024]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedFeature property. Its current value is 'Feature1'. Its new value: 'Feature2'. MSI (c) (74:9C) [13:49:51:759]: Note: 1: 2727 2: MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedAction property. Its current value is '3'. Its new value: '2'. MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedCost property. Its current value is '0'. Its new value: '-976568'. That is from me running the installer to install Feature1 and Feature2, then running it again and deselecting Feature2 in the feature tree. Based on those lines from the log, it looks like it should know that Feature1's action state is set to 3...but I'm not seeing that behavior. When I have the condition just as Feature1=3, I hit next and nothing happens. There is also the Installed state value, but that alone won't help. If a feature is getting uninstalled (in which case !Feature1=3), it would work if I could also check to see if the feature wasn't being uninstalled (!Feature1=3 AND NOT Feature1=2), but that's not working either... I've been googling around and seen people reference Installed, MaintenanceMode=Modify, and WixUI_InstallMode = Change, but as far as I can tell those are all on the product level, not a feature level, which doesn't help. Is there some basic concept about install/action state that I'm missing? Or am I going about the modify logic all wrong? Thanks, Adam -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Action state not set during modify?
Action state is supposed to be set during CostFinalize, which happens before my dialogs in the UI sequence (CostFinalize is 800, my dialogs start at 1296). Also, looking at the section of log I pasted in, I can see the MsiSelectionTreeSelectedAction property get set from 3 to 2 - that is setting the action state (ref: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371604(v=vs.85).aspx) though it appears to not actually be doing anything... -Adam On Tue, Oct 25, 2011 at 2:47 PM, John Cooper jocoo...@jackhenry.com wrote: They get set too late. At the earliest, CostFinalize, and some states are really good until InstallValidate. Your dialogs are occurring before that, more than likely. -- John Merryweather Cooper Jack Henry Associates, Inc. (Premier Tech) Build Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.com -Original Message- From: Adam Kadzban [mailto:mightyshorta...@gmail.com] Sent: Tuesday, October 25, 2011 2:26 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Action state not set during modify? I'm got an installer working off a modified version of the Mondo UI (wix 3.5) that has three different features, and each feature has a custom dialog screen that gathers information on how to configure those features. When the installer is run in maintenance mode as a change/modify, I want the user to go from the feature tree page (where they modified which features to have installed) to the dialogs for every feature that will end up being installed. I'm having problems getting the conditions correct on the Customize dialog's Next button though. When doing a first time install, the condition only needs to be Feature1=3 for it to work (I've set it up so you can't install as advertised or from source, so I should only have to deal with 2 and 3 for action state). However it looks like action state doesn't getting set during modify - is this true? Taking a look at the log, I see this: MSI (c) (74:9C) [13:49:51:024]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedFeature property. Its current value is 'Feature1'. Its new value: 'Feature2'. MSI (c) (74:9C) [13:49:51:759]: Note: 1: 2727 2: MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedAction property. Its current value is '3'. Its new value: '2'. MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedCost property. Its current value is '0'. Its new value: '-976568'. That is from me running the installer to install Feature1 and Feature2, then running it again and deselecting Feature2 in the feature tree. Based on those lines from the log, it looks like it should know that Feature1's action state is set to 3...but I'm not seeing that behavior. When I have the condition just as Feature1=3, I hit next and nothing happens. There is also the Installed state value, but that alone won't help. If a feature is getting uninstalled (in which case !Feature1=3), it would work if I could also check to see if the feature wasn't being uninstalled (!Feature1=3 AND NOT Feature1=2), but that's not working either... I've been googling around and seen people reference Installed, MaintenanceMode=Modify, and WixUI_InstallMode = Change, but as far as I can tell those are all on the product level, not a feature level, which doesn't help. Is there some basic concept about install/action state that I'm missing? Or am I going about the modify logic all wrong? Thanks, Adam -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
Re: [WiX-users] Action state not set during modify?
Well it appears you are right. I just put in a Publish element to show a popup if Feature1=-1, and it came up...so I don't understand why, but yes you are correct. Perhaps during maintenance it isn't set until CostFinalize of the Execute sequence? It works during the installation process, though, which confuses me. But given that, is there another way I can accomplish what I'm trying to do? -Adam On Tue, Oct 25, 2011 at 3:32 PM, Adam Kadzban mightyshorta...@gmail.comwrote: Action state is supposed to be set during CostFinalize, which happens before my dialogs in the UI sequence (CostFinalize is 800, my dialogs start at 1296). Also, looking at the section of log I pasted in, I can see the MsiSelectionTreeSelectedAction property get set from 3 to 2 - that is setting the action state (ref: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371604(v=vs.85).aspx) though it appears to not actually be doing anything... -Adam On Tue, Oct 25, 2011 at 2:47 PM, John Cooper jocoo...@jackhenry.comwrote: They get set too late. At the earliest, CostFinalize, and some states are really good until InstallValidate. Your dialogs are occurring before that, more than likely. -- John Merryweather Cooper Jack Henry Associates, Inc. (Premier Tech) Build Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.com -Original Message- From: Adam Kadzban [mailto:mightyshorta...@gmail.com] Sent: Tuesday, October 25, 2011 2:26 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Action state not set during modify? I'm got an installer working off a modified version of the Mondo UI (wix 3.5) that has three different features, and each feature has a custom dialog screen that gathers information on how to configure those features. When the installer is run in maintenance mode as a change/modify, I want the user to go from the feature tree page (where they modified which features to have installed) to the dialogs for every feature that will end up being installed. I'm having problems getting the conditions correct on the Customize dialog's Next button though. When doing a first time install, the condition only needs to be Feature1=3 for it to work (I've set it up so you can't install as advertised or from source, so I should only have to deal with 2 and 3 for action state). However it looks like action state doesn't getting set during modify - is this true? Taking a look at the log, I see this: MSI (c) (74:9C) [13:49:51:024]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedFeature property. Its current value is 'Feature1'. Its new value: 'Feature2'. MSI (c) (74:9C) [13:49:51:759]: Note: 1: 2727 2: MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedAction property. Its current value is '3'. Its new value: '2'. MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedCost property. Its current value is '0'. Its new value: '-976568'. That is from me running the installer to install Feature1 and Feature2, then running it again and deselecting Feature2 in the feature tree. Based on those lines from the log, it looks like it should know that Feature1's action state is set to 3...but I'm not seeing that behavior. When I have the condition just as Feature1=3, I hit next and nothing happens. There is also the Installed state value, but that alone won't help. If a feature is getting uninstalled (in which case !Feature1=3), it would work if I could also check to see if the feature wasn't being uninstalled (!Feature1=3 AND NOT Feature1=2), but that's not working either... I've been googling around and seen people reference Installed, MaintenanceMode=Modify, and WixUI_InstallMode = Change, but as far as I can tell those are all on the product level, not a feature level, which doesn't help. Is there some basic concept about install/action state that I'm missing? Or am I going about the modify logic all wrong? Thanks, Adam -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this
Re: [WiX-users] Burn UI
That isn't really what I meant, I was hoping to use the existing WiX authoring as the burn UI not just show the UI in my MSI but I think indirectly you have answered my question. I guess I was hoping for something for free, the current BA UI doesn't look very nice if the WIX install is anything to go by I as I don't really write UI's I was look for a free lunch! Neil -Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: 25 October 2011 19:26 To: General discussion for Windows Installer XML toolset. Cc: Neil Sleightholm Subject: Re: [WiX-users] Burn UI On 25/10/2011 18:47, Neil Sleightholm wrote: Is it possible to use the standard WiX authored MSI dialogs as the UI for Burn? I asked about this yesterday: the BA that comes with Burn has a toggle to show the MSI UI, but it will still show its own interface too. You'd need to write your own BA to do this. See the thread Burn: bootstrap a single MSI, not showing BA UI at all for Rob's answer :) -- Bruce Cran -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Action state not set during modify?
Well, the only approach that I have found to work consistently across all maintenance and install modes is to set properties concerning the states and features I'm interested in executed when the Next button of CustomizeDlg is pressed. I can rely on the values of these properties. I then condition further dialogs based on these properties. -- John M. Cooper -Original Message- From: Adam Kadzban [mailto:mightyshorta...@gmail.com] Sent: Tuesday, October 25, 2011 4:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Action state not set during modify? Well it appears you are right. I just put in a Publish element to show a popup if Feature1=-1, and it came up...so I don't understand why, but yes you are correct. Perhaps during maintenance it isn't set until CostFinalize of the Execute sequence? It works during the installation process, though, which confuses me. But given that, is there another way I can accomplish what I'm trying to do? -Adam On Tue, Oct 25, 2011 at 3:32 PM, Adam Kadzban mightyshorta...@gmail.comwrote: Action state is supposed to be set during CostFinalize, which happens before my dialogs in the UI sequence (CostFinalize is 800, my dialogs start at 1296). Also, looking at the section of log I pasted in, I can see the MsiSelectionTreeSelectedAction property get set from 3 to 2 - that is setting the action state (ref: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371604(v=vs. 85).aspx) though it appears to not actually be doing anything... -Adam On Tue, Oct 25, 2011 at 2:47 PM, John Cooper jocoo...@jackhenry.comwrote: They get set too late. At the earliest, CostFinalize, and some states are really good until InstallValidate. Your dialogs are occurring before that, more than likely. -- John Merryweather Cooper Jack Henry Associates, Inc. (Premier Tech) Build Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.com -Original Message- From: Adam Kadzban [mailto:mightyshorta...@gmail.com] Sent: Tuesday, October 25, 2011 2:26 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Action state not set during modify? I'm got an installer working off a modified version of the Mondo UI (wix 3.5) that has three different features, and each feature has a custom dialog screen that gathers information on how to configure those features. When the installer is run in maintenance mode as a change/modify, I want the user to go from the feature tree page (where they modified which features to have installed) to the dialogs for every feature that will end up being installed. I'm having problems getting the conditions correct on the Customize dialog's Next button though. When doing a first time install, the condition only needs to be Feature1=3 for it to work (I've set it up so you can't install as advertised or from source, so I should only have to deal with 2 and 3 for action state). However it looks like action state doesn't getting set during modify - is this true? Taking a look at the log, I see this: MSI (c) (74:9C) [13:49:51:024]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedFeature property. Its current value is 'Feature1'. Its new value: 'Feature2'. MSI (c) (74:9C) [13:49:51:759]: Note: 1: 2727 2: MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedAction property. Its current value is '3'. Its new value: '2'. MSI (c) (74:9C) [13:49:51:774]: PROPERTY CHANGE: Modifying MsiSelectionTreeSelectedCost property. Its current value is '0'. Its new value: '-976568'. That is from me running the installer to install Feature1 and Feature2, then running it again and deselecting Feature2 in the feature tree. Based on those lines from the log, it looks like it should know that Feature1's action state is set to 3...but I'm not seeing that behavior. When I have the condition just as Feature1=3, I hit next and nothing happens. There is also the Installed state value, but that alone won't help. If a feature is getting uninstalled (in which case !Feature1=3), it would work if I could also check to see if the feature wasn't being uninstalled (!Feature1=3 AND NOT Feature1=2), but that's not working either... I've been googling around and seen people reference Installed, MaintenanceMode=Modify, and WixUI_InstallMode = Change, but as far as I can tell those are all on the product level, not a feature level, which doesn't help. Is there some basic concept about install/action state that I'm missing? Or am I going about the modify logic all wrong? Thanks, Adam - - The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn
Re: [WiX-users] Burn UI
I use a customize version of the setup.exe from 3.5 RTM. Much less functionality than Burn, but it works and I get caching which is mainly what I was after. -- John M. Cooper -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Tuesday, October 25, 2011 4:13 PM To: Bruce Cran; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn UI That isn't really what I meant, I was hoping to use the existing WiX authoring as the burn UI not just show the UI in my MSI but I think indirectly you have answered my question. I guess I was hoping for something for free, the current BA UI doesn't look very nice if the WIX install is anything to go by I as I don't really write UI's I was look for a free lunch! Neil -Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: 25 October 2011 19:26 To: General discussion for Windows Installer XML toolset. Cc: Neil Sleightholm Subject: Re: [WiX-users] Burn UI On 25/10/2011 18:47, Neil Sleightholm wrote: Is it possible to use the standard WiX authored MSI dialogs as the UI for Burn? I asked about this yesterday: the BA that comes with Burn has a toggle to show the MSI UI, but it will still show its own interface too. You'd need to write your own BA to do this. See the thread Burn: bootstrap a single MSI, not showing BA UI at all for Rob's answer :) -- Bruce Cran -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn UI
On 25/10/2011 22:12, Neil Sleightholm wrote: I guess I was hoping for something for free, the current BA UI doesn't look very nice if the WIX install is anything to go by I as I don't really write UI's I was look for a free lunch! Actually, the UI in the WiX installer is especially ugly - the UI that developers get via Burn is much nicer (without the RSS feed, a different layout etc.), if incomplete in places. For example there's no explanation that a reboot is required at the end, just Reboot and Close buttons. -- Bruce Cran -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to display the list of features to be installed
Hi Peter, Thank you for responding to my question. I have a few more specific questions for you. 1. For first time install, if I want to determine if a feature is selected for installation in a custom action, what is the best way to do the work? Should I use the ADDLOCAL value or MsiGetFeatureState? 2. In maintenance mode, what has been installed by the first time install will not be in the ADDLOCAL value, correct? If this true, how can we get the whole list of features that will be installed after the Modify install? 3. Is MsiSetFeatureState the best way to set feature install state in a custom action, or should I directly set the value of ADDLOCAL? Thanks a lot, Miaohsi -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 25, 2011 1:31 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to display the list of features to be installed The first 4 properties under Feature Installation Options Properties would be the place to start. http://msdn.microsoft.com/en-us/library/aa370905%28VS.85%29.aspx#feature_inst allation_options_properties -Original Message- From: Wang, Miaohsi [mailto:miaohsi.w...@invensys.com] Sent: 24 October 2011 19:07 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to display the list of features to be installed Dear All, We would like to display before entering the Execute sequence the list of features that the user selects to install, but do not know what the best approach would be. Specifically, the implementation involves getting the feature install status and organizing the features to install into a list. If you have any idea, please let us know. Thanks a lot, Miaohsi *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). - - The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users 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. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc,
Re: [WiX-users] Heat -generate
On 25-Oct-11 13:51, David L. Beckwith wrote: Basically, I have a legacy install program that I would like chained. Specifically, it is Microsoft's Point of Service for dotNet. There is no ClickOnce install, instead it is delivered as a self extracting zip. It has a setup bootstapper with a scad full of files in different directories including an MSI. I'm under the impression I can create a container or payloadgroup that contains all these files. You want a package group (which contains the MSI and payload files). If you want, you can include the package group in a container (a single file that contains all the packages/payloads). But containers are just a delivery mechanism; they're not involved in how a package is installed. That is where heat came in. I don't think Heat has been updated to harvest files for a bundle. But it's not clear to me that you need it. The WiX binder will automatically harvest the loose files that an .msi refers to. So try a PackageGroup with an MsiPackage child that points to the POS .msi. Use PackageGroupRef in your Chain to include the package in the chain. If you want a container, use PackageGroupRef to include the POS package group into the container. -- sig://boB http://joyofsetup.com/ -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Add/Remove Programs doesn't refresh sometimes
On 25-Oct-11 12:03, john.burak wrote: Okay. I wonder what the difference is between doing an uninstall via the usual method and doing an uninstall via Change Remove. ARP is in charge: You click Uninstall and if it gets a success code, it refreshes. Otherwise, it does nothing. It doesn't know that the user uninstalled from maintenance mode. From its perspective, the user clicked Change, so there's no reason to refresh the list. -- sig://boB http://joyofsetup.com/ -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn UI
On 25-Oct-11 17:12, Neil Sleightholm wrote: That isn't really what I meant, I was hoping to use the existing WiX authoring as the burn UI As in: 1. You want Burn to understand MSI UI? 2. You want Burn to mimic the WixUI dialog sets? (Neither will happen in v3.6.g Just curious.) -- sig://boB http://joyofsetup.com/ -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
