Re: [WiX-users] Bootstapper hangs
And, yes, there is *some* documentation on the calls a BA must make. It's in the WiX.chm. More is required but Bruce's approach is very good until we make the shift from fixing bugs to writing documentation. On Sat, Apr 28, 2012 at 1:55 PM, Bruce Cran br...@cran.org.uk wrote: On 28/04/2012 21:45, Alexander Lamaison wrote: Now I see that WixStdBA calls methods of the engine to drive it. Is the required sequence of interactions documented anywhere or do I just have to pick WixStdBA apart? I've just been picking WixStdBA apart. I think a typical application will call Detect() at startup, and then when the user clicks Install it'll call Plan(). Once Plan completes it'll automatically call Apply(). For a BA with no UI I think you'd call Detect() in OnStartup(), Plan() in OnDetectComplete(), and Apply() in your OnApplyComplete() method. -- Bruce Cran -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn support for 32bit and 64bit .NET Framework 4 pre-requisite
IIRC, we chose to install the NETFX that has support for all platforms. That's why it's x86_x64 in the file name. On Sat, Apr 28, 2012 at 5:36 AM, Kristjan Laane kristjan.la...@gmail.comwrote: Dear fellow developers, -- 1 -- I am using the Wix setup bundle as a guide for my own bootstrapper, but it seems to me that the official Wix installer does not work support installing .NET 4 Full on 64bit properly?: I.e. as far as I can tell the DetectCondition is incorrect, because it only targets 32 bit, and there will be no installation happening on 64bit? Fragment WixVariable Id=WixMbaPrereqPackageId Value=Netfx4Full / WixVariable Id=WixMbaPrereqLicenseUrl Value=NetfxLicense.rtf / util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full Value=Version Variable=Netfx4FullVersion / util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full Value=Version Variable=Netfx4x64FullVersion Win64=yes / PackageGroup Id=Netfx4Full ExePackage Id=Netfx4Full Cache=no Compressed=no PerMachine=yes Permanent=yes Vital=yes SourceFile=dotNetFx40_Full_x86_x64.exe DownloadUrl= http://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6 -BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exehttp://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6-BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exe DetectCondition=Netfx4FullVersion AND (NOT VersionNT64 OR Netfx4x64FullVersion) / !-- ExePackage Id=Netfx4x86 DownloadUrl= http://download.microsoft.com/download/5/6/4/5641DA81-E6FA-4550 -9F80-A1D862D9CFAA/dotNetFx40_Full_x86.exehttp://download.microsoft.com/download/5/6/4/5641DA81-E6FA-4550-9F80-A1D862D9CFAA/dotNetFx40_Full_x86.exe Compressed=no PerMachine=yes Permanent=yes SourceFile=dotNetFx40_Full_x86.exe / -- /PackageGroup /Fragment From: http://wix.codeplex.com/SourceControl/changeset/view/a782416c7fbc#src%2fSetu p%2fBundle%2fNetfx.wxs i.e. should it be changed to just DetectCondition=Netfx4FullVersion OR Netfx4x64FullVersion, because the source is dotNetFx40_Full_x86_x64.exe ? -- 2 -- Also, I am going to try to point to the newest version of .NET 4 - currently 4.0.3 at http://www.microsoft.com/en-us/download/details.aspx?id=29053 Do you think this is better, and will it work? i.e. SourceFile=NDP40-KB2600211-x86-x64.exe DownloadUrl= http://download.microsoft.com/download/3/3/9/3396A3CA-BFE8-4C9B -83D3-CADAE72C17BE/NDP40-KB2600211-x86-x64.exehttp://download.microsoft.com/download/3/3/9/3396A3CA-BFE8-4C9B-83D3-CADAE72C17BE/NDP40-KB2600211-x86-x64.exe Atb, Kristjan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Local file for WixStdbaLicenseUrl
I would use the WixBalExtension's WixStandardBootstrapperApplication element's LicenseFile attribute. Documentation should say something like: Source file of the RTF license file. Cannot be used simultaneously with LicenseUrl. On Sat, Apr 28, 2012 at 3:01 PM, Neil Sleightholm n...@x2systems.comwrote: I would like to use the WixStandardBootstrapperApplication.HyperlinkLicense but reference a local license file rather than an internet URL. I have embedded the license file using this syntax: BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense Payload SourceFile=Resource\License.rtf / /BootstrapperApplicationRef I would have assumed the url would be set like this: WixVariable Id=WixStdbaLicenseUrl Value=file://./License.rtf / But that doesn't work. I can see my file in the .ba1 folder in the temp folder so I know it has been extracted as part of the bundle. Can anyone suggest who I can reference it? Thanks Neil Neil Sleightholm X2 Systems Limited n...@x2systems.commailto:n...@x2systems.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application
If you vowed never to build WiX again, then it probably is not feasible. Burn is in wix\src\burn (burn.build) and as Bob noted if you want wixstdba then you'll need to build wix\src\ext\BalExtension\wixsdtba. Both are in WiX so that will require breaking your vow. smile/ On Sat, Apr 28, 2012 at 2:01 PM, Alexander Lamaison sw...@lammy.co.ukwrote: On 28 April 2012 21:18, Bob Arnson b...@joyofsetup.com wrote: On 28-Apr-12 08:08, Alexander Lamaison wrote: Is there a way round this? Can I easily compile the bootstrapper application myself with VS 2005? You'd have to do the same thing to all of Burn too. Is this feasible? I once tried to build WiX and vowed never ever ever again. Can Burn be built independently of the rest of WiX? -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application
NOTE: Win2k was out of support before WiX v3.6 even started development. We obviously don't test the code there so I really have no idea how much work it will be to make any of the native code built by WiX (Burn, and CustomActions mainly) working on Win2k. On Sun, Apr 29, 2012 at 12:04 AM, Rob Mensching r...@robmensching.comwrote: If you vowed never to build WiX again, then it probably is not feasible. Burn is in wix\src\burn (burn.build) and as Bob noted if you want wixstdba then you'll need to build wix\src\ext\BalExtension\wixsdtba. Both are in WiX so that will require breaking your vow. smile/ On Sat, Apr 28, 2012 at 2:01 PM, Alexander Lamaison sw...@lammy.co.ukwrote: On 28 April 2012 21:18, Bob Arnson b...@joyofsetup.com wrote: On 28-Apr-12 08:08, Alexander Lamaison wrote: Is there a way round this? Can I easily compile the bootstrapper application myself with VS 2005? You'd have to do the same thing to all of Burn too. Is this feasible? I once tried to build WiX and vowed never ever ever again. Can Burn be built independently of the rest of WiX? -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn - MSIPackage InstallCondition evaluates to false, attempts minor upgrade
Oh, well, this is far more advanced scenario than I thought you were trying to accomplish. The way I'd accomplish what you described using Burn is via slipstreaming. You include the MSI and MSP as you have it now but with none of the conditions. Then you have the MSI be the baseline you expect your customers have (like v2.0) and you have the MSP included in the Bundle be the update to go from v2.0 - latest. The patch, hopefully, is relatively small. The final piece is to mark the MSP as a slipstream of the MSI. You can do this by adding the SlipstreamMSP element to the MSI or in the next build, you can specify the MSP is a Slipstream=yes (or something like that) and it will slipstream the other way around. The end result is a constant (stable) evaluation that installs the baseline+MSP in one transaction if the baseline is not on the machine (aka: nothing installed or older version installed) or installs only the MSP if the basline is already on the machine. Using slipstreaming is a 300-level concept in Burn that definitely needs documentation. On Fri, Apr 27, 2012 at 4:13 AM, Pally Sandher pally.sand...@iesve.comwrote: Ah I probably wasn't clear. v1 had Product Code A, v2 has Product Code B. Hence I have a upgrade patch for versions 2.0 or 2.1 - 2.2 while a Major Upgrade for 1.x - 2.x Patching works fine now with Burn using the MSP, however for anyone who doesn't have any version of this product installed or has v1.x I would like to be able to have Burn run the Major Upgrade. Currently I can't do this because if they have v2.x installed, it first attempts a Minor Upgrade with the MSI first then tries to update using the MSP. Since both packages are downloaded rather than embedded, it unnecessarily downloads a 760 MB MSI followed by the required 360 MB MSP. Right now the solution is to leave the MSI out of the Burn bundle ask users to deal with it manually. Not an optimal solution but if I can't get Burn doing what we need it to, it'll have to do. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 26 April 2012 22:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn - MSIPackage InstallCondition evaluates to false, attempts minor upgrade Uhh, you can't Major Upgrade if the ProductCode is the same. I'm confused. People (maybe not you) have been asking for support for support for Minor Updates for a long time. Burn automatically handles it when an MSI doesn't change it's ProductCode but has a higher version. Burn also notifies the BA when a higher version of the MSI (Minor Update or Major Upgrade MSIs) is already present on the machine as a downgrade. I also don't understand the comment about patching. You can include patches in Burn and it will install them. You can even slipstream MSPs and Burn will be able to install the original MSI and the MSP in one transaction if the MSI isn't present already and only install the MSP if the MSI is already installed. It's really cool. On Thu, Apr 26, 2012 at 8:06 AM, Pally Sandher pally.sand...@iesve.com wrote: Not too bothered about 3 so I'll ignore it for now. Just mentioned it as one our QA guys noticed it today. Regarding 4, I do have the same product code higher version however my Upgrade Table code looks like the following: Upgrade Id=removed !--Original Shared Content UpgradeCode reinstated. This should never change-- UpgradeVersion Minimum=2.2.0 IncludeMinimum=yes OnlyDetect=yes Property=NEWERVERSIONDETECTED / UpgradeVersion Minimum=1.0.0 IncludeMinimum=yes Maximum=1.9.9 IncludeMaximum=yes IgnoreRemoveFailure=no OnlyDetect=no Property=OLDERVERSIONBEINGUPGRADED / /Upgrade Burn is trying to be too clever for its own good changing the expected behaviour. I create a patch to upgrade from 2.0 or 2.1 to 2.2 as it's less than half the size of the full installer I don't want to make users download something they don't need. Forcing someone to use a Minor Upgrade when they actually want either Major Upgrade or disallow installation seems rather counter-intuitive. I'll raise bugs in the SourceForge tracker for the other issues. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer
Re: [WiX-users] Wix 3.6 Bootstrapper Issues
Unfortunately, the log file seems to have been lost in transit. Can you place it in email. Or maybe, take a look at the log file and if there appears to be a unique error open a bug? On Thu, Apr 26, 2012 at 10:44 PM, Anirban Paul ani.banti.24...@gmail.comwrote: I have attached the log file. Please find the attachment. On Fri, Apr 27, 2012 at 11:03 AM, Rob Mensching r...@robmensching.com wrote: Log file is created in %TEMP% by default. On Thu, Apr 26, 2012 at 9:56 PM, Anirban Paul ani.banti.24...@gmail.com wrote: I downloaded wix36.exe and installed Wix Toolset V3.6.2221.0. The uninstallation UI does not specify anything about the log file when the uninstall operation fails. Please let me know how to generate the log file in this scenario. Anirban On Thu, Apr 26, 2012 at 8:00 PM, Rob Mensching r...@robmensching.com wrote: Please provide the log file. On Wed, Apr 25, 2012 at 11:00 PM, Anirban Paul ani.banti.24...@gmail.com wrote: As you said, I downloaded the WiX v3.6 RC0 (Released: Apr 3 2012) and tried to uninstall the already installed version ( Wix Toolset V3.6.2221.0 ) of Wix. But that version is not getting uninstalled!!! Currently Wix Toolset V3.6.2221.0 is installed in my computer. But I failed to uninstall the version. Whenever I go to Add Remove Program and click on the Remove button of Wix Toolset V3.6.2221.0, It says Failed to unistall Please help. On Thu, Apr 26, 2012 at 11:04 AM, Anirban Paul ani.banti.24...@gmail.com wrote: Ok I shall try that and get back to you. But let me know the wix variable names that are used to set bootstrapper dialog title and bootstrapper dialog icon. On Thu, Apr 26, 2012 at 10:53 AM, Rob Mensching r...@robmensching.com wrote: Sounds like you are using an old version. Upgrade to latest build for all that to work. On Wed, Apr 25, 2012 at 9:15 PM, Anirban Paul ani.banti.24...@gmail.com wrote: Hi, I have created a bootstrapper (using burn in visual studio 2010) which installs .Net framework4 as prerequisite and then installs the actual msi. Following are the problem that I am facing and I really need your help to resolve those problems. 1 I don't want the bootstrapper to have an entry in Add Remove Program;so I am not using Name attribute in Bundle tag. But as a result of that, my bootstrapper dialog displays only the text Setup. Please let me know is there any way to set the title text without specifying Name attribute in Bundle tag. 2 I am unable to set the icon of bootstrapper dialog. How to do this? 3 The bootstrapper exe is working fine but whenever I try to cancel the installation in midway the bootstrapper crashes. Is that a bug in Win 3.6 or I am doing something wrong? Please help me to resolve these problems. Thanks in advance. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the
Re: [WiX-users] Customising a bootstrapper theme
Can you double check and make sure you are using a matching Theme with what is in the build? The identifiers may have changed in recent builds. That's really my only guess. There is nothing magical about the default theme files. They are carried as is with wixstdba. If you copy them, then you have exactly the same thing... Have you tried debugging wixstdba and the launching of the link to see what is going on there? On Thu, Apr 26, 2012 at 12:57 AM, Bertrand D bertrand.w...@yahoo.comwrote: As previously stated in my previous thread (but not clearly as I had actually two different issues) when I try to use a customized theme for the bootstrapper some events are not processed at least for the failure dialog. I haven't checked with the other ones. This is what I used: bal:WixStandardBootstrapperApplication ThemeFile=..\themes\fr\RtfTheme.xml LocalizationFile=..\themes\fr\RtfTheme.wxl LicenseFile=..\themes\fr\license.rtf LogoFile=..\themes\fr\logoFB.jpg SuppressOptionsUI=yes / Every time I set ThemeFile in the failure dialog the link FailureLogFileLink and the close button have no effect. Please note that the ThemeFile file (RtfTheme.xml) was simply copied from the src\ext\BalExtension\wixstdba\Resources. No customization was made (yet). If I modify the content of the ThemeFile file the changes are correctly taken in account but the issues remain. Using a variable WixStdbaThemeXml instead of using ThemeFile gives me the same result. Everyting works fine if I simply use (without WixStdbaThemeXml) : bal:WixStandardBootstrapperApplication LocalizationFile=..\themes\fr\RtfTheme.wxl LicenseFile=..\themes\fr\license.rtf LogoFile=..\themes\fr\logoFB.jpg SuppressOptionsUI=yes / I used the WiX Toolset v3.6.2809.0. What did I miss? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Customising-a-bootstrapper-theme-tp7501905p7501905.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn - Combined x86/x64 package
Nothing in the engine to do that so the BA would have to handle this case. Unfortunately, there is nothing in wixstdba to handle this case today. Seems like a bit of a gap given the way ProgramFilesFolder and the 64-bit variant works. Feel free to open a bug. On Tue, Apr 24, 2012 at 7:05 AM, Neil Sleightholm n...@x2systems.comwrote: Thanks for the quick reply but this is for a Burn package rather than a standard MSI. Neil -Original Message- From: Osanger, Martin [mailto:martin.osan...@fabasoft.com] Sent: 24 April 2012 14:48 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn - Combined x86/x64 package Hello, If i don't missunderstood you, you can set a property with the correct path before installation was triggered. e.g: Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLDIR . CustomAction Id=SetX64Folder Directory=INSTALLDIR Value=[ProgramFiles64Folder] / CustomAction Id=SetX86Folder Directory=INSTALLDIR Value=[ProgramFilesFolder] / Custom Action= SetX64Folder After=CostFinalizeVersionNT64/Custom Custom Action= SetX86Folder After=CostFinalizeNOT VersionNT64/Custom kind regards, Martin -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Dienstag, 24. April 2012 15:01 To: General toolset. (wix-users@lists.sourceforge.net) Subject: [WiX-users] Burn - Combined x86/x64 package I have created a combined x86 and x64 package by setting the InstallCondition of my MsiPackages to NOT VersionNT64 or VersionNT64 respectively. This works ok but I can't see how to set the InstallFolder variable so that it is correct for the options dialog in the StdBA (I can set it correctly for the install by just using 2 variables but the options dialog references InstallFolder). Does anyone know how to do this? What I would like is a condition associated with the variable but can't see how to do that. Thanks Neil Neil Sleightholm X2 Systems Limited n...@x2systems.commailto:n...@x2systems.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Local file for WixStdbaLicenseUrl
Not sure I explained this correctly, I don't want to display the licence file on the UI (more correctly it should have been called License.htm) I want it to be in the bundle and displayed in a browser if the user clicks the link but not be a reference to a file on the internet (like the WiX distribution does). Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 29 April 2012 08:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Local file for WixStdbaLicenseUrl I would use the WixBalExtension's WixStandardBootstrapperApplication element's LicenseFile attribute. Documentation should say something like: Source file of the RTF license file. Cannot be used simultaneously with LicenseUrl. On Sat, Apr 28, 2012 at 3:01 PM, Neil Sleightholm n...@x2systems.comwrote: I would like to use the WixStandardBootstrapperApplication.HyperlinkLicense but reference a local license file rather than an internet URL. I have embedded the license file using this syntax: BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense Payload SourceFile=Resource\License.rtf / /BootstrapperApplicationRef I would have assumed the url would be set like this: WixVariable Id=WixStdbaLicenseUrl Value=file://./License.rtf / But that doesn't work. I can see my file in the .ba1 folder in the temp folder so I know it has been extracted as part of the bundle. Can anyone suggest who I can reference it? Thanks Neil Neil Sleightholm X2 Systems Limited n...@x2systems.commailto:n...@x2systems.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn - Combined x86/x64 package
I did find a work around: util:RegistrySearch Id=RegistrySearch32 Condition=NOT VersionNT64 Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion Value=ProgramFilesDir Variable=PlatformProgramFilesFolder / util:RegistrySearch Id=RegistrySearch64 Condition=VersionNT64 Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion Value=ProgramFilesDir Variable=PlatformProgramFilesFolder Win64=yes / Variable Name=InstallFolder Type=string Value=[PlatformProgramFilesFolder]\ACME\MyApp / I think the ideal you be if ProgramFiles64Folder returned ProgramFilesFolder on x86 (I think this is how it works in Windows Installer). Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 29 April 2012 08:21 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn - Combined x86/x64 package Nothing in the engine to do that so the BA would have to handle this case. Unfortunately, there is nothing in wixstdba to handle this case today. Seems like a bit of a gap given the way ProgramFilesFolder and the 64-bit variant works. Feel free to open a bug. -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Dienstag, 24. April 2012 15:01 To: General toolset. (wix-users@lists.sourceforge.net) Subject: [WiX-users] Burn - Combined x86/x64 package I have created a combined x86 and x64 package by setting the InstallCondition of my MsiPackages to NOT VersionNT64 or VersionNT64 respectively. This works ok but I can't see how to set the InstallFolder variable so that it is correct for the options dialog in the StdBA (I can set it correctly for the install by just using 2 variables but the options dialog references InstallFolder). Does anyone know how to do this? What I would like is a condition associated with the variable but can't see how to do that. Thanks Neil Neil Sleightholm X2 Systems Limited n...@x2systems.commailto:n...@x2systems.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Local file for WixStdbaLicenseUrl
Oh, sorry, I answered the question the wrong way. Use LicenseUrl attribute on the WixStandardBootstrapperApplication element and use the same relative path that you use to add the Payload. On Sun, Apr 29, 2012 at 1:26 AM, Neil Sleightholm n...@x2systems.comwrote: Not sure I explained this correctly, I don't want to display the licence file on the UI (more correctly it should have been called License.htm) I want it to be in the bundle and displayed in a browser if the user clicks the link but not be a reference to a file on the internet (like the WiX distribution does). Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 29 April 2012 08:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Local file for WixStdbaLicenseUrl I would use the WixBalExtension's WixStandardBootstrapperApplication element's LicenseFile attribute. Documentation should say something like: Source file of the RTF license file. Cannot be used simultaneously with LicenseUrl. On Sat, Apr 28, 2012 at 3:01 PM, Neil Sleightholm n...@x2systems.com wrote: I would like to use the WixStandardBootstrapperApplication.HyperlinkLicense but reference a local license file rather than an internet URL. I have embedded the license file using this syntax: BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense Payload SourceFile=Resource\License.rtf / /BootstrapperApplicationRef I would have assumed the url would be set like this: WixVariable Id=WixStdbaLicenseUrl Value=file://./License.rtf / But that doesn't work. I can see my file in the .ba1 folder in the temp folder so I know it has been extracted as part of the bundle. Can anyone suggest who I can reference it? Thanks Neil Neil Sleightholm X2 Systems Limited n...@x2systems.commailto:n...@x2systems.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Local file for WixStdbaLicenseUrl
Actually I looked at the source and realised the problem. If you don't specify a protocol it assumes the file is local, therefore the correct syntax is: BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense Payload SourceFile=Resource\License.htm / /BootstrapperApplicationRef WixVariable Id=WixStdbaLicenseUrl Value=License.htm / Must remember - use the source Luke! Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 29 April 2012 10:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Local file for WixStdbaLicenseUrl Oh, sorry, I answered the question the wrong way. Use LicenseUrl attribute on the WixStandardBootstrapperApplication element and use the same relative path that you use to add the Payload. On Sun, Apr 29, 2012 at 1:26 AM, Neil Sleightholm n...@x2systems.comwrote: Not sure I explained this correctly, I don't want to display the licence file on the UI (more correctly it should have been called License.htm) I want it to be in the bundle and displayed in a browser if the user clicks the link but not be a reference to a file on the internet (like the WiX distribution does). Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 29 April 2012 08:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Local file for WixStdbaLicenseUrl I would use the WixBalExtension's WixStandardBootstrapperApplication element's LicenseFile attribute. Documentation should say something like: Source file of the RTF license file. Cannot be used simultaneously with LicenseUrl. On Sat, Apr 28, 2012 at 3:01 PM, Neil Sleightholm n...@x2systems.com wrote: I would like to use the WixStandardBootstrapperApplication.HyperlinkLicense but reference a local license file rather than an internet URL. I have embedded the license file using this syntax: BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense Payload SourceFile=Resource\License.rtf / /BootstrapperApplicationRef I would have assumed the url would be set like this: WixVariable Id=WixStdbaLicenseUrl Value=file://./License.rtf / But that doesn't work. I can see my file in the .ba1 folder in the temp folder so I know it has been extracted as part of the bundle. Can anyone suggest who I can reference it? Thanks Neil Neil Sleightholm X2 Systems Limited n...@x2systems.commailto:n...@x2systems.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application
'Out of support' is just a marketing term. It doesn't mean it magically stops working. People forget that often. Alex On 29 April 2012 08:06, Rob Mensching r...@robmensching.com wrote: NOTE: Win2k was out of support before WiX v3.6 even started development. We obviously don't test the code there so I really have no idea how much work it will be to make any of the native code built by WiX (Burn, and CustomActions mainly) working on Win2k. On Sun, Apr 29, 2012 at 12:04 AM, Rob Mensching r...@robmensching.comwrote: If you vowed never to build WiX again, then it probably is not feasible. Burn is in wix\src\burn (burn.build) and as Bob noted if you want wixstdba then you'll need to build wix\src\ext\BalExtension\wixsdtba. Both are in WiX so that will require breaking your vow. smile/ On Sat, Apr 28, 2012 at 2:01 PM, Alexander Lamaison sw...@lammy.co.ukwrote: On 28 April 2012 21:18, Bob Arnson b...@joyofsetup.com wrote: On 28-Apr-12 08:08, Alexander Lamaison wrote: Is there a way round this? Can I easily compile the bootstrapper application myself with VS 2005? You'd have to do the same thing to all of Burn too. Is this feasible? I once tried to build WiX and vowed never ever ever again. Can Burn be built independently of the rest of WiX? -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Local file for WixStdbaLicenseUrl
At least until the documentation is updated to be correct. smile/ On Sun, Apr 29, 2012 at 2:54 AM, Neil Sleightholm n...@x2systems.comwrote: Actually I looked at the source and realised the problem. If you don't specify a protocol it assumes the file is local, therefore the correct syntax is: BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense Payload SourceFile=Resource\License.htm / /BootstrapperApplicationRef WixVariable Id=WixStdbaLicenseUrl Value=License.htm / Must remember - use the source Luke! Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 29 April 2012 10:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Local file for WixStdbaLicenseUrl Oh, sorry, I answered the question the wrong way. Use LicenseUrl attribute on the WixStandardBootstrapperApplication element and use the same relative path that you use to add the Payload. On Sun, Apr 29, 2012 at 1:26 AM, Neil Sleightholm n...@x2systems.com wrote: Not sure I explained this correctly, I don't want to display the licence file on the UI (more correctly it should have been called License.htm) I want it to be in the bundle and displayed in a browser if the user clicks the link but not be a reference to a file on the internet (like the WiX distribution does). Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 29 April 2012 08:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Local file for WixStdbaLicenseUrl I would use the WixBalExtension's WixStandardBootstrapperApplication element's LicenseFile attribute. Documentation should say something like: Source file of the RTF license file. Cannot be used simultaneously with LicenseUrl. On Sat, Apr 28, 2012 at 3:01 PM, Neil Sleightholm n...@x2systems.com wrote: I would like to use the WixStandardBootstrapperApplication.HyperlinkLicense but reference a local license file rather than an internet URL. I have embedded the license file using this syntax: BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.HyperlinkLicense Payload SourceFile=Resource\License.rtf / /BootstrapperApplicationRef I would have assumed the url would be set like this: WixVariable Id=WixStdbaLicenseUrl Value=file://./License.rtf / But that doesn't work. I can see my file in the .ba1 folder in the temp folder so I know it has been extracted as part of the bundle. Can anyone suggest who I can reference it? Thanks Neil Neil Sleightholm X2 Systems Limited n...@x2systems.commailto:n...@x2systems.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security
Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application
No, we don't forget that. However, at some point you have to trim your tail or you end up with an enormous support burden that prevents you from moving forward. One of the big questions for us in WiX v3.7 is how many versions of VS should we support? It is expensive to keep VS2005 and VS2008 working because they use the inferior MSBuild 2.0 and MSBuild 3.5. Cutting VS2005 and VS2008 cuts a big chunk of our tail and would allow us to do more stuff. In WiX v4.0 I'm pretty sure we support only VS2010 and VS11 (whatever they end up calling that). In WiX v4.0 the big question is do we support Windows XP? VC just dropped support for in in VS11. I hesitate to cut Windows XP support because it is still very popular... but it too is going out of support very soon. These are never easy decisions. On Sun, Apr 29, 2012 at 3:42 AM, Alexander Lamaison sw...@lammy.co.ukwrote: 'Out of support' is just a marketing term. It doesn't mean it magically stops working. People forget that often. Alex On 29 April 2012 08:06, Rob Mensching r...@robmensching.com wrote: NOTE: Win2k was out of support before WiX v3.6 even started development. We obviously don't test the code there so I really have no idea how much work it will be to make any of the native code built by WiX (Burn, and CustomActions mainly) working on Win2k. On Sun, Apr 29, 2012 at 12:04 AM, Rob Mensching r...@robmensching.com wrote: If you vowed never to build WiX again, then it probably is not feasible. Burn is in wix\src\burn (burn.build) and as Bob noted if you want wixstdba then you'll need to build wix\src\ext\BalExtension\wixsdtba. Both are in WiX so that will require breaking your vow. smile/ On Sat, Apr 28, 2012 at 2:01 PM, Alexander Lamaison sw...@lammy.co.uk wrote: On 28 April 2012 21:18, Bob Arnson b...@joyofsetup.com wrote: On 28-Apr-12 08:08, Alexander Lamaison wrote: Is there a way round this? Can I easily compile the bootstrapper application myself with VS 2005? You'd have to do the same thing to all of Burn too. Is this feasible? I once tried to build WiX and vowed never ever ever again. Can Burn be built independently of the rest of WiX? -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application
Is that not the wrong question? Rather than getting caught up in the ins and outs of which version to support, why not adopt methods that remove the decision entirely? Have you considered using CMake, for example, which generates build files for a vast range of build platforms (including VS 6 - 11)? Basically, you outsource the burden of supporting the long tail to CMake. If a *project* limits itself to a certain platform, then so be it. But its build tools certainly shouldn't. WiX has the double problem of being, itself, a build tool so should neither be limited to a certain platform by its own build tools nor limit projects that use it. Alex On 29 April 2012 18:24, Rob Mensching r...@robmensching.com wrote: No, we don't forget that. However, at some point you have to trim your tail or you end up with an enormous support burden that prevents you from moving forward. One of the big questions for us in WiX v3.7 is how many versions of VS should we support? It is expensive to keep VS2005 and VS2008 working because they use the inferior MSBuild 2.0 and MSBuild 3.5. Cutting VS2005 and VS2008 cuts a big chunk of our tail and would allow us to do more stuff. In WiX v4.0 I'm pretty sure we support only VS2010 and VS11 (whatever they end up calling that). In WiX v4.0 the big question is do we support Windows XP? VC just dropped support for in in VS11. I hesitate to cut Windows XP support because it is still very popular... but it too is going out of support very soon. These are never easy decisions. On Sun, Apr 29, 2012 at 3:42 AM, Alexander Lamaison sw...@lammy.co.ukwrote: 'Out of support' is just a marketing term. It doesn't mean it magically stops working. People forget that often. Alex On 29 April 2012 08:06, Rob Mensching r...@robmensching.com wrote: NOTE: Win2k was out of support before WiX v3.6 even started development. We obviously don't test the code there so I really have no idea how much work it will be to make any of the native code built by WiX (Burn, and CustomActions mainly) working on Win2k. On Sun, Apr 29, 2012 at 12:04 AM, Rob Mensching r...@robmensching.com wrote: If you vowed never to build WiX again, then it probably is not feasible. Burn is in wix\src\burn (burn.build) and as Bob noted if you want wixstdba then you'll need to build wix\src\ext\BalExtension\wixsdtba. Both are in WiX so that will require breaking your vow. smile/ On Sat, Apr 28, 2012 at 2:01 PM, Alexander Lamaison sw...@lammy.co.uk wrote: On 28 April 2012 21:18, Bob Arnson b...@joyofsetup.com wrote: On 28-Apr-12 08:08, Alexander Lamaison wrote: Is there a way round this? Can I easily compile the bootstrapper application myself with VS 2005? You'd have to do the same thing to all of Burn too. Is this feasible? I once tried to build WiX and vowed never ever ever again. Can Burn be built independently of the rest of WiX? -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching -
[WiX-users] Protect installed msi files
Hello again When I used to create my msis through Visual Studio Setup and Deployment projects then these installers protected the files that got installed i.e. if I installed the application and then manually deleted a file (such as an included image content file) then when the next time the main executable was run this deleted file got restored i.e. the msi was found in the Windows store and it repaired my installation. With Wix this protection is not present any more. I think that is better for some of the (optional) files that are installed, but I would like to protect some of my dll's as before - do you know how I could do that in Wix? Atb, Kristjan P.S. My msi's were always per machine, but now are per user, so this may be the difference that is actually causing the lack of protection? If that is the case, is it still possible to protect certain File / Component / Feature elements when deploying per user msi's ? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Protect installed msi files
Self-healing is a feature of the Windows Installer. There are several ways to get it to kick in. The most common is through Advertised entry points. You might decompile your old VS setup/deployment project and see if it has things Advertised or otherwise organized differently. You could also get a verbose log file from the repair operations and see what was used in the past to kick off the self-healing. On Sun, Apr 29, 2012 at 2:01 PM, Kristjan Laane kristjan.la...@gmail.comwrote: Hello again When I used to create my msis through Visual Studio Setup and Deployment projects then these installers protected the files that got installed i.e. if I installed the application and then manually deleted a file (such as an included image content file) then when the next time the main executable was run this deleted file got restored i.e. the msi was found in the Windows store and it repaired my installation. With Wix this protection is not present any more. I think that is better for some of the (optional) files that are installed, but I would like to protect some of my dll's as before - do you know how I could do that in Wix? Atb, Kristjan P.S. My msi's were always per machine, but now are per user, so this may be the difference that is actually causing the lack of protection? If that is the case, is it still possible to protect certain File / Component / Feature elements when deploying per user msi's ? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application
I fundamentally agree with you. However, building the code for a particular platform is the easiest part of the problem. Keeping the code working (since the platforms differ in subtle ways) is the real challenge. Personally, supporting unsupported platforms is very low on my priority list. I have enough trouble keeping WinXP support working (aka: tested). That platform is still supported and *very* popular. If you want to sign up to contribute the fixes and maintain WiX toolset working on Win2k then I'd love to see the changesets. However, to be completely transparent I'm not really excited about delaying the release of WiX v3.6 for an unsupported platform. There are too many people already looking forward to WiX v3.6 being done now. Thus if Win2k requries radical redesign that's something we'd need to look at for next release. On Sun, Apr 29, 2012 at 10:54 AM, Alexander Lamaison sw...@lammy.co.ukwrote: Is that not the wrong question? Rather than getting caught up in the ins and outs of which version to support, why not adopt methods that remove the decision entirely? Have you considered using CMake, for example, which generates build files for a vast range of build platforms (including VS 6 - 11)? Basically, you outsource the burden of supporting the long tail to CMake. If a *project* limits itself to a certain platform, then so be it. But its build tools certainly shouldn't. WiX has the double problem of being, itself, a build tool so should neither be limited to a certain platform by its own build tools nor limit projects that use it. Alex On 29 April 2012 18:24, Rob Mensching r...@robmensching.com wrote: No, we don't forget that. However, at some point you have to trim your tail or you end up with an enormous support burden that prevents you from moving forward. One of the big questions for us in WiX v3.7 is how many versions of VS should we support? It is expensive to keep VS2005 and VS2008 working because they use the inferior MSBuild 2.0 and MSBuild 3.5. Cutting VS2005 and VS2008 cuts a big chunk of our tail and would allow us to do more stuff. In WiX v4.0 I'm pretty sure we support only VS2010 and VS11 (whatever they end up calling that). In WiX v4.0 the big question is do we support Windows XP? VC just dropped support for in in VS11. I hesitate to cut Windows XP support because it is still very popular... but it too is going out of support very soon. These are never easy decisions. On Sun, Apr 29, 2012 at 3:42 AM, Alexander Lamaison sw...@lammy.co.uk wrote: 'Out of support' is just a marketing term. It doesn't mean it magically stops working. People forget that often. Alex On 29 April 2012 08:06, Rob Mensching r...@robmensching.com wrote: NOTE: Win2k was out of support before WiX v3.6 even started development. We obviously don't test the code there so I really have no idea how much work it will be to make any of the native code built by WiX (Burn, and CustomActions mainly) working on Win2k. On Sun, Apr 29, 2012 at 12:04 AM, Rob Mensching r...@robmensching.com wrote: If you vowed never to build WiX again, then it probably is not feasible. Burn is in wix\src\burn (burn.build) and as Bob noted if you want wixstdba then you'll need to build wix\src\ext\BalExtension\wixsdtba. Both are in WiX so that will require breaking your vow. smile/ On Sat, Apr 28, 2012 at 2:01 PM, Alexander Lamaison sw...@lammy.co.uk wrote: On 28 April 2012 21:18, Bob Arnson b...@joyofsetup.com wrote: On 28-Apr-12 08:08, Alexander Lamaison wrote: Is there a way round this? Can I easily compile the bootstrapper application myself with VS 2005? You'd have to do the same thing to all of Burn too. Is this feasible? I once tried to build WiX and vowed never ever ever again. Can Burn be built independently of the rest of WiX? -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT
Re: [WiX-users] Wix 3.6 Bootstrapper Issues
Following is the content of log file
[0EDC:0810][2012-04-27T11:14:00]: Burn v3.6.2221.0, path: C:\Documents and
Settings\All Users\Application Data\Package
Cache\{afd874f6-129a-4fc6-9646-284d80072674}\WiX36.exe, cmdline:
'/uninstall'
[0EDC:0810][2012-04-27T11:14:00]: Setting string variable 'WixBundleName'
to value 'WiX Toolset v3.6.2221.0'
[0EDC:0810][2012-04-27T11:14:00]: Setting string variable 'WixBundleLog' to
value
'C:\DOCUME~1\ANIRBA~1.SAR\LOCALS~1\Temp\WiX_Toolset_v3.6.2221.0_20120427111400.log'
[0EDC:0810][2012-04-27T11:14:00]: Loading managed bootstrapper application.
[0EDC:0810][2012-04-27T11:14:01]: Detect 3 packages
[0EDC:0810][2012-04-27T11:14:01]: Setting string variable
'Netfx4x64FullVersion' to value '4.0.30319'
[0EDC:0810][2012-04-27T11:14:01]: Registry key not found. Key =
'SOFTWARE\Microsoft\VisualStudio\8.0'
[0EDC:0810][2012-04-27T11:14:01]: Setting string variable
'Netfx4FullVersion' to value '4.0.30319'
[0EDC:0810][2012-04-27T11:14:01]: Condition 'Netfx4FullVersion AND (NOT
VersionNT64 OR Netfx4x64FullVersion)' evaluates to true.
[0EDC:0810][2012-04-27T11:14:01]: Detected package: Netfx4Full, state:
Present, cached: No
[0EDC:0810][2012-04-27T11:14:01]: Detected package: ProjectAggregator2,
state: Absent, cached: No
[0EDC:0810][2012-04-27T11:14:01]: Detected package: Wix, state: Present,
cached: Yes
[0EDC:0810][2012-04-27T11:14:01]: Detect complete, result: 0x0
[0EDC:0810][2012-04-27T11:14:01]: Plan 3 packages, action: Uninstall
[0EDC:0810][2012-04-27T11:14:01]: Setting string variable
'WixBundleLog_Wix' to value
'C:\DOCUME~1\ANIRBA~1.SAR\LOCALS~1\Temp\WiX_Toolset_v3.6.2221.0_20120427111400_0_Wix.log'
[0EDC:0810][2012-04-27T11:14:01]: Setting string variable
'WixBundleRollbackLog_Wix' to value
'C:\DOCUME~1\ANIRBA~1.SAR\LOCALS~1\Temp\WiX_Toolset_v3.6.2221.0_20120427111400_0_Wix_rollback.log'
[0EDC:0810][2012-04-27T11:14:01]: Planned package: Wix, state: Present,
default requested: Absent, ux requested: Absent, execute: Uninstall,
rollback: Install, cache: No, uncache: Yes, dependency: Unregister
[0EDC:0810][2012-04-27T11:14:01]: Planned package: ProjectAggregator2,
state: Absent, default requested: Absent, ux requested: Absent, execute:
None, rollback: None, cache: No, uncache: No, dependency: Unregister
[0EDC:0810][2012-04-27T11:14:01]: Setting string variable
'WixBundleRollbackLog_Netfx4Full' to value
'C:\DOCUME~1\ANIRBA~1.SAR\LOCALS~1\Temp\WiX_Toolset_v3.6.2221.0_20120427111400_1_Netfx4Full_rollback.log'
[0EDC:0810][2012-04-27T11:14:01]: Planned package: Netfx4Full, state:
Present, default requested: Absent, ux requested: Absent, execute: None,
rollback: Install, cache: Yes, uncache: Yes, dependency: Register
[0EDC:0810][2012-04-27T11:14:01]: Plan complete, result: 0x0
[0EDC:0810][2012-04-27T11:14:01]: Apply begin
[0EDC:0C20][2012-04-27T11:14:02]: Download engine HTTP 200 HEAD to
http://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6-BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exe
[0EDC:0C20][2012-04-27T11:14:03]: Download engine HTTP 200 GET to
http://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6-BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exe
[0298:0A88][2012-04-27T11:14:03]: Error 0x800b0003: Failed authenticode
verification of payload:
C:\DOCUME~1\ANIRBA~1.SAR\LOCALS~1\Temp\{afd874f6-129a-4fc6-9646-284d80072674}\Netfx4Full
[0298:0A88][2012-04-27T11:14:03]: Error 0x800b0003: Failed to verify
payload signature: C:\Documents and Settings\All Users\Application
Data\Package
Cache\58DA3D74DB353AAD03588CBB5CEA8234166D8B99\dotNetFx40_Full_x86_x64.exe
[0298:0A88][2012-04-27T11:14:03]: Error 0x800b0003: Failed to cache payload.
[0EDC:0C20][2012-04-27T11:14:03]: Failed to cache payload: Netfx4Full from
working path:
C:\DOCUME~1\ANIRBA~1.SAR\LOCALS~1\Temp\{afd874f6-129a-4fc6-9646-284d80072674}\Netfx4Full,
error: 0x800b0003.
[0EDC:0C20][2012-04-27T11:14:03]: Error 0x800b0003: Failed to cache
packages.
[0EDC:0810][2012-04-27T11:14:03]: Error 0x800b0003: Failed while waiting
for cache thread to complete before executing.
[0EDC:0810][2012-04-27T11:14:03]: Apply complete, result: 0x800b0003
restart: No
[0EDC:0810][2012-04-27T11:14:06]: Shutting down, exit code: 0x0
On Sun, Apr 29, 2012 at 12:46 PM, Rob Mensching r...@robmensching.comwrote:
Unfortunately, the log file seems to have been lost in transit. Can you
place it in email. Or maybe, take a look at the log file and if there
appears to be a unique error open a bug?
On Thu, Apr 26, 2012 at 10:44 PM, Anirban Paul ani.banti.24...@gmail.com
wrote:
I have attached the log file. Please find the attachment.
On Fri, Apr 27, 2012 at 11:03 AM, Rob Mensching r...@robmensching.com
wrote:
Log file is created in %TEMP% by default.
On Thu, Apr 26, 2012 at 9:56 PM, Anirban Paul
ani.banti.24...@gmail.com
wrote:
I downloaded wix36.exe and installed Wix Toolset V3.6.2221.0. The
uninstallation UI does not specify anything about the log file when
the
uninstall operation fails. Please let me know
