Dear Blair, Thank you so much! It's really great! Did not think that it will be that simple. I am quiet astonished that all the flags you told me are neither in the help file nor at [1]. But calling heat without parameters tells all "hidden" parameters...
Am 22.07.2010 00:48, schrieb Blair: > -ag switch: [...] This results in stable GUIDs that don't change > between builds unless you change the directory or the filename (and in > either of those cases, you want a new guid). > [...] The "*" for guids in the compiler means "generate" and the algorithm > for guid generation is different based on what the guid is for, but always > with an eye toward the safest results for as many cases as possible. This was exactly what I did not know. GREAT if this is the case!! > Since you are adding and removing PDF files, you should be planning on only > using Major Upgrades, and so your Product/@Id value should also be "*" (in > that case, the algorithm simply generates a new guid each time, which is the > primary requirement for generating major upgrades). Really? :-( I have questions regarding upgrades/packaging left anyway, but for now: My application consists of a "viewer" (1MB exe + 1kb DLL + helpfile, README, ...) which will be more or less static. The data itself is contained in an 80MB database file and a directory of PDFs (mentioned above). Usually the "viewer" won't really change in future but every few months there will be an update where the database file as well as the PDFs will be upgraded. I was really happy when I read the WiX Howto because I thought I really can do "real" upgrades now, i.e. make packages without the viewer component but only update the PDFs and the database file. Is this really not possible in this case? Is it at least possible if only PDFs are added and not removed? Because the PDFs are small and they could reside on the client PC until the next "major" upgrade... > [...] > SourceFile directory: Easiest fix (from my point of view) is to use the -var > switch, and tell the compiler where to look. Something like this: > > Heat ... -var PdfFolder ... > Candle ... -dPdfFolder=src\INSTALLDIR\pdf\ ... Great!! Thank you very much. For the archive: Use heat ... -var var.PdfFolder=... ... And for the second problem (TARGETDIR/INSTALLDIR) there is another "hidden" switch: heat ... -var var.PdfFolder=... -dr INSTALLDIR ... Regards, Luke [1] http://wix.sourceforge.net/manual-wix3/heat.htm > -----Original Message----- > From: Lukas Haase [mailto:lukasha...@gmx.at] > Sent: Wednesday, July 21, 2010 3:17 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Automatically include arbitrary files > > Am 22.07.2010 00:07, schrieb Lukas Haase: >> Dear Blair, >> >> I do not fully understand. You mean the -ag switch? >> >> But then on every compile the PDF files get a different GUID, don't >> they? Then back to the original question: Does it matter in ANY way if >> they get a different GUID on upgrades? >> >> I.e. In a few months I will make the first upgrade for for my product. >> Most likely a few PDFs will be removed, a few will be added. Is there >> any concern with your proposed method? > > Dear Blair, > > Sorry, I forget one additional question: > > Heat generates the<File>-Elements as: > > <File Id="fil6CD3EB10EF7C12F5645E92DEC7FA408E" KeyPath="yes" > Source="SourceDir\04156.pdf" /> > ^^^^^^^^^ > > but in fact I placed the PDFs (relative to the directory from where I > call candle/light) in > src\INSTALLDIR\pdf > > Is there any way to replace SourceDir with src\INSTALLDIR\pdf > automatically? Or is there another solution? > > Similar the directory with is created as: > > <DirectoryRef Id="TARGETDIR"> > ^^^^^^^^^ > <Directory Id="dir92AEA0E44CFC478DB41459D407BB54A9" Name="pdf" /> > </DirectoryRef> > > But in fact it should be<DirectoryRef Id="INSTALLDIR"> in order to work... > > Thank you very much. > > Regards, > Luke > > > > >> Am 21.07.2010 23:41, schrieb Blair: >>> In your settings for heat, you should use automatic component guids (they >>> come out as Guid="*") and you should setup a component group for your PDF >>> files (then you can simply refer to them from your feature using the >>> ComponentGroupRef element). >>> >>> -----Original Message----- >>> From: Lukas Haase [mailto:lukasha...@gmx.at] >>> Sent: Wednesday, July 21, 2010 1:29 PM >>> To: wix-users@lists.sourceforge.net >>> Subject: [WiX-users] Automatically include arbitrary files >>> >>> Hi, >>> >>> My setup project consists of a bunch of "static" files (application, >>> DLL), a huge databasefile and a vast amount of PDF files. The PDF files >>> are very volatile, they change from update to update (some are removed, >>> some are added but no of them are changed). >>> >>> As they are many files I would really prefer to add them automatically. >>> >>> I looked at the include-directive from the preprocessor but I can't find >>> out how to automate. >>> >>> I looked at fragments and played around with "heat". In general, this >>> would work. heat generates a wxs file containing a list of all pdf >>> files. However, I have all of them to add to the<Feature>-List in my >>> main file as<ComponentRef>-element! >>> >>> Isn't there a way to include the whole fragment and/or directory? >>> >>> Even if this would work, I still have to manually add/remove the items >>> in the pdfs.wxs. >>> >>> It would be really great if I could just put the current PDFs in the >>> diretory "pdfs" and all of them are just added to the MSI. >>> >>> However, if I run heat multiple times I clearly get different GUIDs for >>> the PDFs on each call. >>> >>> Does it matter when the GUIDs of the files change? Especially for the >>> update? >>> >>> Is there any chance to automate this process consistently? >>> >>> Best Regards, >>> Luke >>> >>> >>> > ---------------------------------------------------------------------------- >>> -- >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>> _______________________________________________ >>> WiX-users mailing list >>> WiX-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wix-users >>> >>> >>> > ---------------------------------------------------------------------------- > -- >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> >> >> >> > ---------------------------------------------------------------------------- > -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > > > ---------------------------------------------------------------------------- > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
