Hey Nick, I understand your frustration, in fact have expressed them myself. Bottom line is no, Heat currently isn't setup to handle this volume of files in a fully Windows Installer compliant way. This is a known design limitation for the v3.0 release. However, I wouldn't throw the tool away. The general issue around large installations is not just getting the files onto the machine but then servicing the installation "in-place". This would mean not doing a full uninstall and reinstall for each new release. In order to handle this functionality many things need to stay the same for Windows Installer to correctly build patches for an MSI. Component key files must say the same and pretty much cannot be deleted, Feature/Component/File Ids must say the same, Component GUIDs must stay the same according to their key, DiskId's must say the same and I might be missing one or two things from that.
> Is Heat not designed to reduce the task of including 3000 files to adding a <ComponentGroupRef> (or whatever) line to a "Feature" ? Yes and no. What you are seeing with the 1600 components in Candle/Light is actually thrown in Heat as well as a warning. It is very possible this should be upgraded to an error but I thought that was too strong. It is really up to the developer to decide that risk. However, with over 20,000 files one would probably not even see the warning. There are some ways to work around this if you are able to break up your directly harvesting into blocks of less than 1600 files. > Why does the Heat output have one (blank, and duplicated) DirectoryRef each time there is a component in the one directory? Wouldn't this degrade performance... These actually aren't blank, they are correctly fragmented. You can use an "-sfrag" command line switch to get rid of this functionality. This has been done to allow components to be pulled into other ComponentGroups/Features without taking all other Directory references. This is in line with with how WiX can be authored for flexibility > Is there a way to tell Heat that the path to the files is ..\Whatever, NOT a variable, NOT the silly string it uses by default? The answer is No. The use of SourceDir\ was decided to remove root directory path dependencies. This is especially useful in large build environments where the *.wxs files can be copied between machines. The use of the "-b" command line switch in Light allows for root directories to be substituted in place of the SourceDir. It also allows Heat to generate the Directory/Component/File Ids in a repeatable manner to help enable patching. The technical challenges for all of this are actually not extremely difficult. However, they aren't easy either. Much thought has been done in the WiX v3.0 timeline in order to being addressing many of these issues and make this high level of generation possible. Using Extensions to Heat there are ways to do this correctly. I am currently working on doing this for a product that is deploying over 200,000 files which we would like to perform "in-place" patching on once released. I am currently using an internal prototype to deliver this functionality and hope to be able to get this extension onto the WixContrib site within the next few months. Again, automating the initial gathering of files is not the challenge. It is the doing it again for the patch that will come out after your RTM. Your questions prompted a blog response with some additional details. http://icumove.spaces.live.com/blog/cns!FB93073C6534B681!558.entry Thanks, Brian Rogers "Intelligence removes complexity." - Me http://icumove.spaces.live.com On Sat, May 30, 2009 at 4:01 PM, Nick <w...@karancevic.com> wrote: > So I tried to move from Tallow to Heat because, well, when I use Tallow, I > have > to manually edit Tallow's output to delete short filenames so it works with > WiX3... > > Particularly challenging part of my projects is to generate WiX files for > sample > input/output. This sample input/output is on the order of magnitude of > 1000's > of files... > > So Heat proliferates the heck out of IMO unnecessary components, one > component > for each file. It should IMO be just two components (one per directory) > but it > ends up a few thousand...so-what, there's ComponentGroups, right? > > But when I put the ComponentRef into a Feature, then Candle/Light complain > how > Windows Installer only allows 1600 components per feature max, and on Win9x > that number is only 800 (something). > > So now I'm back to manually editing output of Heat to sporadically add > "Feature" > tags in between components... > > 1) What am I missing? Is Heat not designed to reduce the task of including > 3000 > files to adding a <ComponentGroupRef> (or whatever) line to a "Feature" ? > > 2) Why does the Heat output have one (blank, and duplicated) DirectoryRef > each > time there is a component in the one directory? Wouldn't this degrade > performance... > > 3) Is there a way to tell Heat that the path to the files is ..\Whatever, > NOT a > variable, NOT the silly string it uses by default? > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
