[WiX-users] Is it possible to add an existing file to Visual Studio WiX Setup project without it making a local copy?
I have a setup project in which I have file called ProjectManifest.wxs which contains a Fragment declaring a PackageGroup for my MsiPackage and also sets up some registry searches for some prerequisites for my msi. I also have a bootstrapper project that uses this ProjectManifest.wxs file so that it can simply use the PackageGroupRef in its chain element. I have made this separation so that the same msi (and it's prerequisites) can be consumed by another bundle which bundles a suite of related applications (also it keeps the mark-up in my bootstrapper clean). The problem I have is that when I Add-Existing Item to my bootstrapper project and point it at the ProjectManifest.wxs file it takes a copy of that file and places it in the bootstrapper project folder. This is causing me to have multiple copies of the same file and consequently is a source revision control nightmare. Is there any way to reference an existing file from a bootstrapper project without it taking a 'local' copy? I'm using WiX v3.6 and Visual Studio 2010. Many thanks, David -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is it possible to add an existing file to Visual Studio WiX Setup project without it making a local copy?
I used to use a wixlib project but when I added multiplatform projects and tried to use MSBuild directly for my build process I had problems with a x64 project failing due to a dependency on the wixlib project (which had already been built) but would not build with platform set to x64. So for wxs file I have a 'CommonSrc' project. (A MSI setup project works, but is never built.) I use this project only to edit the wxs as needed (with comments in the wxs indicating that it should only be edited in the CommonSrc project). I then run a script file which copies the file to each project where this wxs file is needed. (Not exactly what you are asking for, but since I only edit the file in the 'CommonSrc' location I no longer have confusion related to managing the various copies.) For wxi files that are common I place them in a common Include folder, and add the following to the project file. CompilerAdditionalOptions -I$(ReleaseVersionedProjectRoot)\Common\Src\Includes /CompilerAdditionalOptions Then at the top of the one wxi file that I have in each project I add the following. ?include commonIncludes.wxi ? The various wxs files include this local wix file, and by extension have access to the information in my various common wxi file. Again not exactly what you are looking for, but maybe it can help. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Is-it-possible-to-add-an-existing-file-to-Visual-Studio-WiX-Setup-project-without-it-making-a-local--tp7595113p7595114.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is it possible to add an existing file to Visual Studio WiX Setup project without it making a local copy?
You can also do this by right clicking on the project and Add -- Existing Item.. When you find the file you want, don't double click, go down to the Add button and you will notice a tiny arrow to the right, click and then select Add As Link. That should do it, and eliminates having to modify pesky xml files :) -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: June-09-14 8:51 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is it possible to add an existing file to Visual Studio WiX Setup project without it making a local copy? I used to use a wixlib project but when I added multiplatform projects and tried to use MSBuild directly for my build process I had problems with a x64 project failing due to a dependency on the wixlib project (which had already been built) but would not build with platform set to x64. So for wxs file I have a 'CommonSrc' project. (A MSI setup project works, but is never built.) I use this project only to edit the wxs as needed (with comments in the wxs indicating that it should only be edited in the CommonSrc project). I then run a script file which copies the file to each project where this wxs file is needed. (Not exactly what you are asking for, but since I only edit the file in the 'CommonSrc' location I no longer have confusion related to managing the various copies.) For wxi files that are common I place them in a common Include folder, and add the following to the project file. CompilerAdditionalOptions -I$(ReleaseVersionedProjectRoot)\Common\Src\Includes /CompilerAdditionalOptions Then at the top of the one wxi file that I have in each project I add the following. ?include commonIncludes.wxi ? The various wxs files include this local wix file, and by extension have access to the information in my various common wxi file. Again not exactly what you are looking for, but maybe it can help. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Is-it-possible-to-add-an-existing-file-to-Visual-Studio-WiX-Setup-project-without-it-making-a-local--tp7595113p7595114.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in torch - wixmst output is not in XML format
Hey Bob, It might be a case of The Mondays but I'm at a loss at what you are getting at :( What are these other files that might get output by torch? How can I supress their output? No typo in this email! ;) -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: June-08-14 10:37 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Bug in torch - wixmst output is not in XML format On 6/8/2014 11:13 AM, Tunney, Stephen wrote: Re: [WiX-users] Bug in torch - wixmst output is not in XML format -xo doesn't produce a text file if there are files in the output (which is pretty often). -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT0136: error importing table 'Upgrade'
Hi Bob; Thanks a lot for the insight. I stared at that and did not pick up on the line feed which had broke the Product/@Version entry. Thanks; Phill -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0136-error-importing-table-Upgrade-tp7595107p7595119.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is it possible to add an existing file to Visual Studio WiX Setup project without it making a local copy?
I've gone for the Add as Link approach which has done the trick nicely. Thanks everyone. David -Original Message- From: Tunney, Stephen [mailto:stephen.tun...@nuance.com] Sent: 09 June 2014 14:09 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Is it possible to add an existing file to Visual Studio WiX Setup project without it making a local copy? You can also do this by right clicking on the project and Add -- Existing Item.. When you find the file you want, don't double click, go down to the Add button and you will notice a tiny arrow to the right, click and then select Add As Link. That should do it, and eliminates having to modify pesky xml files :) -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: June-09-14 8:51 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is it possible to add an existing file to Visual Studio WiX Setup project without it making a local copy? I used to use a wixlib project but when I added multiplatform projects and tried to use MSBuild directly for my build process I had problems with a x64 project failing due to a dependency on the wixlib project (which had already been built) but would not build with platform set to x64. So for wxs file I have a 'CommonSrc' project. (A MSI setup project works, but is never built.) I use this project only to edit the wxs as needed (with comments in the wxs indicating that it should only be edited in the CommonSrc project). I then run a script file which copies the file to each project where this wxs file is needed. (Not exactly what you are asking for, but since I only edit the file in the 'CommonSrc' location I no longer have confusion related to managing the various copies.) For wxi files that are common I place them in a common Include folder, and add the following to the project file. CompilerAdditionalOptions -I$(ReleaseVersionedProjectRoot)\Common\Src\Includes /CompilerAdditionalOptions Then at the top of the one wxi file that I have in each project I add the following. ?include commonIncludes.wxi ? The various wxs files include this local wix file, and by extension have access to the information in my various common wxi file. Again not exactly what you are looking for, but maybe it can help. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Is-it-poss ible-to-add-an-existing-file-to-Visual-Studio-WiX-Setup-project-without- it-making-a-local--tp7595113p7595114.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WIX Burn - Uninstalling MSI package with embedded transform failing
I am using WIX Burn to create the bootstrapper. The payload Chain contains an MSI MyMSIPackage. The MSI have embedded transforms for some 5 different languages. The bootstrapper is able to install and uninstall the MSI in english environment properly. But when I execute it in non-english OS it successfully installs but fails to remove. The Bootstrapper entry from the ARP got removed (so unregistered) but the MSI is not uninstalled. Moreover in the OnDetectRelatedMsiPackage I get RelatedOperation as Downgrade during uninstall. I guess this is because WIX bootstrapper finds mismatched product code. I have gone through lot of WIX threads and it seems that currently BURN doesn't support Instance transformation. Is there a way i can handle this situation? Moreover it a requirement to apply proper transformation to MSI I cannot just install using property ProductLanguage=1033 i.e., english. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WIX-Burn-Uninstalling-MSI-package-with-embedded-transform-failing-tp7595121.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
what if at build time I change the name of the MSI to be the same as the original MSI's name and use the same upgrade code? Would that work ? Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079p7595124.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
I do not have direct experience with this issue, but I suspect the thing to do is to leave the new package name as is, but rather author multiple upgrade codes to also remove the old product. http://www.joyofsetup.com/2008/09/07/hint-be-generous-with-upgrade-codes/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079p7595125.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Registering COM objects
Recently we've updated from registering COM objects with .NET 3.5 to registering COM objects with .NET 4.0; however, they seem to not be behaving properly anymore (windows which are supposed to be docked are now floating). Is there something different which must be done for registering COM objects that use .NET 4.0 than what needed to be done for registering COM objects that use .NET 3.5? -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn error when parsing msi version
Wix is allowing me to create msi files with a large number in the fourth version index (6-digit numbers, i.e. 11). I'm trying to use burn to create a bootstrapper which bundles my wix installer. When I include an msi in the bundle which has a fourth version index greater than 65535 (16-bit unsigned) I get MSI parsing errors when executing the bootstrapper. No error pop-up is displayed, the only indication of the parsing error in in the Setup log file. Parsing errors in the Setup log file appear as follows: [25C4:25D0][2014-06-09T14:24:10]i001: Burn v3.8.1128.0, Windows v6.3 (Build 9600: Service Pack 0), path: C:\Users\ejcarpen\Documents\Visual Studio 2010\Projects\Bootstrapper1\Bootstrapper1\bin\Debug\Bootstrapper1.exe, cmdline: '' [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse @Version: 1.0.0.65536 [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse MSI package. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse packages. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to load manifest. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to initialize core. This is reproducible by building an empty setup project with version 1.0.0.65536 and adding it to an empty bootstrapper project Is there a way around this issue? Is it a bug or expected behavior based on MS version handling limitations? I find it strange that wix allows me to build MSI files that the wix bootstrapper can't parse Thanks, -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
This is expected behavior because all of WiX ignores the 4th version number... If you want to test for it, you must do it manually. Carter Quoting Ed ecarp...@gmail.com: Wix is allowing me to create msi files with a large number in the fourth version index (6-digit numbers, i.e. 11). I'm trying to use burn to create a bootstrapper which bundles my wix installer. When I include an msi in the bundle which has a fourth version index greater than 65535 (16-bit unsigned) I get MSI parsing errors when executing the bootstrapper. No error pop-up is displayed, the only indication of the parsing error in in the Setup log file. Parsing errors in the Setup log file appear as follows: [25C4:25D0][2014-06-09T14:24:10]i001: Burn v3.8.1128.0, Windows v6.3 (Build 9600: Service Pack 0), path: C:\Users\ejcarpen\Documents\Visual Studio 2010\Projects\Bootstrapper1\Bootstrapper1\bin\Debug\Bootstrapper1.exe, cmdline: '' [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse @Version: 1.0.0.65536 [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse MSI package. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse packages. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to load manifest. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to initialize core. This is reproducible by building an empty setup project with version 1.0.0.65536 and adding it to an empty bootstrapper project Is there a way around this issue? Is it a bug or expected behavior based on MS version handling limitations? I find it strange that wix allows me to build MSI files that the wix bootstrapper can't parse Thanks, -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
We are okay with WiX ignoring this number for upgrading purposes. We simply attach the build CL in the 4th index so we can trace each MSI back to the point of creation if needed The problem seems to be that Burn can't parse MSI files which fill this value with a number larger than 16-bit unsigned. If WiX is truly ignoring this number, shouldn't the Boostrapper not care what value is used, as long is it was a legal value when creating the MSI? -Ed On Mon, Jun 9, 2014 at 2:44 PM, Carter Young ecyo...@grandecom.net wrote: This is expected behavior because all of WiX ignores the 4th version number... If you want to test for it, you must do it manually. Carter Quoting Ed ecarp...@gmail.com: Wix is allowing me to create msi files with a large number in the fourth version index (6-digit numbers, i.e. 11). I'm trying to use burn to create a bootstrapper which bundles my wix installer. When I include an msi in the bundle which has a fourth version index greater than 65535 (16-bit unsigned) I get MSI parsing errors when executing the bootstrapper. No error pop-up is displayed, the only indication of the parsing error in in the Setup log file. Parsing errors in the Setup log file appear as follows: [25C4:25D0][2014-06-09T14:24:10]i001: Burn v3.8.1128.0, Windows v6.3 (Build 9600: Service Pack 0), path: C:\Users\ejcarpen\Documents\Visual Studio 2010\Projects\Bootstrapper1\Bootstrapper1\bin\Debug\Bootstrapper1.exe, cmdline: '' [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse @Version: 1.0.0.65536 [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse MSI package. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse packages. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to load manifest. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to initialize core. This is reproducible by building an empty setup project with version 1.0.0.65536 and adding it to an empty bootstrapper project Is there a way around this issue? Is it a bug or expected behavior based on MS version handling limitations? I find it strange that wix allows me to build MSI files that the wix bootstrapper can't parse Thanks, -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
Your getting the error because the number is ignored all together, regardless of type, int long string doesnt matter... its unable to parse because there is no underlying code in burn that says parse 4th digit Quoting Ed ecarp...@gmail.com: We are okay with WiX ignoring this number for upgrading purposes. We simply attach the build CL in the 4th index so we can trace each MSI back to the point of creation if needed The problem seems to be that Burn can't parse MSI files which fill this value with a number larger than 16-bit unsigned. If WiX is truly ignoring this number, shouldn't the Boostrapper not care what value is used, as long is it was a legal value when creating the MSI? -Ed On Mon, Jun 9, 2014 at 2:44 PM, Carter Young ecyo...@grandecom.net wrote: This is expected behavior because all of WiX ignores the 4th version number... If you want to test for it, you must do it manually. Carter Quoting Ed ecarp...@gmail.com: Wix is allowing me to create msi files with a large number in the fourth version index (6-digit numbers, i.e. 11). I'm trying to use burn to create a bootstrapper which bundles my wix installer. When I include an msi in the bundle which has a fourth version index greater than 65535 (16-bit unsigned) I get MSI parsing errors when executing the bootstrapper. No error pop-up is displayed, the only indication of the parsing error in in the Setup log file. Parsing errors in the Setup log file appear as follows: [25C4:25D0][2014-06-09T14:24:10]i001: Burn v3.8.1128.0, Windows v6.3 (Build 9600: Service Pack 0), path: C:\Users\ejcarpen\Documents\Visual Studio 2010\Projects\Bootstrapper1\Bootstrapper1\bin\Debug\Bootstrapper1.exe, cmdline: '' [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse @Version: 1.0.0.65536 [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse MSI package. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse packages. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to load manifest. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to initialize core. This is reproducible by building an empty setup project with version 1.0.0.65536 and adding it to an empty bootstrapper project Is there a way around this issue? Is it a bug or expected behavior based on MS version handling limitations? I find it strange that wix allows me to build MSI files that the wix bootstrapper can't parse Thanks, -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
Sorry I'm still a bit confused. If this is the case, then why am I able to create a bootstrapper which bundles an MSI file that has a fourth index version number of 65535? The fact that an MSI with fourth index 65535 (1.0.0.65535) will execute from a WiX bootstrapper with no issue, while an MSI file with fourth index of 65536 (1.0.0.65536) will cause the silent parsing error shown above seems to indicate there is an upper limit for this index when using burn (but not when creating the MSI via WiX) Could you explain source of this apparent value limitation? On Mon, Jun 9, 2014 at 3:01 PM, Carter Young ecyo...@grandecom.net wrote: Your getting the error because the number is ignored all together, regardless of type, int long string doesnt matter... its unable to parse because there is no underlying code in burn that says parse 4th digit Quoting Ed ecarp...@gmail.com: We are okay with WiX ignoring this number for upgrading purposes. We simply attach the build CL in the 4th index so we can trace each MSI back to the point of creation if needed The problem seems to be that Burn can't parse MSI files which fill this value with a number larger than 16-bit unsigned. If WiX is truly ignoring this number, shouldn't the Boostrapper not care what value is used, as long is it was a legal value when creating the MSI? -Ed On Mon, Jun 9, 2014 at 2:44 PM, Carter Young ecyo...@grandecom.net wrote: This is expected behavior because all of WiX ignores the 4th version number... If you want to test for it, you must do it manually. Carter Quoting Ed ecarp...@gmail.com: Wix is allowing me to create msi files with a large number in the fourth version index (6-digit numbers, i.e. 11). I'm trying to use burn to create a bootstrapper which bundles my wix installer. When I include an msi in the bundle which has a fourth version index greater than 65535 (16-bit unsigned) I get MSI parsing errors when executing the bootstrapper. No error pop-up is displayed, the only indication of the parsing error in in the Setup log file. Parsing errors in the Setup log file appear as follows: [25C4:25D0][2014-06-09T14:24:10]i001: Burn v3.8.1128.0, Windows v6.3 (Build 9600: Service Pack 0), path: C:\Users\ejcarpen\Documents\Visual Studio 2010\Projects\Bootstrapper1\Bootstrapper1\bin\Debug\Bootstrapper1.exe, cmdline: '' [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse @Version: 1.0.0.65536 [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse MSI package. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse packages. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to load manifest. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to initialize core. This is reproducible by building an empty setup project with version 1.0.0.65536 and adding it to an empty bootstrapper project Is there a way around this issue? Is it a bug or expected behavior based on MS version handling limitations? I find it strange that wix allows me to build MSI files that the wix bootstrapper can't parse Thanks, -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading...
Thanks I have add the older MSI's upgrade code to the upgrade table and will test that tomorrow :) Cheers, STeve -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: June-09-14 4:46 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading... I do not have direct experience with this issue, but I suspect the thing to do is to leave the new package name as is, but rather author multiple upgrade codes to also remove the old product. http://www.joyofsetup.com/2008/09/07/hint-be-generous-with-upgrade-codes/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079p7595125.html Sent from the wix-users mailing list archive at Nabble.com. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
See this post: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Setup-upgrade-needs-to-care-for-4th-part-of-version-number-td3250189.html Carter Quoting Ed ecarp...@gmail.com: Sorry I'm still a bit confused. If this is the case, then why am I able to create a bootstrapper which bundles an MSI file that has a fourth index version number of 65535? The fact that an MSI with fourth index 65535 (1.0.0.65535) will execute from a WiX bootstrapper with no issue, while an MSI file with fourth index of 65536 (1.0.0.65536) will cause the silent parsing error shown above seems to indicate there is an upper limit for this index when using burn (but not when creating the MSI via WiX) Could you explain source of this apparent value limitation? On Mon, Jun 9, 2014 at 3:01 PM, Carter Young ecyo...@grandecom.net wrote: Your getting the error because the number is ignored all together, regardless of type, int long string doesnt matter... its unable to parse because there is no underlying code in burn that says parse 4th digit Quoting Ed ecarp...@gmail.com: We are okay with WiX ignoring this number for upgrading purposes. We simply attach the build CL in the 4th index so we can trace each MSI back to the point of creation if needed The problem seems to be that Burn can't parse MSI files which fill this value with a number larger than 16-bit unsigned. If WiX is truly ignoring this number, shouldn't the Boostrapper not care what value is used, as long is it was a legal value when creating the MSI? -Ed On Mon, Jun 9, 2014 at 2:44 PM, Carter Young ecyo...@grandecom.net wrote: This is expected behavior because all of WiX ignores the 4th version number... If you want to test for it, you must do it manually. Carter Quoting Ed ecarp...@gmail.com: Wix is allowing me to create msi files with a large number in the fourth version index (6-digit numbers, i.e. 11). I'm trying to use burn to create a bootstrapper which bundles my wix installer. When I include an msi in the bundle which has a fourth version index greater than 65535 (16-bit unsigned) I get MSI parsing errors when executing the bootstrapper. No error pop-up is displayed, the only indication of the parsing error in in the Setup log file. Parsing errors in the Setup log file appear as follows: [25C4:25D0][2014-06-09T14:24:10]i001: Burn v3.8.1128.0, Windows v6.3 (Build 9600: Service Pack 0), path: C:\Users\ejcarpen\Documents\Visual Studio 2010\Projects\Bootstrapper1\Bootstrapper1\bin\Debug\Bootstrapper1.exe, cmdline: '' [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse @Version: 1.0.0.65536 [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse MSI package. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to parse packages. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to load manifest. [25C4:25D0][2014-06-09T14:24:10]e000: Error 0x8002000a: Failed to initialize core. This is reproducible by building an empty setup project with version 1.0.0.65536 and adding it to an empty bootstrapper project Is there a way around this issue? Is it a bug or expected behavior based on MS version handling limitations? I find it strange that wix allows me to build MSI files that the wix bootstrapper can't parse Thanks, -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration
Re: [WiX-users] Burn error when parsing msi version
On 6/9/2014 5:32 PM, Ed wrote:
Wix is allowing me to create msi files with a large number in the fourth
version index (6-digit numbers, i.e. 11).
How are you authoring that? If you put such a version as a literal
string, the compiler will fail with an error message saying you can't do
that:
Invalid product version '{0}'. Product version must have a major version
less than 256, a minor version less than 256, and a build version less
than 65536.
You can override that checking, such as by using a loc or other
bind-time variable:
http://www.joyofsetup.com/2008/07/17/beware-localization-variables/
Is there a way around this issue? Is it a bug or expected behavior based on
MS version handling limitations?
Expected behavior.
--
sig://boB
http://joyofsetup.com/
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in torch - wixmst output is not in XML format
On 6/9/2014 9:06 AM, Tunney, Stephen wrote: It might be a case of The Mondays but I'm at a loss at what you are getting at :( What are these other files that might get output by torch? How can I supress their output? Rename the .wixmst to .cab and open it in explorer. You'll see binaries in the .cab. -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
On 6/9/2014 6:01 PM, Carter Young wrote: Your getting the error because the number is ignored all together, regardless of type, int long string doesnt matter... its unable to parse because there is no underlying code in burn that says parse 4th digit Burn supports all four places of version numbers. -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
My Mistake, it's the MSI causing the issue, not the Burn Engine. See the post I linked earlier... Quoting Bob Arnson b...@joyofsetup.com: On 6/9/2014 6:01 PM, Carter Young wrote: Your getting the error because the number is ignored all together, regardless of type, int long string doesnt matter... its unable to parse because there is no underlying code in burn that says parse 4th digit Burn supports all four places of version numbers. -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
Thank you Bob, I have isolated the issue by using basic Visual Studio WiX projects (Setup Project and Bootstrapper Project) To create the MSI, I created a simple Setup Project and changed the Product's Version attribute to 1.0.0.65536. Then I crated a basic Bootstrapper Project and added a single MSIPackage element which specified my new MSI as the only item in the Chain. Note that I am leaving the Bootstrapper version as 1.0.0.0, it is not part of the issue. When the MSI Product Version attribute is set to 1.0.0.65535, my simple empty bootstrapper project launches the the msi as expected, but when the MSI Product Version's fourth index is 65536 or higher, the MSI parse fails with the message I included in the original e-mail. I understand the build version must be less than 65536, but I believe that refers to the third index in the version number. There is no compile error for a high number in the fourth version index (I read somewhere this was 64-bit, but can't find it now...) Below is the Product.wxs of the msi that allows the 1.0.0.65536 version number to build. It is the only change I made to the basic Setup Project and it compiles with no issue: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=* Name=SetupProject1 Language=1033 Version=1.0.0.65536 Manufacturer=Me UpgradeCode=656c5f73-a75d-449c-813d-7be197cec1a2 Package InstallerVersion=200 Compressed=yes InstallScope=perMachine / MajorUpgrade DowngradeErrorMessage=A newer version of [ProductName] is already installed. / MediaTemplate / Feature Id=ProductFeature Title=SetupProject1 Level=1 ComponentGroupRef Id=ProductComponents / /Feature /Product Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLFOLDER Name=SetupProject1 / /Directory /Directory /Fragment Fragment ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER !-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -- !-- Component Id=ProductComponent -- !-- TODO: Insert files, registry keys, and other resources here. -- !-- /Component -- /ComponentGroup /Fragment /Wix On Mon, Jun 9, 2014 at 3:36 PM, Carter Young ecyo...@grandecom.net wrote: My Mistake, it's the MSI causing the issue, not the Burn Engine. See the post I linked earlier... Quoting Bob Arnson b...@joyofsetup.com: On 6/9/2014 6:01 PM, Carter Young wrote: Your getting the error because the number is ignored all together, regardless of type, int long string doesnt matter... its unable to parse because there is no underlying code in burn that says parse 4th digit Burn supports all four places of version numbers. -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
concerning 'Invalid product version '{0}'. Product version must have a
major version
less than 256, a minor version less than 256, and a build version less
than 65536.' I believe the version format is Major.Minor.Build.Revision,
hence the compile error is correct, albeit missing any limit information
concerning index four
On Mon, Jun 9, 2014 at 3:51 PM, Ed ecarp...@gmail.com wrote:
Thank you Bob,
I have isolated the issue by using basic Visual Studio WiX projects (Setup
Project and Bootstrapper Project)
To create the MSI, I created a simple Setup Project and changed the
Product's Version attribute to 1.0.0.65536. Then I crated a basic
Bootstrapper Project and added a single MSIPackage element which specified
my new MSI as the only item in the Chain. Note that I am leaving the
Bootstrapper version as 1.0.0.0, it is not part of the issue.
When the MSI Product Version attribute is set to 1.0.0.65535, my simple
empty bootstrapper project launches the the msi as expected, but when the
MSI Product Version's fourth index is 65536 or higher, the MSI parse fails
with the message I included in the original e-mail.
I understand the build version must be less than 65536, but
I believe that refers to the third index in the version number. There is no
compile error for a high number in the fourth version index (I read
somewhere this was 64-bit, but can't find it now...)
Below is the Product.wxs of the msi that allows the 1.0.0.65536 version
number to build. It is the only change I made to the basic Setup Project
and it compiles with no issue:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=* Name=SetupProject1 Language=1033
Version=1.0.0.65536 Manufacturer=Me
UpgradeCode=656c5f73-a75d-449c-813d-7be197cec1a2
Package InstallerVersion=200 Compressed=yes
InstallScope=perMachine /
MajorUpgrade DowngradeErrorMessage=A newer version of [ProductName] is
already installed. /
MediaTemplate /
Feature Id=ProductFeature Title=SetupProject1 Level=1
ComponentGroupRef Id=ProductComponents /
/Feature
/Product
Fragment
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=INSTALLFOLDER Name=SetupProject1 /
/Directory
/Directory
/Fragment
Fragment
ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER
!-- TODO: Remove the comments around this Component element and the
ComponentRef below in order to add resources to this installer. --
!-- Component Id=ProductComponent --
!-- TODO: Insert files, registry keys, and other resources here. --
!-- /Component --
/ComponentGroup
/Fragment
/Wix
On Mon, Jun 9, 2014 at 3:36 PM, Carter Young ecyo...@grandecom.net
wrote:
My Mistake, it's the MSI causing the issue, not the Burn Engine. See
the post I linked earlier...
Quoting Bob Arnson b...@joyofsetup.com:
On 6/9/2014 6:01 PM, Carter Young wrote:
Your getting the error because the number is ignored all together,
regardless of type, int long string doesnt matter... its unable to
parse because there is no underlying code in burn that says parse 4th
digit
Burn supports all four places of version numbers.
--
sig://boB
http://joyofsetup.com/
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk
Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
-Ed
--
-Ed
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
On 6/9/2014 6:51 PM, Ed wrote: I understand the build version must be less than 65536, but I believe that refers to the third index in the version number. Product versions must be less than or equal to 255.255.65535.65535. http://msdn.microsoft.com/en-us/library/aa370859%28v=vs.85%29.aspx makes that clear for the first three fields but doesn't talk about the fourth. http://msdn.microsoft.com/en-us/library/aa372488%28v=vs.85%29.aspx shows it's a 16-bit limit. There is no compile error for a high number in the fourth version index That's a bug, for sure. Can you open one at http://wixtoolset.org/issues/? -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
I see, thanks for the help! Our team has been filling that fourth index with larger numbers for years with no ill affects, so I assumed this was acceptable. I will deliver to them the bad news ;) I will also open a bug for wix to flag such builds with compile warnings so other teams don't encounter this issue in the future On Mon, Jun 9, 2014 at 4:01 PM, Bob Arnson b...@joyofsetup.com wrote: On 6/9/2014 6:51 PM, Ed wrote: I understand the build version must be less than 65536, but I believe that refers to the third index in the version number. Product versions must be less than or equal to 255.255.65535.65535. http://msdn.microsoft.com/en-us/library/aa370859%28v=vs.85%29.aspx makes that clear for the first three fields but doesn't talk about the fourth. http://msdn.microsoft.com/en-us/library/aa372488%28v=vs.85%29.aspx shows it's a 16-bit limit. There is no compile error for a high number in the fourth version index That's a bug, for sure. Can you open one at http://wixtoolset.org/issues/? -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn error when parsing msi version
Defect added: http://wixtoolset.org/issues/4443/ On Mon, Jun 9, 2014 at 4:27 PM, Ed ecarp...@gmail.com wrote: I see, thanks for the help! Our team has been filling that fourth index with larger numbers for years with no ill affects, so I assumed this was acceptable. I will deliver to them the bad news ;) I will also open a bug for wix to flag such builds with compile warnings so other teams don't encounter this issue in the future On Mon, Jun 9, 2014 at 4:01 PM, Bob Arnson b...@joyofsetup.com wrote: On 6/9/2014 6:51 PM, Ed wrote: I understand the build version must be less than 65536, but I believe that refers to the third index in the version number. Product versions must be less than or equal to 255.255.65535.65535. http://msdn.microsoft.com/en-us/library/aa370859%28v=vs.85%29.aspx makes that clear for the first three fields but doesn't talk about the fourth. http://msdn.microsoft.com/en-us/library/aa372488%28v=vs.85%29.aspx shows it's a 16-bit limit. There is no compile error for a high number in the fourth version index That's a bug, for sure. Can you open one at http://wixtoolset.org/issues/ ? -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -Ed -- -Ed -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in torch - wixmst output is not in XML format
OK. That's kinda cool, now how do I stop it from outputting that? :) From: Bob Arnson [b...@joyofsetup.com] Sent: June 9, 2014 6:24 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Bug in torch - wixmst output is not in XML format On 6/9/2014 9:06 AM, Tunney, Stephen wrote: It might be a case of The Mondays but I'm at a loss at what you are getting at :( What are these other files that might get output by torch? How can I supress their output? Rename the .wixmst to .cab and open it in explorer. You'll see binaries in the .cab. -- sig://boB http://joyofsetup.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Update Application (IIS)
Hi, Using Wix we can able to create Application Virtual Directory.But,know i need to update the application -- Thanks Regards, Chaitanya. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
