[WiX-users] Different behaviour of executable created using setupbld.exe
I created a executable of my msi using setupbld.exe and setup.exe stub tool of wix 3.0. I installed the executable created, everything worked fine. but when i double click the exe again (after the installation)it shows me resume dialogbox with 'back' button(disabled), install button, cancel button. but if double click an installed msi, it shows me MaintenanceWelcomeDlg as expected. Why am i getting two different behaviour? What is going wrong in here? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Different-behaviour-of-executable-created-using-setupbld-exe-tp5203373p5203373.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] This 32BitComponent uses 64BitDirectory issue
Hello, I am getting errors when building the same wix scripts for 64 bit which builds fine for 32 bit: D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent RegistryValues uses 64BitDirectory INSTALLDIR D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent EulaPdf uses 64BitDirectory INSTALLDIR D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent uplevel.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory payload_ul.9BAE13A2_E7AF_D6C3_FF 1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent downlevel_payload.8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory payload. 8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent downlevel_manifest.8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory WinSxsM anifests.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent nosxs.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory SystemFolder.9BAE13A2_E7AF_D6C3_FF 1F_C8B3B9A1E18E And here are my command parameters: D:\src\clean\src\bsitools\winnt\wix\3.0.2925.0\candle.exe -nologo -sw1086 -sw1088 -arch=x64 -dINSTALLER_PRODUCT_VERSION=09.99.56.789 -dDIRECTORY_PROGFILES=ProgramFiles64Folder -dDIRECTORY_COMMFIL ES=CommonFiles64Folder -dTARGET_PROCESSOR_DIRECTORY=Winx64 -dPACKAGE_TARGETPLATFORM=x64 -dCOMPONENT_WIN64=yes -dINSTALLER_FILE_BASE=D:\src\clean\out\ABC\Winx64\delivery\bin\ %(INSTALLER_SOURCE_LIST.Identity) -out D:\src\clea n\out\ABC\Winx64\build\BCEV\ Ignoring this error is not an option even though it builds the msi file. How can I fix this? Thanks, Ahmad Luqman -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to add a warning dialog?
Hi, I have to check for the presence of a product. If the product is absent I need to use a warning msg and then continue the installation without exiting. what I have done is using upgrade code I'm detecting if the product is present and am setting a property based on that. later I show a dialog box by using condition on that property. Now the problem I'm having is I need to provide something as publish item for the ok button of the warning dialog. I am not sure what is that I use there to make it a do nothing action? Regards, Bijay Agarwal -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] This 32BitComponent uses 64BitDirectory issue
Hi Ahmad, You are using a folder that's for 64 bits files and are installing files that are marked as 32 bits. You can fix this by either using a 32 bits folder, or change the component to 64 bits. Cheers, Jeffrey Bindinga Software Developer at CyberTech International -Original Message- From: Ahmad Luqman [mailto:ahmad.luq...@gmail.com] Sent: maandag 21 juni 2010 11:33 To: wix-users@lists.sourceforge.net Subject: [WiX-users] This 32BitComponent uses 64BitDirectory issue Hello, I am getting errors when building the same wix scripts for 64 bit which builds fine for 32 bit: D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent RegistryValues uses 64BitDirectory INSTALLDIR D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent EulaPdf uses 64BitDirectory INSTALLDIR D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent uplevel.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory payload_ul.9BAE13A2_E7AF_D6C3_FF 1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent downlevel_payload.8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory payload. 8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent downlevel_manifest.8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory WinSxsM anifests.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent nosxs.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory SystemFolder.9BAE13A2_E7AF_D6C3_FF 1F_C8B3B9A1E18E And here are my command parameters: D:\src\clean\src\bsitools\winnt\wix\3.0.2925.0\candle.exe -nologo -sw1086 -sw1088 -arch=x64 -dINSTALLER_PRODUCT_VERSION=09.99.56.789 -dDIRECTORY_PROGFILES=ProgramFiles64Folder -dDIRECTORY_COMMFIL ES=CommonFiles64Folder -dTARGET_PROCESSOR_DIRECTORY=Winx64 -dPACKAGE_TARGETPLATFORM=x64 -dCOMPONENT_WIN64=yes -dINSTALLER_FILE_BASE=D:\src\clean\out\ABC\Winx64\delivery\bin\ %(INSTALLER_SOURCE_LIST.Identity) -out D:\src\clea n\out\ABC\Winx64\build\BCEV\ Ignoring this error is not an option even though it builds the msi file. How can I fix this? Thanks, Ahmad Luqman -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users CyberTech B.V. is registered in The Netherlands, Alkmaar KvK 37.05.01.69 This message is intended for the addressee only. Unless clearly stated that this disclaimer should not apply, the email is not intended to create legally binding commitments on behalf of CyberTech B.V.. Any unauthorised disclosure, use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient of the message, please notify the sender immediately. CyberTech B.V. email system is for business purposes only. Messages are not confidential. All email may be reviewed by authorised personnel. CyberTech B.V. would kindly ask that you consider the environment before printing this mail -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to add a warning dialog?
Hi Bijay, You can use the SpawnDialog event to show a modal dialog, add a condition to this action to show it conditionally. In the warning dialog you can add the EndDialog event to the ok button to close the dialog. Regards, Jeffrey Bindinga Software Developer at CyberTech International. -Original Message- From: Bijay Agarwal [mailto:agarw...@vmware.com] Sent: maandag 21 juni 2010 11:37 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to add a warning dialog? Hi, I have to check for the presence of a product. If the product is absent I need to use a warning msg and then continue the installation without exiting. what I have done is using upgrade code I'm detecting if the product is present and am setting a property based on that. later I show a dialog box by using condition on that property. Now the problem I'm having is I need to provide something as publish item for the ok button of the warning dialog. I am not sure what is that I use there to make it a do nothing action? Regards, Bijay Agarwal -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users CyberTech B.V. is registered in The Netherlands, Alkmaar KvK 37.05.01.69 This message is intended for the addressee only. Unless clearly stated that this disclaimer should not apply, the email is not intended to create legally binding commitments on behalf of CyberTech B.V.. Any unauthorised disclosure, use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient of the message, please notify the sender immediately. CyberTech B.V. email system is for business purposes only. Messages are not confidential. All email may be reviewed by authorised personnel. CyberTech B.V. would kindly ask that you consider the environment before printing this mail -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] This 32BitComponent uses 64BitDirectory issue
You're trying to put Components marked as 32-bit into 64-bit only locations. For RegistryValues and EulaPdf I'm guessing all you need to do is remove the Win64=no attribute. For the Visual C++ 8.0 Merge Modules, simply put them under TARGETDIR (see - http://wix.sourceforge.net/manual-wix3/install_vcredist.htm) instead. Also you're distributing *very* old versions of the VC++ redist. So old it's probably not even necessary as users are going to have the v8.0.50727.4053 ones which were released almost a year ago. You might want to update your machine with the ATL Security fix update for Visual Studio 2005 (see - http://www.microsoft.com/technet/security/bulletin/ms09-035.mspx). Palbinder Sandher Software Deployment IT Administrator 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: Ahmad Luqman [mailto:ahmad.luq...@gmail.com] Sent: 21 June 2010 10:33 To: wix-users@lists.sourceforge.net Subject: [WiX-users] This 32BitComponent uses 64BitDirectory issue Hello, I am getting errors when building the same wix scripts for 64 bit which builds fine for 32 bit: D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent RegistryValues uses 64BitDirectory INSTALLDIR D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent EulaPdf uses 64BitDirectory INSTALLDIR D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent uplevel.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory payload_ul.9BAE13A2_E7AF_D6C3_FF 1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent downlevel_payload.8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory payload. 8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent downlevel_manifest.8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory WinSxsM anifests.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E D:\src\clean\out\ABC\Winx64\delivery\install\ECCE\BCEV.msi : error SMOK0204 : ICE80: This 32BitComponent nosxs.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E uses 64BitDirectory SystemFolder.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E And here are my command parameters: D:\src\clean\src\bsitools\winnt\wix\3.0.2925.0\candle.exe -nologo -sw1086 -sw1088 -arch=x64 -dINSTALLER_PRODUCT_VERSION=09.99.56.789 -dDIRECTORY_PROGFILES=ProgramFiles64Folder -dDIRECTORY_COMMFIL ES=CommonFiles64Folder -dTARGET_PROCESSOR_DIRECTORY=Winx64 -dPACKAGE_TARGETPLATFORM=x64 -dCOMPONENT_WIN64=yes -dINSTALLER_FILE_BASE=D:\src\clean\out\ABC\Winx64\delivery\bin\ %(INSTALLER_SOURCE_LIST.Identity) -out D:\src\clea n\out\ABC\Winx64\build\BCEV\ Ignoring this error is not an option even though it builds the msi file. How can I fix this? Thanks, Ahmad Luqman -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Unresolved reference to symbol 'Directory:ProgramMenuDir' in section 'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'
Hi there,
I'm getting started with WiX and I want to create just some simple icons on the
desktop and the startmenu but I'm getting:
Error 1 Unresolved reference to symbol 'Directory:ProgramMenuDir' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 2 Unresolved reference to symbol 'Icon:Test.exe' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 3 Unresolved reference to symbol 'Directory:DesktopFolder' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 4 Unresolved reference to symbol 'Icon:Test.exe' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
My .wxs files looks like this:
Directory Id=TARGETDIR Name=SourceDir
Directory Id='ProgramFilesFolder' Name='PFiles'
Directory Id=Firma Name=Test
Directory Id=App Name=Test
Directory Id=Server Name=Test
Directory Id=INSTALLLOCATION Name=19
Component Id=MainExecutable
Guid=0257BFC2-D661-4C24-9F1B-8B8E24F4A8FB
File Id=Testexe Name=Test.exe DiskId=1
Source=Test.exe KeyPath=yes
Shortcut Id=startmenuTestTest19
Directory=ProgramMenuDir Name=Test - Test - 19
WorkingDirectory='INSTALLLOCATION' Icon=Test.exe
IconIndex=0 Advertise=yes /
Shortcut Id=desktopTestTest19 Directory=DesktopFolder
Name=Test - Test - 19
WorkingDirectory='INSTALLLOCATION' Icon=Test.exe
IconIndex=0 Advertise=yes /
/File
/Component
/Directory
/Directory
/Directory
/Directory
/Directory
/Directory
What am I doing wrong?
Kind regards,
J. Hetzer
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unresolved reference to symbol 'Directory:ProgramMenuDir' in section 'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'
Hello,
Error 1: You mention Directory Id='ProgramFilesFolder' Name='PFiles' where
PFiles is the name of the link to the programfiles folder, further, you mention
Directory=ProgramMenuDir. Replace the last with the first and you're done.
Error 2: You have to include a reference to the icon itself (it is not native).
Add this statement afte the last /directory line : Icon Id=Test.exe
SourceFile=$(var.yourpath)\yourexe.exe / where yourpath and yourexe
are to be replaced by the data of your executable file (source folder!)
Error 3: You need to add Directory Id=DesktopFolder Name=Desktop / to
the directory list
Error 4 : similar to error 2
HTH,
Tim
- Originele e-mail -
Van: Johannes Hetzer johannes.het...@eckd.de
Aan: wix-users@lists.sourceforge.net
Verzonden: Maandag 21 juni 2010 12:58:40 GMT +01:00 Amsterdam / Berlijn / Bern
/ Rome / Stockholm / Wenen
Onderwerp: [WiX-users] Unresolved reference to symbol
'Directory:ProgramMenuDir' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'
Hi there,
I'm getting started with WiX and I want to create just some simple icons on the
desktop and the startmenu but I'm getting:
Error 1 Unresolved reference to symbol 'Directory:ProgramMenuDir' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 2 Unresolved reference to symbol 'Icon:Test.exe' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 3 Unresolved reference to symbol 'Directory:DesktopFolder' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 4 Unresolved reference to symbol 'Icon:Test.exe' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
My .wxs files looks like this:
Directory Id=TARGETDIR Name=SourceDir
Directory Id='ProgramFilesFolder' Name='PFiles'
Directory Id=Firma Name=Test
Directory Id=App Name=Test
Directory Id=Server Name=Test
Directory Id=INSTALLLOCATION Name=19
Component Id=MainExecutable
Guid=0257BFC2-D661-4C24-9F1B-8B8E24F4A8FB
File Id=Testexe Name=Test.exe DiskId=1
Source=Test.exe KeyPath=yes
Shortcut Id=startmenuTestTest19
Directory=ProgramMenuDir Name=Test - Test - 19
WorkingDirectory='INSTALLLOCATION' Icon=Test.exe
IconIndex=0 Advertise=yes /
Shortcut Id=desktopTestTest19 Directory=DesktopFolder
Name=Test - Test - 19
WorkingDirectory='INSTALLLOCATION' Icon=Test.exe
IconIndex=0 Advertise=yes /
/File
/Component
/Directory
/Directory
/Directory
/Directory
/Directory
/Directory
What am I doing wrong?
Kind regards,
J. Hetzer
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Different behaviour of executable created usingsetupbld.exe
Setup.exe is running your MSI with some parameters which double clicking the MSI itself isn't (sounds like it's trying to do either Repair or Reinstall by default). Find out what they are then find out how to remove them. Palbinder Sandher Software Deployment IT Administrator 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: Sagar [mailto:sagarkavitak...@gmail.com] Sent: 21 June 2010 09:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Different behaviour of executable created usingsetupbld.exe I created a executable of my msi using setupbld.exe and setup.exe stub tool of wix 3.0. I installed the executable created, everything worked fine. but when i double click the exe again (after the installation)it shows me resume dialogbox with 'back' button(disabled), install button, cancel button. but if double click an installed msi, it shows me MaintenanceWelcomeDlg as expected. Why am i getting two different behaviour? What is going wrong in here? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Different- behaviour-of-executable-created-using-setupbld-exe-tp5203373p5203373.htm l Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unresolved reference to symbol'Directory:ProgramMenuDir' in section'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'
Error 1 - Author a ProgramMenuDir. You can't link to something which
doesn't exist. See -
http://wix.sourceforge.net/manual-wix3/create_start_menu_shortcut.htm
Error 2 - Author an Icon Element. You can't link to something which
doesn't exist. See -
http://wix.sourceforge.net/manual-wix3/wix_xsd_icon.htm
Error 3 - Add a reference to the DesktopFolder Property. You can't link
to something which doesn't exist. See -
http://msdn.microsoft.com/en-us/library/aa368276.aspx
Error 4 - See Error 3 above.
Palbinder Sandher
Software Deployment IT Administrator
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: Johannes Hetzer [mailto:johannes.het...@eckd.de]
Sent: 21 June 2010 11:59
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Unresolved reference to
symbol'Directory:ProgramMenuDir' in
section'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'
Hi there,
I'm getting started with WiX and I want to create just some simple icons
on the desktop and the startmenu but I'm getting:
Error 1 Unresolved reference to symbol 'Directory:ProgramMenuDir' in
section 'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 2 Unresolved reference to symbol 'Icon:Test.exe' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 3 Unresolved reference to symbol 'Directory:DesktopFolder' in
section 'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
Error 4 Unresolved reference to symbol 'Icon:Test.exe' in section
'Product:{21303116-42B5-4428-9ED1-A20CDBDE2168}'.
My .wxs files looks like this:
Directory Id=TARGETDIR Name=SourceDir
Directory Id='ProgramFilesFolder' Name='PFiles'
Directory Id=Firma Name=Test
Directory Id=App Name=Test
Directory Id=Server Name=Test
Directory Id=INSTALLLOCATION Name=19
Component Id=MainExecutable
Guid=0257BFC2-D661-4C24-9F1B-8B8E24F4A8FB
File Id=Testexe Name=Test.exe DiskId=1
Source=Test.exe KeyPath=yes
Shortcut Id=startmenuTestTest19
Directory=ProgramMenuDir Name=Test - Test - 19
WorkingDirectory='INSTALLLOCATION' Icon=Test.exe
IconIndex=0 Advertise=yes /
Shortcut Id=desktopTestTest19
Directory=DesktopFolder Name=Test - Test - 19
WorkingDirectory='INSTALLLOCATION' Icon=Test.exe
IconIndex=0 Advertise=yes /
/File
/Component
/Directory
/Directory
/Directory
/Directory
/Directory
/Directory
What am I doing wrong?
Kind regards,
J. Hetzer
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's
Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the
prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Customizing WixUI_FeatureTree
Hi, WixUI_FeatureTree is almost exactly what I need. I just want to change 2 things: 1) Add a Readme.rtf file at the end of the install. This can either be in a dialog similar to EULA (that's what Visual Studio setup projects do), or a checkbox to execute the RTF when the installer closes. Given the choice between the two I would prefer the first option (embed the Readme text in a dialog). 2) Currently when I upgrade from one version to the next I get a popup from the Restart Manager asking to restart the programs that use my DLL. That's good. But during uninstall I only get a simple message box saying Some files are in use, you should reboot afterwards. I want to use the Restart Manager in all cases (even during Change when the offending feature is being uninstalled). What is the easiest way to do what I need? Thanks Ivo -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing WixUI_FeatureTree
1 - http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html However from looking at the sources WiXUI_FeatureTree already has LicenseAgreementDlg after the WelcomeDlg. If you want a second one showing a different RTF you'll need to write it (or copy paste from the LicenseAgreementDlg.wxs in the WiX sources). 2 - No idea. Never used Restart Manager as it's only supported in Windows Installer 4.0 and later. Are you using Util:CloseApplication (http://wix.sourceforge.net/manual-wix3/util_xsd_closeapplication.htm) or relying on Windows Installer alone? Palbinder Sandher Software Deployment IT Administrator 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: Ivo Beltchev [mailto:i...@roadrunner.com] Sent: 21 June 2010 14:48 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Customizing WixUI_FeatureTree Hi, WixUI_FeatureTree is almost exactly what I need. I just want to change 2 things: 1) Add a Readme.rtf file at the end of the install. This can either be in a dialog similar to EULA (that's what Visual Studio setup projects do), or a checkbox to execute the RTF when the installer closes. Given the choice between the two I would prefer the first option (embed the Readme text in a dialog). 2) Currently when I upgrade from one version to the next I get a popup from the Restart Manager asking to restart the programs that use my DLL. That's good. But during uninstall I only get a simple message box saying Some files are in use, you should reboot afterwards. I want to use the Restart Manager in all cases (even during Change when the offending feature is being uninstalled). What is the easiest way to do what I need? Thanks Ivo -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deferred custom action Impersonation.
Personally we're using VMWare ESXi 4.0 for my QA teams my own testing purposes. It really is pretty damn good. Hyper-V Server is Microsoft's response to VMWare making ESXi free. Any machine you can run Hyper-V Server on you can run ESXi on from my experience it's a much better choice overall. I'm not (never have been and never will be) one of those people who hate Microsoft products just because they're made by Microsoft but VMWare do virtualization very well so it's hard to recommend Hyper-V Server over ESXi. ESXi 4.0 supports version 7 VM's so you can move from VMWare Server to ESXi without too much fuss plus it supports thin disks natively (something I really missed from Virtual PC when moving to VMWare Server/ESXi 3.5) with a simple checkbox in the disk options now. Palbinder Sandher Software Deployment IT Administrator 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: Blair [mailto:os...@live.com] Sent: 18 June 2010 19:59 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Deferred custom action Impersonation. Microsoft Hyper-V Server 2008 R2 is free to download and use, if you don't have a Server 2008 license available. It requires an x64 box with certain CPUs that support hardware virtualization. -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Friday, June 18, 2010 11:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deferred custom action Impersonation. To Bob's list (which is a little out of date) I'll add that Server 2008 also has Hypervisor, Microsoft's newer VM technology. If you can get an x64 Server 2008 box you can have x64 and x86 VMs. VMs really are the best way to test setups when you can do your tests and then revert to an untarnished image. Phil Wilson -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Friday, June 18, 2010 3:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deferred custom action Impersonation. http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ Palbinder Sandher Software Deployment IT Administrator 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: Sagar [mailto:sagarkavitak...@gmail.com] Sent: 18 June 2010 08:11 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Deferred custom action Impersonation. if i have a deferr=red custom action with Impersonate=yes. then on Windows Vista with UAC enabled i get a prompt asking if the user wishes the allow the program to access your computer. now if the user presses allow in UAC prompt. Will my custom action be able to connect to SQL server on another machine using windows authentication. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deferred-c ustom-action-Impersonation-tp5191516p5194260.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ 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
Re: [WiX-users] Customizing WixUI_FeatureTree
2) Currently when I upgrade from one version to the next I get a popup from the Restart Manager asking to restart the programs that use my DLL. That's good. But during uninstall I only get a simple message box saying Some files are in use, you should reboot afterwards. I want to use the Restart Manager in all cases (even during Change when the offending feature is being uninstalled). 2 - No idea. Never used Restart Manager as it's only supported in Windows Installer 4.0 and later. Are you using Util:CloseApplication (http://wix.sourceforge.net/manual-wix3/util_xsd_closeapplication.htm) or relying on Windows Installer alone? I don't use Util:CloseApplication. The package is a shell extension, so the processes that need to be restarted are Explorer.exe and any other process that loads the shell extension. I think I have an idea what's happening: It says here (http://msdn.microsoft.com/en-us/library/aa370379.aspx) that the MsiRMFilesInUse dialog only shows up if The Full UI user interface level is used.. When uninstalling from the Control Panel the interface level is basic or reduced. Is there a way around that limitation? Like force full UI when running from the Control Panel? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing WixUI_FeatureTree
Not if you use the Windows Installer integration with ARP. You would have to use the Legacy ARP interface, which requires using the ARPSYSTEMCOMPONENT property AND programming the uninstall registry key yourself. This has been discussed on this list before. However, I don't believe that is what is happening. From this page: http://msdn.microsoft.com/library/aa372466.aspx: Basic UI or Reduced UI level installations give the user the option of using the Restart Manager to reduce system restarts even if the MsiRMFilesInUse dialog box is not present. Silent UI level installations always shut down applications and services, and on Windows Vista, always use Restart Manager. From my previous interactions with Windows Installer, if a file isn't replaced, Windows Installer doesn't bother with requesting a reboot (it just moves the files it couldn't delete to a hidden directory and marks them to be deleted on the next system boot). Thus, it may not be engaging RM to stop/restart a process that is holding onto a file it doesn't feel requires a reboot. CloseApplication may do the job you need. If it doesn't, either it should be extended to join processes to the RM session, or another CA would need to be used for that task. Alternately, if you add an embedded UI you could add any processes holding files found to be in use to the RM session yourself right from the embedded UI (which ironically doesn't have to show any UI at all, and can be run no matter what UI level is in play). Of course, embedded UI requires MSI 4.5 or higher, which not everyone has (The latest Service Pack for both Vista and 2008 have 4.5, but XP SP3 doesn't, although 4.5 is available for XP. However, XP doesn't have Restart Manager, so that may be a moot point). -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Monday, June 21, 2010 11:34 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Customizing WixUI_FeatureTree 2) Currently when I upgrade from one version to the next I get a popup from the Restart Manager asking to restart the programs that use my DLL. That's good. But during uninstall I only get a simple message box saying Some files are in use, you should reboot afterwards. I want to use the Restart Manager in all cases (even during Change when the offending feature is being uninstalled). 2 - No idea. Never used Restart Manager as it's only supported in Windows Installer 4.0 and later. Are you using Util:CloseApplication (http://wix.sourceforge.net/manual-wix3/util_xsd_closeapplication.htm) or relying on Windows Installer alone? I don't use Util:CloseApplication. The package is a shell extension, so the processes that need to be restarted are Explorer.exe and any other process that loads the shell extension. I think I have an idea what's happening: It says here (http://msdn.microsoft.com/en-us/library/aa370379.aspx) that the MsiRMFilesInUse dialog only shows up if The Full UI user interface level is used.. When uninstalling from the Control Panel the interface level is basic or reduced. Is there a way around that limitation? Like force full UI when running from the Control Panel? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Set package name dynamically
The ARPSYSTEMCOMPONENT route seems treacherous. Can't I just modify the
summary information on the cached msi in c:\windows\installer? The code
signing signature doesn't work from add/remove programs anyway, due to MSKB
929467. The trick here would be to find out when the cached msi is written,
and what the filename is. Then I could use MsiSummaryInfoSetProperty just on
the cached file, yes?
Matt Johnson MCPD, MCTS, MCSD, MCDBA
Director of Application Development
Time America, Inc.
ma...@timeamerica.com | www.timeamerica.com
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Friday, June 18, 2010 9:34 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Set package name dynamically
The summary information stream is MSI metadata outside of the MSI SQL
database (but inside of the MSI file) and uses a different set of APIs to
access than the rest of the data in the file. Changing it would have to
occur before you start an installation transaction, and if you codesign your
MSIs to prove to your customers that no tampering has occurred, changing the
summary info stream will invalidate your signature (the system will treat it
as if it had never been signed, including the scarier UAC-related prompt
used with unsigned files vs. the one used with signed files).
The data in the registry related to display in ARP is used only for legacy
installations (those that are non-MSI based). The only way to, at runtime,
change that data is to use the ARPSYSTEMCOMPONENT property and then write an
entirely new legacy registry entry for ARP. However, there are downsides
to that: for one - you lose the Repair button in ARP.
A discussion on using that property, including some dangers and some
mitigations, can be found by checking the posts on this page:
http://blogs.msdn.com/b/heaths/archive/tags/arpsystemcomponent/. I recommend
reading the blogs in the order they were written, which would mean oldest
first (bottom of page?).
-Original Message-
From: Matt Johnson [mailto:ma...@timeamerica.com]
Sent: Friday, June 18, 2010 5:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Set package name dynamically
Is there any way to set the packa...@description property dynamically? It
does seem to accept bracket-style properties, but it only uses the values
that those properties are initialized to on startup. If I change the value
during install, I still get the original value displayed in Add/Remove
Programs.
Basically, my application is cobranded with different names and I'm building
a generic installer. I read the brand name from a license key in a custom
action before the first UI dialog. I use that to decide what to set the
ProductName property to and what graphics to load in to the UI.
It works great, except I can't get the name in add/remove programs updated.
I tried changing the
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{guid}\DisplayName
value, but it seems to have no effect.
The docs say that that packa...@description ends up in the summary
information stream. Is there a way to write to the summary information
stream dynamically at runtime? Or is this hardcoded into the MSI? Perhaps
there's a way to write to the cached MSI that Add/Remove programs is looking
at? I'm not sure where it's cached to. Please help.
Thanks,
Matt Johnson MCPD, MCTS, MCSD, MCDBA
Director of Application Development
Time America, Inc.
ma...@timeamerica.commailto:ma...@timeamerica.com |
www.timeamerica.comhttp://www.timeamerica.com/
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing WixUI_FeatureTree
Basic UI or Reduced UI level installations give the user the option of using the Restart Manager to reduce system restarts even if the MsiRMFilesInUse dialog box is not present. Silent UI level installations always shut down applications and services, and on Windows Vista, always use Restart Manager. From my previous interactions with Windows Installer, if a file isn't replaced, Windows Installer doesn't bother with requesting a reboot (it just moves the files it couldn't delete to a hidden directory and marks them to be deleted on the next system boot). Thus, it may not be engaging RM to stop/restart a process that is holding onto a file it doesn't feel requires a reboot. I see, that may explain what's happening. It is still a problem though, because the component in question needs other files to function correctly, and they get deleted during uninstall. A specific example: The component is a toolbar for Explorer. It gets its configuration (what buttons to show) from an ini file. Once the ini file is uninstalled, the toolbar will revert to the default buttons, which (while not critical) is not nice. Same goes for the localization files. Without them the toolbar reverts to English when they are gone. CloseApplication may do the job you need. If it doesn't, either it should be extended to join processes to the RM session, or another CA would need to be used for that task. Correct me if I'm wrong, but CloseApplication is specifically for EXEs that are part of the package, right? I don't know in advance what EXEs will load my DLL. Alternately, if you add an embedded UI you could add any processes holding files found to be in use to the RM session yourself right from the embedded UI (which ironically doesn't have to show any UI at all, and can be run no matter what UI level is in play). Of course, embedded UI requires MSI 4.5 or higher, which not everyone has (The latest Service Pack for both Vista and 2008 have 4.5, but XP SP3 doesn't, although 4.5 is available for XP. However, XP doesn't have Restart Manager, so that may be a moot point). I'm not sure I understand, but are you suggesting I re-implement the Restart Manager? (locate all processes that use the DLL, then show a list to the user, or try to restart them). BTW, I am targeting Vista and up, and I don't mind if the uninstaller does its best on SP2, as long as it works somehow on lower service packs. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom Action execution by feature
Hi ALL, I wrote a custom action to create a scheduled task after install. I do not want the Custom Action to run when the user does not want to create the schedule task. During installation even if I select Feature will be unAvailable the schtask is getting created. How do i prevent the Custom Action from executing? Feature Id=SWUSchedTaskFeature Title=Create a scheduled task Level=5 Absent=allow Description=Creates and configures Scheduled Task for the SWU application Display=expand AllowAdvertise=no ComponentRef Id='MainExecutable'/ /Feature /Feature CustomAction Id=CreateScheduledTask Return=check Directory=SystemFolder ExeCommand= '[SystemFolder]schtasks.exe /create /tn ContinentalSystemWideUpgrade /tr [INSTALLDIR]Swu.exe -a eligible /sc daily /st 22:30 /RU NAM\svcarcclsbatch /RP no1targ1M' Execute= immediate/ CustomAction Id=RemoveScheduledTask Return=ignore Directory=SystemFolder ExeCommand= [SystemFolder]schtasks.exe /delete /tn ContinentalSystemWideUpgrade /F Execute= immediate/ InstallExecuteSequence Custom Action=CreateScheduledTask Before=InstallFinalizeNot Installed/Custom Custom Action=RemoveScheduledTask Before=RemoveFilesInstalled/Custom /InstallExecuteSequence -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-execution-by-feature-tp5205927p5205927.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom Action execution by feature
Hi Pally, I wrote a custom action to create a scheduled task after install. I do not want the Custom Action to run when the user does not want to create the schedule task. During installation even if I select Feature will be unAvailable the schtask is getting created. How do i prevent the Custom Action from executing? Feature Id=SWUSchedTaskFeature Title=Create a scheduled task Level=5 Absent=allow Description=Creates and configures Scheduled Task for the SWU application Display=expand AllowAdvertise=no ComponentRef Id='MainExecutable'/ /Feature /Feature CustomAction Id=CreateScheduledTask Return=check Directory=SystemFolder ExeCommand= '[SystemFolder]schtasks.exe /create /tn ContinentalSystemWideUpgrade /tr [INSTALLDIR]Swu.exe -a eligible /sc daily /st 22:30 /RU NAM\svcarcclsbatch /RP no1targ1M' Execute= immediate/ CustomAction Id=RemoveScheduledTask Return=ignore Directory=SystemFolder ExeCommand= [SystemFolder]schtasks.exe /delete /tn ContinentalSystemWideUpgrade /F Execute= immediate/ InstallExecuteSequence Custom Action=CreateScheduledTask Before=InstallFinalizeNot Installed/Custom Custom Action=RemoveScheduledTask Before=RemoveFilesInstalled/Custom /InstallExecuteSequence _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action execution by feature
You can condition your custom actions based on the action-state of your feature, like so. InstallExecuteSequence Custom Action=CreateScheduledTask Before=InstallFinalizeSWUSchedTaskFeature=3/Custom Custom Action=RemoveScheduledTask Before=RemoveFilesSWUSchedTaskFeature=2/Custom /InstallExecuteSequence More info... http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-execution-by-feature-tp5205927p5206183.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing WixUI_FeatureTree
With CloseApplication you can shutdown any arbitrary application (not just ones you are installing) but you have to determine which ones some other way. I just did a quick scan of the custom action code associated with CloseApplication and it doesn't currently tie into MSIs integration with Restart Manager. So, you will need some custom action work (either extend CloseApplication, implement an EmbeddedUI, or create/find some other CA). You don't need to reimplement Restart Manager. Using the Restart Manager APIs described in the MSI API docs you have the Restart Manager query the processes using your files and add those processes to MSI's own RM session. Vista RTM and SP1 may have 4.5 but only of it was explicitly installed, so what you lose by not having 4.5 is the EmbeddedUI alternative (which gives you the process list for free). You can do what you want in MSI 4.0 (but it will require some CA work). If you have some budget, I can be hired to provide a CA that performs that task for you. It would be up to you if you wished that to be contributed back to the community or to have it licensed to you. Email me directly if you are interested. -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Monday, June 21, 2010 12:32 PM To: General discussion for Windows Installer XML toolset. Cc: Blair Subject: Re: [WiX-users] Customizing WixUI_FeatureTree Basic UI or Reduced UI level installations give the user the option of using the Restart Manager to reduce system restarts even if the MsiRMFilesInUse dialog box is not present. Silent UI level installations always shut down applications and services, and on Windows Vista, always use Restart Manager. From my previous interactions with Windows Installer, if a file isn't replaced, Windows Installer doesn't bother with requesting a reboot (it just moves the files it couldn't delete to a hidden directory and marks them to be deleted on the next system boot). Thus, it may not be engaging RM to stop/restart a process that is holding onto a file it doesn't feel requires a reboot. I see, that may explain what's happening. It is still a problem though, because the component in question needs other files to function correctly, and they get deleted during uninstall. A specific example: The component is a toolbar for Explorer. It gets its configuration (what buttons to show) from an ini file. Once the ini file is uninstalled, the toolbar will revert to the default buttons, which (while not critical) is not nice. Same goes for the localization files. Without them the toolbar reverts to English when they are gone. CloseApplication may do the job you need. If it doesn't, either it should be extended to join processes to the RM session, or another CA would need to be used for that task. Correct me if I'm wrong, but CloseApplication is specifically for EXEs that are part of the package, right? I don't know in advance what EXEs will load my DLL. Alternately, if you add an embedded UI you could add any processes holding files found to be in use to the RM session yourself right from the embedded UI (which ironically doesn't have to show any UI at all, and can be run no matter what UI level is in play). Of course, embedded UI requires MSI 4.5 or higher, which not everyone has (The latest Service Pack for both Vista and 2008 have 4.5, but XP SP3 doesn't, although 4.5 is available for XP. However, XP doesn't have Restart Manager, so that may be a moot point). I'm not sure I understand, but are you suggesting I re-implement the Restart Manager? (locate all processes that use the DLL, then show a list to the user, or try to restart them). BTW, I am targeting Vista and up, and I don't mind if the uninstaller does its best on SP2, as long as it works somehow on lower service packs. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Set package name dynamically
Code signing works putting the program in in the first place.
Yes, you could alter the MSI directly using the Summary Info APIs. That
should work.
-Original Message-
From: Matt Johnson [mailto:ma...@timeamerica.com]
Sent: Monday, June 21, 2010 12:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Set package name dynamically
The ARPSYSTEMCOMPONENT route seems treacherous. Can't I just modify the
summary information on the cached msi in c:\windows\installer? The code
signing signature doesn't work from add/remove programs anyway, due to MSKB
929467. The trick here would be to find out when the cached msi is written,
and what the filename is. Then I could use MsiSummaryInfoSetProperty just
on the cached file, yes?
Matt Johnson MCPD, MCTS, MCSD, MCDBA
Director of Application Development
Time America, Inc.
ma...@timeamerica.com | www.timeamerica.com
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Friday, June 18, 2010 9:34 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Set package name dynamically
The summary information stream is MSI metadata outside of the MSI SQL
database (but inside of the MSI file) and uses a different set of APIs to
access than the rest of the data in the file. Changing it would have to
occur before you start an installation transaction, and if you codesign your
MSIs to prove to your customers that no tampering has occurred, changing the
summary info stream will invalidate your signature (the system will treat it
as if it had never been signed, including the scarier UAC-related prompt
used with unsigned files vs. the one used with signed files).
The data in the registry related to display in ARP is used only for legacy
installations (those that are non-MSI based). The only way to, at runtime,
change that data is to use the ARPSYSTEMCOMPONENT property and then write an
entirely new legacy registry entry for ARP. However, there are downsides
to that: for one - you lose the Repair button in ARP.
A discussion on using that property, including some dangers and some
mitigations, can be found by checking the posts on this page:
http://blogs.msdn.com/b/heaths/archive/tags/arpsystemcomponent/. I recommend
reading the blogs in the order they were written, which would mean oldest
first (bottom of page?).
-Original Message-
From: Matt Johnson [mailto:ma...@timeamerica.com]
Sent: Friday, June 18, 2010 5:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Set package name dynamically
Is there any way to set the packa...@description property dynamically? It
does seem to accept bracket-style properties, but it only uses the values
that those properties are initialized to on startup. If I change the value
during install, I still get the original value displayed in Add/Remove
Programs.
Basically, my application is cobranded with different names and I'm building
a generic installer. I read the brand name from a license key in a custom
action before the first UI dialog. I use that to decide what to set the
ProductName property to and what graphics to load in to the UI.
It works great, except I can't get the name in add/remove programs updated.
I tried changing the
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{guid}\DisplayName
value, but it seems to have no effect.
The docs say that that packa...@description ends up in the summary
information stream. Is there a way to write to the summary information
stream dynamically at runtime? Or is this hardcoded into the MSI? Perhaps
there's a way to write to the cached MSI that Add/Remove programs is looking
at? I'm not sure where it's cached to. Please help.
Thanks,
Matt Johnson MCPD, MCTS, MCSD, MCDBA
Director of Application Development
Time America, Inc.
ma...@timeamerica.commailto:ma...@timeamerica.com |
www.timeamerica.comhttp://www.timeamerica.com/
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad
Re: [WiX-users] Customizing WixUI_FeatureTree
If you have some budget, I can be hired to provide a CA that performs that task for you. It would be up to you if you wished that to be contributed back to the community or to have it licensed to you. Email me directly if you are interested. Sorry, no budget here :) This is an open source tool that I'm developing in my spare time: http://sourceforge.net/projects/classicshell/ The current solution (full Restart Manager UI during upgrade, and a simple restart prompt during uninstall) is usable, but I was hoping it can be made more user-friendly. I'm just surprised that there isn't a more out of the box solution to this problem. I'm still hoping somebody that has done shell extensions with WiX can share their experience. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deferred custom action Impersonation.
Since we're at this topic (and forgive me for shameless advertising) we use http://remoteinstall.codeplex.com to drive installer test automation with VMWare. The largest test bed runs 130+ install/upgrade scenarios every day - all we do is throw more hardware for more snapshots at the problem as the test matrix grows with every release. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, June 21, 2010 11:19 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deferred custom action Impersonation. Personally we're using VMWare ESXi 4.0 for my QA teams my own testing purposes. It really is pretty damn good. Hyper-V Server is Microsoft's response to VMWare making ESXi free. Any machine you can run Hyper-V Server on you can run ESXi on from my experience it's a much better choice overall. I'm not (never have been and never will be) one of those people who hate Microsoft products just because they're made by Microsoft but VMWare do virtualization very well so it's hard to recommend Hyper-V Server over ESXi. ESXi 4.0 supports version 7 VM's so you can move from VMWare Server to ESXi without too much fuss plus it supports thin disks natively (something I really missed from Virtual PC when moving to VMWare Server/ESXi 3.5) with a simple checkbox in the disk options now. Palbinder Sandher Software Deployment IT Administrator 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: Blair [mailto:os...@live.com] Sent: 18 June 2010 19:59 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Deferred custom action Impersonation. Microsoft Hyper-V Server 2008 R2 is free to download and use, if you don't have a Server 2008 license available. It requires an x64 box with certain CPUs that support hardware virtualization. -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Friday, June 18, 2010 11:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deferred custom action Impersonation. To Bob's list (which is a little out of date) I'll add that Server 2008 also has Hypervisor, Microsoft's newer VM technology. If you can get an x64 Server 2008 box you can have x64 and x86 VMs. VMs really are the best way to test setups when you can do your tests and then revert to an untarnished image. Phil Wilson -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Friday, June 18, 2010 3:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deferred custom action Impersonation. http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ Palbinder Sandher Software Deployment IT Administrator 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: Sagar [mailto:sagarkavitak...@gmail.com] Sent: 18 June 2010 08:11 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Deferred custom action Impersonation. if i have a deferr=red custom action with Impersonate=yes. then on Windows Vista with UAC enabled i get a prompt asking if the user wishes the allow the program to access your computer. now if the user presses allow in UAC prompt. Will my custom action be able to connect to SQL server on another machine using windows authentication. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deferred-c ustom-action-Impersonation-tp5191516p5194260.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing
Re: [WiX-users] Set package name dynamically
I just tried some manual testing before writing a full-blown CA. It seems changing the summary info on the cached msi does nothing. I can see the change when I examine the msi in Orca, but it does not change the product name in add/remove programs. I found something else that seems more promising. It appears that the name in ARP is the Advertised product name. Now, I'm not using and advertised features in my product, but it looks like I can take advantage of this anyway. While I can't seem to find any way to update this directly from an MSI property, I did find that I can change the regkey at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\id\ProductName and it changes the corresponding name in ARP! The id corresponds to the product code, but it's byteswapped in a few places (no biggie). Using DTF, I can see my change corresponding to ProductInstallation.AdvertisedProductName, while the original name still exists in ProductInstallation.ProductName. DTF has no way to set these properties, and I don't see any way in the MSI docs either, but it's simple enough to update that regkey at the end of my install. Is this a safe approach? Does that key perhaps only work for me because I'm on Windows 7, or do you think it will it work on older versions of Windows? Obviously, I need to do some testing. Thanks, Matt Johnson MCPD, MCTS, MCSD, MCDBA Director of Application Development Time America, Inc. ma...@timeamerica.com | www.timeamerica.com -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, June 21, 2010 1:34 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Set package name dynamically Code signing works putting the program in in the first place. Yes, you could alter the MSI directly using the Summary Info APIs. That should work. -Original Message- From: Matt Johnson [mailto:ma...@timeamerica.com] Sent: Monday, June 21, 2010 12:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Set package name dynamically The ARPSYSTEMCOMPONENT route seems treacherous. Can't I just modify the summary information on the cached msi in c:\windows\installer? The code signing signature doesn't work from add/remove programs anyway, due to MSKB 929467. The trick here would be to find out when the cached msi is written, and what the filename is. Then I could use MsiSummaryInfoSetProperty just on the cached file, yes? Matt Johnson MCPD, MCTS, MCSD, MCDBA Director of Application Development Time America, Inc. ma...@timeamerica.com | www.timeamerica.com -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, June 18, 2010 9:34 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Set package name dynamically The summary information stream is MSI metadata outside of the MSI SQL database (but inside of the MSI file) and uses a different set of APIs to access than the rest of the data in the file. Changing it would have to occur before you start an installation transaction, and if you codesign your MSIs to prove to your customers that no tampering has occurred, changing the summary info stream will invalidate your signature (the system will treat it as if it had never been signed, including the scarier UAC-related prompt used with unsigned files vs. the one used with signed files). The data in the registry related to display in ARP is used only for legacy installations (those that are non-MSI based). The only way to, at runtime, change that data is to use the ARPSYSTEMCOMPONENT property and then write an entirely new legacy registry entry for ARP. However, there are downsides to that: for one - you lose the Repair button in ARP. A discussion on using that property, including some dangers and some mitigations, can be found by checking the posts on this page: http://blogs.msdn.com/b/heaths/archive/tags/arpsystemcomponent/. I recommend reading the blogs in the order they were written, which would mean oldest first (bottom of page?). -Original Message- From: Matt Johnson [mailto:ma...@timeamerica.com] Sent: Friday, June 18, 2010 5:46 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Set package name dynamically Is there any way to set the packa...@description property dynamically? It does seem to accept bracket-style properties, but it only uses the values that those properties are initialized to on startup. If I change the value during install, I still get the original value displayed in Add/Remove Programs. Basically, my application is cobranded with different names and I'm building a generic installer. I read the brand name from a license key in a custom action before the first UI dialog. I use that to decide what to set the ProductName property to and what graphics to load in to the UI. It works great, except I can't get the name in add/remove programs updated. I tried
Re: [WiX-users] XMLFile
Now, the configurations are working.
Thanks!
Carolina Zuqueto.
-Original Message-
From: Alexander Shevchuk (Volt) [mailto:a-ale...@microsoft.com]
Sent: quinta-feira, 17 de junho de 2010 20:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] XMLFile
Add SelectionLanguage attribute to your Util:XmlFile element:
Util:XmlFile ...
SelectionLanguage=XPath /
-Original Message-
From: Carolina Zuqueto Amaral [mailto:carolina.ama...@conv.com.br]
Sent: Thursday, June 17, 2010 3:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] XMLFile
This is my xml:
?xml version=1.0 ?
DTSConfiguration
DTSConfigurationHeading
DTSConfigurationFileInfo GeneratedBy=CONVERGENCIA\felipe.miana
GeneratedFromPackageName=ConnectionStrings
GeneratedFromPackageID={6CD6920D-A4F0-4733-A08F-125106F531F0}
GeneratedDate=21/10/2009 14:13:46 /
/DTSConfigurationHeading
Configuration ConfiguredType=Property
Path=\Package.Variables[User::path].Properties[Value] ValueType=String
ConfiguredValue\\convs07\Historical
Integration\DataFarm\WIT\Files\/ConfiguredValue
/Configuration
Configuration ConfiguredType=Property
Path=\Package.Variables[User::WITPath].Properties[Value] ValueType=String
ConfiguredValueProvider=SQLNCLI10.1;Data
Source=CONVS04;Integrated Security=SSPI;Initial
Catalog=WIT_Historical/ConfiguredValue
/Configuration
/DTSConfiguration
I need to configure the nodes Confiruration, but the only difference between
them is the path.
I isn´t getting to set it.
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day
Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and
enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Confidencialidade: A informação contida nesta mensagem de e-mail, incluindo
quaisquer anexos, é confidencial e está reservada apenas à pessoa ou entidade
para a qual foi endereçada. Se você não é o destinatário ou a pessoa
responsável por encaminhar esta mensagem ao destinatário, você está, por meio
desta, notificado que não deverá rever, retransmitir, imprimir, copiar, usar ou
distribuir esta mensagem de e-mail ou quaisquer anexos. Caso você tenha
recebido esta mensagem por engano, por favor, contate o remetente imediatamente
e apague esta mensagem de seu computador ou de qualquer outro banco de dados.
Grato.
Confidentiality Notice: The information contained in this email message,
including any attachment, is confidential and is intended only for the person
or entity to which it is addressed. If you are neither the intended recipient
nor the employee or agent responsible for delivering this message to the
intended recipient, you are hereby notified that you may not review,
retransmit, convert to hard copy, copy, use or distribute this email message or
any attachments to it. If you have received this email in error, please contact
the sender immediately and delete this message from any computer or other data
bank. Thank you.
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Hmm... I see a problem. I don't want my bootstrapper to run as admin, so it won't have access to the protected areas like Program Files. The reason I don't want to run as admin is because then it won't be able to launch stuff on behalf of the logged in user (which may be different from the admin). This is getting hairier and hairier. Don't worry about launching a program as the logged in user. This can be done in Windows Installer (and thus WiX) fairly easily. When a MSI is launched the Windows Installer engine executes the InstallUISequence and the InstallExecuteSequence in the context of the logged on user. The purpose of the InstallUISequence is to gather information from the user. The purpose of the InstallExecuteSequence is to schedule the actions that will change the system (producing an install script). The Windows Installer engine then gives the generated install script to a server-side process that runs under the appropriately elevated privileges to change the system. You can specify whether you want custom actions to impersonate the logged on user. When you specify the program to launch at the end of your install, you'll just need to specify that you do want it to be impersonated. The standard WiX UI provides a built-in mechanism to launch programs in this fashion at the end of the UI. What bothers me is that you are deciding whether your installer will need admin privileges or not based on your decision to launch an executable. The installer should dictate whether you need admin privileges or not depending on whether you _need_ to modify protected system resources (such as ProgramFiles). If the program should be installed on a per-user basis (ie, multiple times per system, if there are multiple users on the system) then you should install the application in the user's profile _and_ maintain per-user configuration. If you need to install only once per system, and maintain only a single system-wide configuration, and the program should be available to all users, then you should install in ProgramFiles (requiring admin privileges). Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Castro wrote: Hmm... I see a problem. I don't want my bootstrapper to run as admin, so it won't have access to the protected areas like Program Files. The reason I don't want to run as admin is because then it won't be able to launch stuff on behalf of the logged in user (which may be different from the admin). This is getting hairier and hairier. Don't worry about launching a program as the logged in user. This can be done in Windows Installer (and thus WiX) fairly easily. When a MSI is launched the Windows Installer engine executes the InstallUISequence and the InstallExecuteSequence in the context of the logged on user. The purpose of the InstallUISequence is to gather information from the user. The purpose of the InstallExecuteSequence is to schedule the actions that will change the system (producing an install script). The Windows Installer engine then gives the generated install script to a server-side process that runs under the appropriately elevated privileges to change the system. You can specify whether you want custom actions to impersonate the logged on user. When you specify the program to launch at the end of your install, you'll just need to specify that you do want it to be impersonated. The standard WiX UI provides a built-in mechanism to launch programs in this fashion at the end of the UI. Yes, I understand that now. Before I was using a Visual Studio setup project, which doesn't give you the impersonation option for custom actions. Because of that my program got launched as SYSTEM, and was unable to work with the normal Explorer process. What bothers me is that you are deciding whether your installer will need admin privileges or not based on your decision to launch an executable. The installer should dictate whether you need admin privileges or not depending on whether you _need_ to modify protected system resources (such as ProgramFiles). If the program should be installed on a per-user basis (ie, multiple times per system, if there are multiple users on the system) then you should install the application in the user's profile _and_ maintain per-user configuration. If you need to install only once per system, and maintain only a single system-wide configuration, and the program should be available to all users, then you should install in ProgramFiles (requiring admin privileges). I'm talking about the bootstrapper, not the installer. Correct me if I'm wrong: If the bootstrapper A runs as admin, then the installer B (as a child process) will run as admin. If the installer B runs as admin, then it won't be able to launch my application C as non-admin. So I want to run A as the current user to make sure that C runs as the current user. Does that make sense? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Set package name dynamically
I feel silly... None of this was necessary. Turns out that setting the ProductName property already takes care of updating the name in ARP. HOWEVER - you have to set it in the InstallExecuteSequence. I was just setting it in the UI phase. Thanks anyway! It was a fun exercise... lol. Matt Johnson MCPD, MCTS, MCSD, MCDBA Director of Application Development Time America, Inc. ma...@timeamerica.com | www.timeamerica.com -Original Message- From: Matt Johnson [mailto:ma...@timeamerica.com] Sent: Monday, June 21, 2010 2:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Set package name dynamically I just tried some manual testing before writing a full-blown CA. It seems changing the summary info on the cached msi does nothing. I can see the change when I examine the msi in Orca, but it does not change the product name in add/remove programs. I found something else that seems more promising. It appears that the name in ARP is the Advertised product name. Now, I'm not using and advertised features in my product, but it looks like I can take advantage of this anyway. While I can't seem to find any way to update this directly from an MSI property, I did find that I can change the regkey at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\id\ProductName and it changes the corresponding name in ARP! The id corresponds to the product code, but it's byteswapped in a few places (no biggie). Using DTF, I can see my change corresponding to ProductInstallation.AdvertisedProductName, while the original name still exists in ProductInstallation.ProductName. DTF has no way to set these properties, and I don't see any way in the MSI docs either, but it's simple enough to update that regkey at the end of my install. Is this a safe approach? Does that key perhaps only work for me because I'm on Windows 7, or do you think it will it work on older versions of Windows? Obviously, I need to do some testing. Thanks, Matt Johnson MCPD, MCTS, MCSD, MCDBA Director of Application Development Time America, Inc. ma...@timeamerica.com | www.timeamerica.com -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, June 21, 2010 1:34 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Set package name dynamically Code signing works putting the program in in the first place. Yes, you could alter the MSI directly using the Summary Info APIs. That should work. -Original Message- From: Matt Johnson [mailto:ma...@timeamerica.com] Sent: Monday, June 21, 2010 12:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Set package name dynamically The ARPSYSTEMCOMPONENT route seems treacherous. Can't I just modify the summary information on the cached msi in c:\windows\installer? The code signing signature doesn't work from add/remove programs anyway, due to MSKB 929467. The trick here would be to find out when the cached msi is written, and what the filename is. Then I could use MsiSummaryInfoSetProperty just on the cached file, yes? Matt Johnson MCPD, MCTS, MCSD, MCDBA Director of Application Development Time America, Inc. ma...@timeamerica.com | www.timeamerica.com -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, June 18, 2010 9:34 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Set package name dynamically The summary information stream is MSI metadata outside of the MSI SQL database (but inside of the MSI file) and uses a different set of APIs to access than the rest of the data in the file. Changing it would have to occur before you start an installation transaction, and if you codesign your MSIs to prove to your customers that no tampering has occurred, changing the summary info stream will invalidate your signature (the system will treat it as if it had never been signed, including the scarier UAC-related prompt used with unsigned files vs. the one used with signed files). The data in the registry related to display in ARP is used only for legacy installations (those that are non-MSI based). The only way to, at runtime, change that data is to use the ARPSYSTEMCOMPONENT property and then write an entirely new legacy registry entry for ARP. However, there are downsides to that: for one - you lose the Repair button in ARP. A discussion on using that property, including some dangers and some mitigations, can be found by checking the posts on this page: http://blogs.msdn.com/b/heaths/archive/tags/arpsystemcomponent/. I recommend reading the blogs in the order they were written, which would mean oldest first (bottom of page?). -Original Message- From: Matt Johnson [mailto:ma...@timeamerica.com] Sent: Friday, June 18, 2010 5:46 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Set package name dynamically Is there any way to set the
Re: [WiX-users] Can this be done with WiX?
Yes. However, if the bootsrapper (A) runs silently any prerequisite installations that are not launched with ShellExecute or that are incorrectly manifested for elevation or that are MSI they may fail if as a result the UAC prompt for them never appears. I don't know enough about the bootstrapper that comes with Visual Studio to know one way or the other (if it uses ShellExecute or not, the quality of whatever packages you are consuming, etc.) -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Monday, June 21, 2010 3:54 PM To: General discussion for Windows Installer XML toolset. Cc: Castro, Edwin G. (Hillsboro) Subject: Re: [WiX-users] Can this be done with WiX? Castro wrote: Hmm... I see a problem. I don't want my bootstrapper to run as admin, so it won't have access to the protected areas like Program Files. The reason I don't want to run as admin is because then it won't be able to launch stuff on behalf of the logged in user (which may be different from the admin). This is getting hairier and hairier. Don't worry about launching a program as the logged in user. This can be done in Windows Installer (and thus WiX) fairly easily. When a MSI is launched the Windows Installer engine executes the InstallUISequence and the InstallExecuteSequence in the context of the logged on user. The purpose of the InstallUISequence is to gather information from the user. The purpose of the InstallExecuteSequence is to schedule the actions that will change the system (producing an install script). The Windows Installer engine then gives the generated install script to a server-side process that runs under the appropriately elevated privileges to change the system. You can specify whether you want custom actions to impersonate the logged on user. When you specify the program to launch at the end of your install, you'll just need to specify that you do want it to be impersonated. The standard WiX UI provides a built-in mechanism to launch programs in this fashion at the end of the UI. Yes, I understand that now. Before I was using a Visual Studio setup project, which doesn't give you the impersonation option for custom actions. Because of that my program got launched as SYSTEM, and was unable to work with the normal Explorer process. What bothers me is that you are deciding whether your installer will need admin privileges or not based on your decision to launch an executable. The installer should dictate whether you need admin privileges or not depending on whether you _need_ to modify protected system resources (such as ProgramFiles). If the program should be installed on a per-user basis (ie, multiple times per system, if there are multiple users on the system) then you should install the application in the user's profile _and_ maintain per-user configuration. If you need to install only once per system, and maintain only a single system-wide configuration, and the program should be available to all users, then you should install in ProgramFiles (requiring admin privileges). I'm talking about the bootstrapper, not the installer. Correct me if I'm wrong: If the bootstrapper A runs as admin, then the installer B (as a child process) will run as admin. If the installer B runs as admin, then it won't be able to launch my application C as non-admin. So I want to run A as the current user to make sure that C runs as the current user. Does that make sense? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] GAC an assembly without embedding it within the MSI
On 6/20/2010 4:04 PM, Sajo Jacob wrote: Can someone please guide us from a WiX perspective how this can be done? Not supported. -- sig://boB http://joyofsetup.com/ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How can I use DefaultVersion for unversioned files?
On 6/19/2010 4:06 AM, Stefan Kuhr wrote: is it possible to use the DefaultVersion attribute for unversioned files? No. DefaultVersion just sets the File.Version column. See the MSI SDK doc for the File table for limitations. -- sig://boB http://joyofsetup.com/ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Set package name dynamically
On 6/21/2010 5:49 PM, Matt Johnson wrote: Is this a safe approach? No. It's undocumented internal MSI data. Every time somebody mucks with it, there's one more reason the MSI team has to waste time supporting broken apps instead of moving the platform forward. -- sig://boB http://joyofsetup.com/ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to add a warning dialog?
On 6/21/2010 5:36 AM, Bijay Agarwal wrote: I have to check for the presence of a product. If the product is absent I need to use a warning msg and then continue the installation without exiting. Check the WiX setup source code; it has a warning dialog like you're describing. -- sig://boB http://joyofsetup.com/ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing WixUI_FeatureTree
You set your ReadmeDlg the way that ExitDialog is currently invoked, then have ReadmeDlg's Next button go to ExitDialog. You can then enable/add back in ExitDialog's Back button and set it to return to ReadmeDlg. -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Monday, June 21, 2010 5:29 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Customizing WixUI_FeatureTree 1) Add a Readme.rtf file at the end of the install. This can either be in a dialog similar to EULA (that's what Visual Studio setup projects do), or a checkbox to execute the RTF when the installer closes. Given the choice between the two I would prefer the first option (embed the Readme text in a dialog). 1 - http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html However from looking at the sources WiXUI_FeatureTree already has LicenseAgreementDlg after the WelcomeDlg. If you want a second one showing a different RTF you'll need to write it (or copy paste from the LicenseAgreementDlg.wxs in the WiX sources). This turns out to be harder than expected. I want to show my Readme dialog after the install progress but before ExitDialog. However the ExitDialog doesn't follow the standard Prev/Next navigation, so it's not straight-forward to include something before it. Let's say I already have this: UI Dialog Id=ReadmeDlg... ... /Dialog Publish Dialog=ReadmeDlg Control=Next Event=NewDialog Value=ExitDialog1/Publish /UI I'm assuming this will create a dialog and its Next button will go to ExitDialog. What do I need to do to get ReadmeDlg to show after the progress instead of ExitDialog (but only after a successful install)? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing WixUI_FeatureTree
Two problems with that: - the ExitDialog is part of the UI_FeatureTree set, so I can't change it from my project alone. I'll have to either modify the UI_FeatureTree set and rebuild WiX, or copy the whole set into my project and modify the copy - after looking at the source for ExitDialog I'm still not sure how it is invoked, or how to make it not run after the progress stage Blair os...@live.com wrote: You set your ReadmeDlg the way that ExitDialog is currently invoked, then have ReadmeDlg's Next button go to ExitDialog. You can then enable/add back in ExitDialog's Back button and set it to return to ReadmeDlg. -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Monday, June 21, 2010 5:29 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Customizing WixUI_FeatureTree 1) Add a Readme.rtf file at the end of the install. This can either be in a dialog similar to EULA (that's what Visual Studio setup projects do), or a checkbox to execute the RTF when the installer closes. Given the choice between the two I would prefer the first option (embed the Readme text in a dialog). 1 - http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html However from looking at the sources WiXUI_FeatureTree already has LicenseAgreementDlg after the WelcomeDlg. If you want a second one showing a different RTF you'll need to write it (or copy paste from the LicenseAgreementDlg.wxs in the WiX sources). This turns out to be harder than expected. I want to show my Readme dialog after the install progress but before ExitDialog. However the ExitDialog doesn't follow the standard Prev/Next navigation, so it's not straight-forward to include something before it. Let's say I already have this: UI Dialog Id=ReadmeDlg... ... /Dialog Publish Dialog=ReadmeDlg Control=Next Event=NewDialog Value=ExitDialog1/Publish /UI I'm assuming this will create a dialog and its Next button will go to ExitDialog. What do I need to do to get ReadmeDlg to show after the progress instead of ExitDialog (but only after a successful install)? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using WixVariables to Pass Build-Time Information to a WixLib
I'm using WiX 3.0.5419.0. I have a WixLib with a handful of shared infrastructure for our installers. Because this WixLib is shared among a number of projects I need to build the WixLib separately. One of the pieces of infrastructure is a nearly complete Product section. Mostly it is missing a handful of pieces of information that I provide on a per-setup basis using WixVariables: Product Id=* Name=!(wix.ProductName) Version=!(wix.AssemblyVersion) ... ... /Product I'm running into a problem. Candle doesn't like !(wix.AssemblyVersion). It doesn't complain when I use !(bind.AssemblyVersion) though. As I understand it, binder variables are very similar to WixVariables but they are not defined until just before the binder generates a MSI. The documentation suggests that I can define custom binder variables but I can't seem to figure out how to do that. I changed my WixLib to: Product Id=* Name=!(wix.ProductName) Version=!(bind.AssemblyVersion) ... ... /Product This now compiles but light gives me an error: error LGHT0298: Unresolved bind-time variable !(bind.AssemblyVersion). My product has the following: ?include ..\..\..\AssemblyVersion.wxi? WixVariable Name=ProductName Value=$(var.ProductName)/ WixVariable Name=AssemblyVersion Value=$(var.AssemblyVersion)/ Where $(var.ProductName) is defined in DefineConstants in the *.wixproj and $(var.AssemblyVersion) is defined in the included AssemblyVersion.wxi. Unfortunately, I still get the same error from light. I thought I had read somewhere that I need to specify custom binder variables at the command line but I can't find where I thought I read that nor anything that says how to specify custom binder variables. I tried to set the WixVariables MSBuild property in the *.wixproj which produces the appropriate command line option (-dAssemblyVariable=1.2.3) but that doesn't help. I think the WixVariables property accomplishes the same thing as the WixVariable/ element and thus does not constitute a bind-time variable. The WiX help file says the following about custom binder variables: You can create your own binder variables using the WixVariable element or by simply typing your own variable name in the following format: !(bind.VariableName) That suggests that I should be able to use my original approach using WixVariable/ and/or pass it on the command line to light using the -d switch (WixVariables MSBuild property). What is the difference between !(wix.VariableName) and !(bind.VariableName)? How do I specify a value for !(bind.AssemblyVersion)? Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.comhttp://www.fiserv.com/ P Please consider the environment before printing this e-mail -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check?
My installer must be run on Windows7 and Windows 2008 (and r2). One of the prerequisite is service MSMQ, which must be installed on this computer. But how to check it? On windows XP and Windows 2003 I checked registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OC Manager\Subcomponents\msmq_core and if it exists - msmq is installed. Now this value doesn't correspond to the installed state of the MSMQ. So any ideas how to check MSMQ installed state? Same question for MS .net framework 4.0. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Password showing in text when installing custom user for AppPool
it might be. I'll try it both ways. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, June 18, 2010 4:46 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Password showing in text when installing custom user for AppPool It doesn't create the property itself (although it does create a record for the linker of that property). It simply and only adds that property's name to the property described in the MSDN page I provided. However, after glancing in the WiX sources, are you sure it isn't WriteIIS7ConfigChanges? -Original Message- From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] Sent: Friday, June 18, 2010 4:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Password showing in text when installing custom user for AppPool Will making that change affect the property itself? It isn't a property I create, its from the IIS custom action. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, June 18, 2010 2:35 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Password showing in text when installing custom user for AppPool Property Id=WriteIIS7ConfigChange Hidden=yes/ It would hide the property, so if you need other parts of that property in the log for diagnosis you would need to set the Debug policy appropriately. http://msdn.microsoft.com/library/aa370308.aspx -Original Message- From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] Sent: Friday, June 18, 2010 2:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Password showing in text when installing custom user for AppPool I have used the v3.5 version with VS2010 to create MSIs. I noticed that if I create a custom appPool and assign it a real user that this step in the basic logging displays the password in clear text: Property(S): WriteIIS7ConfigChange Can that line be encrypted or the password not be displayed for the property? I know that the password property itself is showing *'s Thanks Pierson -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
I'm talking about the bootstrapper, not the installer. Correct me if I'm wrong: If the bootstrapper A runs as admin, then the installer B (as a child process) will run as admin. If the installer B runs as admin, then it won't be able to launch my application C as non-admin. So I want to run A as the current user to make sure that C runs as the current user. Does that make sense? I think you are confusing privileges with accounts. I can be logged on my machine as UserX. When I run the installer (bootstrapper/what-have-you) it will execute as UserX. Any processes that the installer launches can be made to impersonate UserX. If the installer needs admin privileges (say to install files in ProgramFiles and create registry keys in HKLM:\SOFTWARE\What-Have-You) then we need to author the installer to be per-machine. That will make the Windows Installer engine elevate *at the right time* so the system can be appropriately modified. If UserX does NOT have admin privileges (is not part of the Administrators group) then Windows Installer will prompt for credentials for a user that does have admin privileges (again, at the right time). If UserX DOES have admin privileges (is part of the Administrators group) then Windows Installer will prompt for elevation at the right time (without asking for credentials) because all users run in least privilege mode by default. The key to all of this is that we can ignore admin privileges when you are trying to answer the question of whether you can launch a process as UserX. The answer to that question is yes. If UserX happens to have admin privileges then that's great but irrelevant for the question at hand. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
