Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Thanks Dave, I understand what your saying, but I'm managing installers with 16,000+ files. That's not something I'm going to do manually and files can be added and deleted on a daily basis. Heat looks good from my prospective however its missing a critical piece, and that's (what believe what you call) a component catalog. Is there any plans on the horizon for such a feature in heat? Thanks again Jimbo From: David Howell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 4:17 PM To: Collins, James; 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Msi inside msi ?
Hey Jeroen, I'm also not sure what your trying to achieve however for me I have very large installers including well over 16k files. For me I need to split that up to reduce build time as well as keeping things modular. The way I do that is with Merge Modules (MSM) which is basically an installer inside an installer. Jimbo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, July 25, 2007 8:27 AM To: Jeroen Davelaar Cc: WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Msi inside msi ? Jeroen Davelaar wrote: How is it possible to nest a msi file with Orca while it is nog possible to do the same thing with WiX? WiX deprecated the functionality when the MSI team deprecated it. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Msi inside msi ?
Thanks mike, Yes I would agree fragments offer much more and I will keep that in mind moving forward. For me however I need a migration path from Wise to WIX and that's going to be merge modules for now. Once I have convinced my team WIX is the way to go (and believe me I'm trying very hard), and we are fully WIX then this approach makes much more sense. WIX by stealth! :) Jimbo -Original Message- From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 25, 2007 12:02 PM To: Collins, James; 'Bob Arnson'; 'Jeroen Davelaar' Cc: WiX-users@lists.sourceforge.net Subject: RE: [WiX-users] Msi inside msi ? WiX was designed to support very large installer projects, with a design goal of distributed setup authoring. To support this idea, WiX supports Fragments. A Fragment is just a section of setup authoring. Loosely, candle compiles source files containing one or more Fragments into .wixobj files, and light links one or more .wixobj files into a final installer/merge module/patch. One, and only one, of the sections of an installation must be a Product, PatchCreation, or Module. candle and light are very much modelled after a C/C++ Compiler and Linker respectively. It took me a while to work out that the first letter of each tool's name indicates its purpose (Candle = compiler, Light = linker, Lit = library tool, Dark = decompiler, Heat = 'harvester', Pyro = patch builder, Torch = transform creation). You can keep .wixobj files between sessions if the corresponding source file hasn't changed, which may reduce build time (although most of the cost is in binding and validating the MSI rather than processing the source files). A traditional C compiler would only operate on a single source file per run, but like Microsoft's cl.exe, candle accepts multiple source files on the same command line. You should probably consider defining one Fragment per logical component (not necessarily Component) of your product. Just like C# and C++ classes, you can have more than one Fragment per source file, but it may be more understandable if you stick to one Fragment per source file. Splitting your installation into more source files reduces the chance of checkout/merge collisions with multiple developers. In general, Fragments are much nicer to work with than merge modules. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: 25 July 2007 19:35 To: Bob Arnson; Jeroen Davelaar Cc: WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Msi inside msi ? Hey Jeroen, I'm also not sure what your trying to achieve however for me I have very large installers including well over 16k files. For me I need to split that up to reduce build time as well as keeping things modular. The way I do that is with Merge Modules (MSM) which is basically an installer inside an installer. Jimbo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, July 25, 2007 8:27 AM To: Jeroen Davelaar Cc: WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Msi inside msi ? Jeroen Davelaar wrote: How is it possible to nest a msi file with Orca while it is nog possible to do the same thing with WiX? WiX deprecated the functionality when the MSI team deprecated it. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Multiple files of the same name in Merge Module
Hi all, I have a merge module with lots and lots of files. Some of these files have the same name eg. Styles.css but of course each contain different contents and are located in different folders throughout the module. The problem I have found is that after I install the files and compare them to the original, some of these file's contents is different (replaced with some random file of the same name). Has anyone seen this before? I was reading somewhere that there was a new feature added recently that prevented the same file being added more than once to the cab, to help reduce size? Perhaps there is a bug with this feature? Can I disable that feature? I'm using version 3.0.2925.0 Thanks in advance Jimbo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multiple files of the same name in Merge Module
Hey all I have some more information... This seems to be an issue with heat.exe. For the files that are incorrect, it appears that I have multiple components of the same name ComponentRef Id=Styles.css_1 / ComponentRef Id=styles.css_1 / Fragment DirectoryRef Id=Default_5 Component Id=styles.css_1 Guid=09ff9a3c-a3c7-4be5-a8f9-57d5723f6087 File Id=styles.css_1 Name=styles.css KeyPath=yes Source=d:\My Path\Input\Skins\Default\styles.css / /Component /DirectoryRef /Fragment Fragment DirectoryRef Id=Brick Component Id=Styles.css_1 Guid=712a5824-1a0e-4e13-a217-12e800976995 File Id=Styles.css_1 Name=Styles.css KeyPath=yes Source=d:\My Path\Combobox\Skins\Brick\Styles.css / /Component /DirectoryRef /Fragment Notice that one component name has an uppercase and the other does not. Would this be classified as a bug? Has anyone noticed this before? Thanks Again Jimbo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Monday, July 23, 2007 3:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Multiple files of the same name in Merge Module Hi all, I have a merge module with lots and lots of files. Some of these files have the same name eg. Styles.css but of course each contain different contents and are located in different folders throughout the module. The problem I have found is that after I install the files and compare them to the original, some of these file's contents is different (replaced with some random file of the same name). Has anyone seen this before? I was reading somewhere that there was a new feature added recently that prevented the same file being added more than once to the cab, to help reduce size? Perhaps there is a bug with this feature? Can I disable that feature? I'm using version 3.0.2925.0 Thanks in advance Jimbo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multiple files of the same name in Merge Module
Thanks bob. Yes I think the cab file only having one of the ID's per case is exactly the problem. I have added your comment to the bug... 1759273 -- Sent from my BlackBerry Wireless Handheld - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: Collins, James Cc: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Sent: Mon Jul 23 22:27:56 2007 Subject: Re: [WiX-users] Multiple files of the same name in Merge Module Collins, James wrote: This seems to be an issue with heat.exe. For the files that are incorrect, it appears that I have multiple components of the same name…. ComponentRef Id=Styles.css_1 / ComponentRef Id=styles.css_1 / It's a two-fer bug: Heat sees them as distinct IDs and Light doesn't complain. (CAB files can't have IDs that differ only by case.) I've encountered the bug before but haven't tracked down the fix yet. Feel free to file a bug to encourage it. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multiple files of the same name in Merge Module
Thanks bob. Yes I think the cab file only having one of the ID's per case is exactly the problem. I have added your comment to the bug... 1759273 Jimbo From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Mon 7/23/2007 10:27 PM To: Collins, James Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Multiple files of the same name in Merge Module Collins, James wrote: This seems to be an issue with heat.exe. For the files that are incorrect, it appears that I have multiple components of the same name ComponentRef Id=Styles.css_1 / ComponentRef Id=styles.css_1 / It's a two-fer bug: Heat sees them as distinct IDs and Light doesn't complain. (CAB files can't have IDs that differ only by case.) I've encountered the bug before but haven't tracked down the fix yet. Feel free to file a bug to encourage it. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Hey Patrice,
Have you tried using heat.exe ?? Since you have so many
files you might want to take a look at that. You point it to you folder
and it writes out the wxs file for you including all the reg keys for
DLL's etc.
If order to build patch's and minor versions your going to
need to reconcile your GUIDS and ID. The tool you need I believe this
community calls it a component catalog, and as far as I'm aware it
does not exist.
Unfortunately when you use heat it will not generate GUIDS
and you need to maintain them and the ID's yourself. Remember to not
break any of the component rules (whatever they are).
I have written what I think is a component catalog, however
I don't have enough knowledge to ensure all component rules are not
broken so it's just something I'm playing with at this point.
Jimbo
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Patrice
Lamarche
Sent: Thursday, July 19, 2007 6:39 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Hello everyone,
We are stating using WiX. I'm searching for some help about
how to structure our wxs file. We have a lot (more than 60K) files. The
format we use currently is one file per component and one feature
containing all the components. I have to build patch between minor
version that remove, update and add new files. Is there any best
practices or suggestions?
I did some tests. I correctly generated a setup. I tried the patching
system with pyro. I based my Patch.wxs on the Peter Marcu's Blog sample.
My sample did work but it's took long time to generate the patch for
only one file modified. Pyro looks to do a binary compare on each file
can we specify to check if the file date have changed if not skip to the
next file?
Now I'm trying with a smaller set of files to test removed files and
added files into a patch but I get this error
C:\delivery\Dev\wix\src\ext\uiextension\wixlib\Common.wxs(73) : error
PYRO0103 : The system cannot find the file
'C:\delivery\Target\wix\x86\ship\lang-neutral\PrintEula.dll'.
I'm currently updating my sdk to build wix. And get the dll
Thanks you for yours advices.
Best Regards,
Patrice Lamarche
There is a sample of my wxs
Setup.wxs
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id={955BA1D1-594E-4678-AD9B-785038FEBC47} Language=1033
Manufacturer=Blabla Inc. Name=v1.00.00
UpgradeCode={DD431266-3725-4BBB-902A-936CDFD95CA5} Version=1.00.00
Package Compressed=yes InstallerVersion=300 /
Upgrade Id={DD431266-3725-4BBB-902A-936CDFD95CA5}
UpgradeVersion OnlyDetect='yes' Property='PATCHFOUND'
Minimum='1.00.00' IncludeMinimum='yes' Maximum='1.00.00'
IncludeMaximum='yes' /
UpgradeVersion OnlyDetect='yes' Property='NEWERFOUND'
Minimum='1.00.00' IncludeMinimum='no' /
/Upgrade
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='ProgramFilesFolder' Name='PFiles'
Directory Id='Blabla' Name='Blabla'
Directory Id='INSTALLDIR' Name='Bla'
Directory Id=data_1 Name=Data
Component Id=bla.build_1
Guid={6CB5A96B-2470-4F61-A237-8B8FC9853BCC}
File Id=bla.build_1 Name=bla.build KeyPath=yes
Source=x:\Data\bla.build DiskId=1 /
/Component
Component Id=bladata.build_1
Guid={7743C10F-109D-4209-9B67-361D24AB3D21}
File Id=bladata.build_1 Name=blaData.build KeyPath=yes
Source=x:\blaData.build DiskId=1 /
/Component
Component Id=bladata.ss.build_1
Guid={FD92FBF9-BAF0-4730-A263-CC646B91914D}
File Id=bladata.ss.build_1 Name=blaData.ss.build KeyPath=yes
Source=x:\blaData.ss.build DiskId=1 /
/Component
..
Feature Id=bla Level=1 Title=Bla 1.00.00
ComponentRef
Id=log4net.appender.appenderskeleton.activateoptions.html_1 /
ComponentRef Id=banksinmultibootdlg.cpp_1 /
ComponentRef Id=gxtevbias.html_1 /
ComponentRef Id=log4net.core.logimpl.errorformat_overload_3.html_1 /
ComponentRef Id=t_5_025.cpp_1 /
ComponentRef Id=test_list.vcproj_1 /
ComponentRef Id=doc2.htm_1 /
.
Patch.wxs
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Patch
AllowRemoval=yes
Manufacturer=Bla
MoreInfoURL=http://www.bla.com/;
DisplayName=Bla 1.00.00 to 1.00.01
Description=Patch Sample
Classification=Update
Media Id=5000 Cabinet=RTM.cab
PatchBaseline Id=RTM/
/Media
PatchFamilyRef Id=BlaPatch/
/Patch
Fragment
PatchFamily Id=BlaPatch Version='1.00.01' Supersede='yes'
/PatchFamily
/Fragment
/Wix
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Re: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
My understanding is that if your removing a file then just remove the whole
component all together and when you upgrade MSI will realize the component no
longer exists and remove the file for you.
So you would start with
Component Id=bla.build_1 Guid={6CB5A96B-2470-4F61-A237-8B8FC9853BCC}
File Id=bla.build_1 Name=bla.build KeyPath=yes
Source=x:\Data\bla.build DiskId=1 /
/Component
And change it to...
Empty string.
But as I said I'm no expert on the component rules. :-)
Jimbo
From: Patrice Lamarche [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 10:57 AM
To: Collins, James; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Hello,
First, thanks for the reply. No I'm not using heat, I'll look. I'm
currently generating my GUIDS with a perl script for the 1st install and we
planned to create a program that will create the RemoveFile entry for deleted
files, add the new files. I downloaded a weekly build from the website and it
resolved my pyro problem. I can now generate patch with the files I manually
edited. I'll search for more info about a component catalog.
Just to be sure. If a file is deleted I need to change
Component Id=bla.build_1 Guid={6CB5A96B-2470-4F61-A237-8B8FC9853BCC}
File Id=bla.build_1 Name=bla.build KeyPath=yes
Source=x:\Data\bla.build DiskId=1 /
/Component
For
Component Id=bla.build_1 Guid={6CB5A96B-2470-4F61-A237-8B8FC9853BCC}
RemoveFile Id=bla.build_1 Name=bla.build KeyPath=yes
Source=x:\Data\bla.build DiskId=1 /
/Component
It's give me error about the keypath. I've read in the doc and I'm not sure
about what the keypath attribute does.
Thanks for your reactivity!
Best regards,
Patrice Lamarche
De : Collins, James [mailto:[EMAIL PROTECTED]
Envoyé : 19 juillet 2007 13:43
À : Patrice Lamarche; wix-users@lists.sourceforge.net
Objet : RE: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Hey Patrice,
Have you tried using heat.exe ?? Since you have so many files you
might want to take a look at that. You point it to you folder and it writes out
the wxs file for you including all the reg keys for DLL's etc.
If order to build patch's and minor versions your going to need to
reconcile your GUIDS and ID. The tool you need I believe this community calls
it a component catalog, and as far as I'm aware it does not exist.
Unfortunately when you use heat it will not generate GUIDS and you
need to maintain them and the ID's yourself. Remember to not break any of the
component rules (whatever they are).
I have written what I think is a component catalog, however I don't
have enough knowledge to ensure all component rules are not broken so it's just
something I'm playing with at this point.
Jimbo
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrice Lamarche
Sent: Thursday, July 19, 2007 6:39 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Hello everyone,
We are stating using WiX. I'm searching for some help about how to
structure our wxs file. We have a lot (more than 60K) files. The format we use
currently is one file per component and one feature containing all the
components. I have to build patch between minor version that remove, update and
add new files. Is there any best practices or suggestions?
I did some tests. I correctly generated a setup. I tried the patching system
with pyro. I based my Patch.wxs on the Peter Marcu's Blog sample. My sample did
work but it's took long time to generate the patch for only one file modified.
Pyro looks to do a binary compare on each file can we specify to check if the
file date have changed if not skip to the next file?
Now I'm trying with a smaller set of files to test removed files and added
files into a patch but I get this error
C:\delivery\Dev\wix\src\ext\uiextension\wixlib\Common.wxs(73) : error PYRO0103
: The system cannot find the file
'C:\delivery\Target\wix\x86\ship\lang-neutral\PrintEula.dll'.
I'm currently updating my sdk to build wix. And get the dll
Thanks you for yours advices.
Best Regards,
Patrice Lamarche
There is a sample of my wxs
Setup.wxs
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id={955BA1D1-594E-4678-AD9B-785038FEBC47} Language=1033
Manufacturer=Blabla Inc. Name=v1.00.00
UpgradeCode={DD431266-3725-4BBB-902A-936CDFD95CA5} Version=1.00.00
Package Compressed=yes InstallerVersion=300 /
Upgrade Id={DD431266-3725-4BBB-902A-936CDFD95CA5}
UpgradeVersion OnlyDetect='yes' Property='PATCHFOUND'
Minimum='1.00.00' IncludeMinimum='yes' Maximum='1.00.00' IncludeMaximum='yes' /
UpgradeVersion
[WiX-users] heat.exe 9000+ Files Merge Module, warning LGHT1076
Hey all, I was wondering if someone can help me with this issue. I'm creating a very large merge module 9000+ files, everything looks fine except when I try to include the MSM in wise which suggests there are problems with directory and component tables (yes fantastic error reporting from wise). BTW I'm unable to search the mail archive on sourceforge so please excuse me if this topic has already been covered. :-) Doing a verbose output on light.exe when I create the merge module gives me a bunch of warnings that look like. C:\temp\testing123.wxs(45240) : warning LGHT1076 : ICE03: String overflow (greater than length permitted in column); Table: File, Column: Component_, Key(s): paneTabContainerExpandedBottom.gif_6.ECE25F21_7C22_4B3F_93EC_FA1EDBA5FB2 5 It seems to be appending the packageID to the end of the Component key? I assume that's standard practice. Package Id=ece25f21-7c22-4b3f-93ec-fa1edba5fb25 Compressed=yes InstallerVersion=200 Manufacturer=Blah / This particular component looks like Fragment DirectoryRef Id=Img_105 Component Id=paneTabContainerExpandedBottom.gif_6 Guid=d8790233-d93e-41d7-905d-2d6bd2ab855f File Id=paneTabContainerExpandedBottom.gif_6 Name=paneTabContainerExpandedBottom.gif KeyPath=yes Source=c:\temp\source\Splitter\Skins\Vista\Img\paneTabContainerExpanded Bottom.gif / /Component /DirectoryRef /Fragment I think this is the root of the problem, I'm using heat.exe to generate the XML. Does anyone have any suggestions? Is there a limit for the component name? How do I get heat.exe to respect a component name size limit if there is one? Thanks in advance Jimbo - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heat.exe 9000+ Files Merge Module, warning LGHT1076
Great thanks for the reply Mike, that makes sense. So could this be classified as a bug in heat.exe? It sounds like heat should be limiting the Component ID to a length of 35 for merge modules? Aka when the -template:module flag is used. I did a search through the bugs database for heat and component but found no bugs. I'm a newbie here so how does one submit a bug? Thanks again Jimbo From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 1:18 PM To: Collins, James; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] heat.exe 9000+ Files Merge Module, warning LGHT1076 Components in merge modules have the package GUID appended to the component ID so there isn't a clash if the same component ID is used in multiple merge modules, and no clash between the merge modules and the main installer. It's a way to make the component ID unique. The same happens for a number of other IDs (e.g. property names). This means that you have to constrain your IDs to a shorter length than you would for the main installer. The GUID is 36 characters long so that gives you 35 characters for the component ID. It's the tool that generates the merge module which appends the package GUID, so you can often turn the feature off. In WiX that is done with the SuppressModularization attribute. However, this practice is not generally recommended due to the name clash problem. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: 18 July 2007 20:07 To: wix-users@lists.sourceforge.net Subject: [WiX-users] heat.exe 9000+ Files Merge Module, warning LGHT1076 Hey all, I was wondering if someone can help me with this issue. I'm creating a very large merge module 9000+ files, everything looks fine except when I try to include the MSM in wise which suggests there are problems with directory and component tables (yes fantastic error reporting from wise). BTW I'm unable to search the mail archive on sourceforge so please excuse me if this topic has already been covered. :-) Doing a verbose output on light.exe when I create the merge module gives me a bunch of warnings that look like. C:\temp\testing123.wxs(45240) : warning LGHT1076 : ICE03: String overflow (greater than length permitted in column); Table: File, Column: Component_, Key(s): paneTabContainerExpandedBottom.gif_6.ECE25F21_7C22_4B3F_93EC_FA1EDBA5FB2 5 It seems to be appending the packageID to the end of the Component key? I assume that's standard practice. Package Id=ece25f21-7c22-4b3f-93ec-fa1edba5fb25 Compressed=yes InstallerVersion=200 Manufacturer=Blah / This particular component looks like Fragment DirectoryRef Id=Img_105 Component Id=paneTabContainerExpandedBottom.gif_6 Guid=d8790233-d93e-41d7-905d-2d6bd2ab855f File Id=paneTabContainerExpandedBottom.gif_6 Name=paneTabContainerExpandedBottom.gif KeyPath=yes Source=c:\temp\source\Splitter\Skins\Vista\Img\paneTabContainerExpanded Bottom.gif / /Component /DirectoryRef /Fragment I think this is the root of the problem, I'm using heat.exe to generate the XML. Does anyone have any suggestions? Is there a limit for the component name? How do I get heat.exe to respect a component name size limit if there is one? Thanks in advance Jimbo - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
