[WiX-users] Burn: bundle cost validation?
Hello. I have a question: my BA shows feature selection screen, where user can choose what features of what packages he wants to install, and I wonder is there any mechanism in BA that I can use to validate if there is enough disk space for installation? For simple msi launch there are CostInitialize, FileCost, CostFinalize actions, that are responsible for this. BR, Vadym. /pre font face=arial size=1 color=#736F6E bSDL PLC confidential, all rights reserved./b If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.BR SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.BR Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. /font -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers
Well, that was a helpful clue. I was able to get smoke.exe to run without error on my newest Server 2008 R2 build agent by: 1) disabling the Application Identity Service; 2) enabling for autostart and starting the Application Information service; 3) enabling for autostart and starting the Application Management service; I have no idea if all of that is necessary, but it was progress. -- John M. Cooper -Original Message- From: Heath Stewart [mailto:clubs...@gmail.com] Sent: Thursday, March 29, 2012 11:12 PM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers ICE does not seem work correctly on a default, locked-down install of Windows Server 2008 R2 with AppLocker enabled. IIRC, an MSI policy that is locked down on Server also has to be enabled (it's been a while since I had to ge this working on my own machine). On Thu, Mar 29, 2012 at 1:21 PM, Christopher Painter chr...@iswix.comwrote: I've done more research. I wrote a per-user install that didn't require admin and tried to install it by using an MSBuild Exec task. I got a 1601 error message saying the installer service was unavailable. I also ran sc query msiserver and it didn't say it was disabled. But clearly MSI is locked down in their build environment. From: John Cooper jocoo...@jackhenry.com Sent: Thursday, March 29, 2012 3:00 PM To: chr...@iswix.com chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers Could it be authority to execute/registration of vbscript? I believe some of those validation tests still have vbs in them, and if it can't run, it's going to fail every time. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, March 29, 2012 11:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers I've started playing with Microsoft's new hosted build service and I've come across some issues. The environment is locked down ( the builds don't run with administrative priv ) so you can't install software. While I understand WiX can xcopy deploy to a build envionment, I wanted to also leverage the MSBUILD ( .wixproj ) support because, well, that's kind of the whole design of TFS Team Build. So I grabbed the contents of the MSBuild Targets dirctory and the WiX directory and checked it into source control. Then I passed the following values into the build: /p:WiXTargetsPath=..\WiX\MSBuild\wix.targets;WixTasksPath=WiXTasks.dll ;WixTo olPath=..\WiX\Application\bin;WixExtDir=..\WiX\Application\bin Everything almost worked except for ICE Validation. I was getting the usual suspect: light.exe: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. I'm running the X86 msbuild platform. Does anyone have any suggestions on what could be done with user-privs only to fix this problem? Turning off validation is a horrible work around. -- -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
Re: [WiX-users] RemoveExisitngProducts and deferred CA
When I ran into that error/warning, it was because I had some custom actions that where scheduled before the removeexistingproducts. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RemoveExisitngProducts-and-deferred-CA-tp7418399p7421588.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Native language OS install vs language pack
Any takers? Any tips? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Native-language-OS-install-vs-language-pack-tp7414229p7421594.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers
May be not helpful enough. Enabling validation still gets me: light.exe: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe: Error executing ICE action 'ICE02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe: Error executing ICE action 'ICE03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe: Error executing ICE action 'ICE04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe: Error executing ICE action 'ICE05'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. I've already verified that vbscript and jscript are not registered in HKCU and are properly registered in HKLM. No dice. Going to see if running smoke as an msbuild process will work for me. Got two more Server 2008 R2 build servers coming on line today, and I need to have this working. -- John M. Cooper -Original Message- From: John Cooper Sent: Friday, March 30, 2012 8:29 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers Well, that was a helpful clue. I was able to get smoke.exe to run without error on my newest Server 2008 R2 build agent by: 1) disabling the Application Identity Service; 2) enabling for autostart and starting the Application Information service; 3) enabling for autostart and starting the Application Management service; I have no idea if all of that is necessary, but it was progress. -- John M. Cooper -Original Message- From: Heath Stewart [mailto:clubs...@gmail.com] Sent: Thursday, March 29, 2012 11:12 PM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers ICE does not seem work correctly on a default, locked-down install of Windows Server 2008 R2 with AppLocker enabled. IIRC, an MSI policy that is locked down on Server also has to be enabled (it's been a while since I had to ge this working on my own machine). On Thu, Mar 29, 2012 at 1:21 PM, Christopher Painter chr...@iswix.comwrote: I've done more research. I wrote a per-user install that didn't require admin and tried to install it by using an MSBuild Exec task. I got a 1601 error message saying the installer service was unavailable. I also ran sc query msiserver and it didn't say it was disabled. But clearly MSI is locked down in their build environment. From: John Cooper jocoo...@jackhenry.com Sent: Thursday, March 29, 2012 3:00 PM To: chr...@iswix.com chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers Could it be authority to execute/registration of vbscript? I believe some of those validation tests still have vbs in them, and if it can't run, it's going to fail every time. --
Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers
Well, the only benefit to running smoke.exe as an Exec process is that I can set the ConinueOnError process to keep it from breaking the build. I also have an interesting error message from smoke.exe during the run: smoke.exe: An unexpected Win32 exception with error code 0x643 occurred: Action - 'ICE08' Fatal error during installation C:\Builds\44\765\Sources\Dev\WFS\WFServerWix\WFServerWix.wixproj (147): The command C:\Program Files (x86)\Windows Installer XML v3.5\bin\smoke.exe -v C:\Builds\44\765\Binaries\WFServer.msi exited with code 216. -- John M. Cooper -Original Message- From: John Cooper Sent: Friday, March 30, 2012 9:10 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers May be not helpful enough. Enabling validation still gets me: light.exe: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe: Error executing ICE action 'ICE02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe: Error executing ICE action 'ICE03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe: Error executing ICE action 'ICE04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe: Error executing ICE action 'ICE05'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. I've already verified that vbscript and jscript are not registered in HKCU and are properly registered in HKLM. No dice. Going to see if running smoke as an msbuild process will work for me. Got two more Server 2008 R2 build servers coming on line today, and I need to have this working. -- John M. Cooper -Original Message- From: John Cooper Sent: Friday, March 30, 2012 8:29 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers Well, that was a helpful clue. I was able to get smoke.exe to run without error on my newest Server 2008 R2 build agent by: 1) disabling the Application Identity Service; 2) enabling for autostart and starting the Application Information service; 3) enabling for autostart and starting the Application Management service; I have no idea if all of that is necessary, but it was progress. -- John M. Cooper -Original Message- From: Heath Stewart [mailto:clubs...@gmail.com] Sent: Thursday, March 29, 2012 11:12 PM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers ICE does not seem work correctly on a default, locked-down install of Windows Server 2008 R2 with AppLocker enabled. IIRC, an MSI policy that is locked down on Server also has to be enabled (it's been a while since I had to ge this working on my own machine). On Thu, Mar 29, 2012 at 1:21 PM, Christopher Painter chr...@iswix.comwrote: I've done more research. I wrote a per-user install that didn't
Re: [WiX-users] Burn: bundle cost validation?
Burn engine does not help with that today. Your BA can do it. On Fri, Mar 30, 2012 at 5:09 AM, Vadym Verba vve...@sdl.com wrote: Hello. I have a question: my BA shows feature selection screen, where user can choose what features of what packages he wants to install, and I wonder is there any mechanism in BA that I can use to validate if there is enough disk space for installation? For simple msi launch there are CostInitialize, FileCost, CostFinalize actions, that are responsible for this. BR, Vadym. /pre font face=arial size=1 color=#736F6E bSDL PLC confidential, all rights reserved./b If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.BR SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.BR Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. /font -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix Burn LogoFile doesn't work on Windows XP
Based on what you've described it sounds like a bug. Can you debug it and see? Can you open a bug if it looks like something is messed up? On Thu, Mar 29, 2012 at 8:23 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, I create a burn exe and as long as I don't specify a LogoFile attribute for the bal:WixStandardBootstrapperApplication element I have no problems. But when I do add this attribute it works fine on Windows 7 but does not work on Windows XP. On XP the GUI does not even load. In the log I get: [07D8:081C][2012-03-29T12:16:16]: Error 0x8007000d: Failed to load theme controls. [07D8:081C][2012-03-29T12:16:16]: Error 0x80004005: Failed to create main window. [07D8:080C][2012-03-29T12:16:16]: Shutting down, exit code: 0x80004005 My XML is below. The only difference in the XML between the two cases is the LogoFile attribute. I also tried to use a Payload element for image as I seen a post by someone else using a custom theme but it didn't make a difference. Bundle Name=Dynagen Configurator Version=0.9.0.0 Manufacturer=Dynagen Technologies Inc. UpgradeCode=e5ce911c-cae5-43f8-b11e-878989f1fec5 IconSourceFile=$(var.ConfigExePath)\DynagenProgramIcon.ico HelpUrl=www.dynagen.ca Condition=NOT ( ((VersionNT=600) OR ((VersionNT=501) AND (ServicePackLevel=3))) AND (VersionMsi=301) ) BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense bal:WixStandardBootstrapperApplication LogoFile=$(var.ConfigExePath)\DynagenProgramIcon.ico LicenseUrl=http://www.dynagen.ca; SuppressOptionsUI=yes / !-- -- !--Payload SourceFile=$(var.ConfigExePath)\DynagenProgramIcon.ico/-- /BootstrapperApplicationRef Chain PackageGroupRef Id='Netfx4Full' / PackageGroupRef Id=VS2010_Cpp/ PackageGroupRef Id=Shell_Installer/ /Chain /Bundle A bug or am I doing something wrong? Wes Manning -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Theme
ThmViewer.exe might help as well. It isn't perfect right now but it can rapidly speed up thm development. On Thu, Mar 29, 2012 at 12:12 PM, robert_h_yang robert_y...@non.agilent.com wrote: I started tinkering with this, and got something like this to work : BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense bal:WixStandardBootstrapperApplication LicenseFile=license.rtf LogoFile=mylogo.bmp SuppressOptionsUI=yes ThemeFile=mytheme.xml LocalizationFile=mytheme.wxl / Payload Name=myico.ico Compressed=yes SourceFile=application.ico/ /BootstrapperApplicationRef Some explanation below : 1. Some theme files can be found in the source under src\ext\BalExtension\wixstdba\Resources 2. I hacked up RtfTheme.[xml|wxl] to come up with my own Mytheme.* -- the schema is documented in the Wix 3.6 help file (as of build 2719 at least). 3. Myico.ico is used in my theme as a custom icon for the main window. Staring at WixStandardBootstrapperApplication.cpp and BalCompiler.cs helps, as does searching the source tree .. Parkes, Kevin wrote I'm exploring Burn and would like to try using my own theme with WixStandardBootstrapperApplication.Foundation. I'm probably being dense but I haven't managed to get anything working so far and the documentation isn't exactly extensive (yet). A few quick pointers as to how to get started would be much appreciated. Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Theme-tp7262316p7418931.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: forceReboot and UI
Actually, this is a bug. The wixstdba should go straight back to progress after a force reboot and it obviously is not. Can you open the bug? On Thu, Mar 29, 2012 at 12:55 AM, Sergey Yukhno sergey.yuk...@visutechsystem.by wrote: Hello. Can I switch off install dialog after forceReboot? Every time after rebooting I have to set options in the Options dialog. And how to save the options between rebootings? It is possible? ExePackage Id=WindowsInstaller SourceFile=..\MsiProjects\SourceDir\Packages\WindowsXP-KB942288-v3-x86.exe Compressed=no Vital=no InstallCommand=/quiet /norestart PerMachine=yes Cache=no InstallCondition=Feature1 AND VersionMsi lt; v4.5.0.0 ExitCode Behavior=forceReboot / /ExePackage ExePackage Id=dotNetFx40 SourceFile=dotNetFx40_Full_x86_x64.exe InstallCommand=/quiet /norestart Compressed=no InstallCondition=(NOT DotNetFramework40FullInstallRegValue=1) AND Feature1 ExitCode Behavior=forceReboot / /ExePackage Thanks for your help, Sergey -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating a shortcut to a directory
Hi, Complete WiX beginner here. I've managed to create a Start Menu folder with shortcuts to files in it (by using Shortcut elements nested inside the File element of the destination, which in turn is inside a Component element). But I want to create a shortcut to the installation *directory* itself so the users can edit some of the files there. Putting Shortcut inside a Directory doesn't seem to work. I feel I have to put Shortcut in a Component somehow but haven't managed to make it work. If anyone can give a short example of creating a shortcut-to-a-folder in the Start Menu, that would be great. -Stephen -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating a shortcut to a directory
After some trial and error I've found that adding the following to my Component (containing the Shortcut) RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Value='' KeyPath='yes' / ...makes it all work. I'm a bit concerned because I've used the Software\[Manufacturer]\[ProductName] registry key as the key path for another component (the start menu folder itself) and I read somewhere that key paths should not be reused between components. Still, it works in my tests currently. -Stephen -Original Message- From: Stephen Brooks Sent: Friday, March 30, 2012 8:33 PM To: wix-users@lists.sourceforge.net Subject: Re: Creating a shortcut to a directory Hi, Complete WiX beginner here. I've managed to create a Start Menu folder with shortcuts to files in it (by using Shortcut elements nested inside the File element of the destination, which in turn is inside a Component element). But I want to create a shortcut to the installation *directory* itself so the users can edit some of the files there. Putting Shortcut inside a Directory doesn't seem to work. I feel I have to put Shortcut in a Component somehow but haven't managed to make it work. If anyone can give a short example of creating a shortcut-to-a-folder in the Start Menu, that would be great. -Stephen -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Creating a shortcut to a directory
Hi, Complete WiX beginner here. I've managed to create a Start Menu folder with shortcuts to files in it (by using Shortcut elements nested inside the File element of the destination, which in turn is inside a Component element). But I want to create a shortcut to the installation *directory* itself so the users can edit some of the files there. Putting Shortcut inside a Directory doesn't seem to work. I feel I have to put Shortcut in a Component somehow but haven't managed to make it work. If anyone can give a short example of creating a shortcut-to-a-folder in the Start Menu, that would be great. -Stephen -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix Burn LogoFile doesn't work on Windows XP
Hi Rob, I'm not sure what you mean by debug. Does burn have a verbose command line option? I'm not that familiar with window installer and wix. Just started using wix for msi 6 months ago and burn a week ago. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: March-30-12 12:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix Burn LogoFile doesn't work on Windows XP Based on what you've described it sounds like a bug. Can you debug it and see? Can you open a bug if it looks like something is messed up? On Thu, Mar 29, 2012 at 8:23 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, I create a burn exe and as long as I don't specify a LogoFile attribute for the bal:WixStandardBootstrapperApplication element I have no problems. But when I do add this attribute it works fine on Windows 7 but does not work on Windows XP. On XP the GUI does not even load. In the log I get: [07D8:081C][2012-03-29T12:16:16]: Error 0x8007000d: Failed to load theme controls. [07D8:081C][2012-03-29T12:16:16]: Error 0x80004005: Failed to create main window. [07D8:080C][2012-03-29T12:16:16]: Shutting down, exit code: 0x80004005 My XML is below. The only difference in the XML between the two cases is the LogoFile attribute. I also tried to use a Payload element for image as I seen a post by someone else using a custom theme but it didn't make a difference. Bundle Name=Dynagen Configurator Version=0.9.0.0 Manufacturer=Dynagen Technologies Inc. UpgradeCode=e5ce911c-cae5-43f8-b11e-878989f1fec5 IconSourceFile=$(var.ConfigExePath)\DynagenProgramIcon.ico HelpUrl=www.dynagen.ca Condition=NOT ( ((VersionNT=600) OR ((VersionNT=501) AND (ServicePackLevel=3))) AND (VersionMsi=301) ) BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense bal:WixStandardBootstrapperApplication LogoFile=$(var.ConfigExePath)\DynagenProgramIcon.ico LicenseUrl=http://www.dynagen.ca; SuppressOptionsUI=yes / !-- -- !--Payload SourceFile=$(var.ConfigExePath)\DynagenProgramIcon.ico/-- /BootstrapperApplicationRef Chain PackageGroupRef Id='Netfx4Full' / PackageGroupRef Id=VS2010_Cpp/ PackageGroupRef Id=Shell_Installer/ /Chain /Bundle A bug or am I doing something wrong? Wes Manning -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RemoveExisitngProducts and deferred CA
There may not be enough context in that WiX to see what actually gets generated in the MSI file. That sequence is certainly allowed because other tools have been generating it for years. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 2:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RemoveExisitngProducts and deferred CA Thanks for your reply Phil, I had tried that and unfortunately got the error *RemoveExistingProducts action sequenced incorrectly* The sequence which I had tried was InstallExecute Before=RemoveExistingProducts / RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts I had also tried the following sequence but still got the RemoveExistingProducts error RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts On Thu, Mar 29, 2012 at 1:42 PM, Wilson, Phil phil.wil...@invensys.comwrote: The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
Re: [WiX-users] RemoveExisitngProducts and deferred CA
If you sequence before InstallFinalize, you need to also schedule InstallExecute (and REP is sequenced after that.) http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29.aspx Dave On 3/30/2012 1:40 PM, Wilson, Phil wrote: There may not be enough context in that WiX to see what actually gets generated in the MSI file. That sequence is certainly allowed because other tools have been generating it for years. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 2:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RemoveExisitngProducts and deferred CA Thanks for your reply Phil, I had tried that and unfortunately got the error *RemoveExistingProducts action sequenced incorrectly* The sequence which I had tried was InstallExecute Before=RemoveExistingProducts / RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts I had also tried the following sequence but still got the RemoveExistingProducts error RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts On Thu, Mar 29, 2012 at 1:42 PM, Wilson, Philphil.wil...@invensys.comwrote: The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its
Re: [WiX-users] RemoveExisitngProducts and deferred CA
That is what I posted earlier, but without seeing that area in the final MSI file it's not clear that's actually what's going on. Phil W -Original Message- From: David Connet [mailto:d...@agilityrecordbook.com] Sent: Friday, March 30, 2012 1:59 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RemoveExisitngProducts and deferred CA If you sequence before InstallFinalize, you need to also schedule InstallExecute (and REP is sequenced after that.) http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29.aspx Dave On 3/30/2012 1:40 PM, Wilson, Phil wrote: There may not be enough context in that WiX to see what actually gets generated in the MSI file. That sequence is certainly allowed because other tools have been generating it for years. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 2:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RemoveExisitngProducts and deferred CA Thanks for your reply Phil, I had tried that and unfortunately got the error *RemoveExistingProducts action sequenced incorrectly* The sequence which I had tried was InstallExecute Before=RemoveExistingProducts / RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts I had also tried the following sequence but still got the RemoveExistingProducts error RemoveExistingProducts Before=InstallFinalizePREVIOUSVERSION_AGPM_FOUND/RemoveExistingProducts On Thu, Mar 29, 2012 at 1:42 PM, Wilson, Philphil.wil...@invensys.comwrote: The other placement of RemoveExistingProducts is in a sequence at the end typically something like: PublishProduct InstallExecute RemoveExistingProducts InstallFinalize So there is room for your deferred CA in that gap between REP and InstallFinalize. Phil W -Original Message- From: Meera Jindal [mailto:meera.jin...@gmail.com] Sent: Thursday, March 29, 2012 9:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RemoveExisitngProducts and deferred CA Hi Due to KB 905238(http://support.microsoft.com/kb/905238) I have to schedule RemoveExisitngProducts after InstallFinalize. Hence during upgrade my new product gets installed first and then the old product gets removed. The product which I am working on adds a port rule to the firewall so that the port can be used by the service installed by the product for communicating with the network. Now the msi of the old product removes this port from firewall during uninstall. Since both the new and the old version of the product use the same port for communicating, the behavior which we are seeing during upgrade is that even though the new product opens the port during install, the old product removes it during uninstall. The net effect is that port is removed from the firewall. Opening up a port in the firewall seems to be a system change and should be done in a deferred custom action and should be done after the old product has been uninstalled. Hence, this custom action should be done after RemoveExisitngProducts. However, since RemoveExisitngProducts is after Installfinalize, I cannot run this as a deferred custom action because deferred CAs run between InstallInitilaize and InstallFinalize. I also cannot change the old product behavior to not remove the port during an upgrade case as the old product has already been released. Can someone please guide me through this and let me know how can invoke a custom action making a system change after RemoveExistingProducts(which is scheduled after InstallFinalize). Alternatively, if there is any other way of doing this I would be interested in knowing that as well. Thanks for your help!! Regards Meera -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of
