One strategy would be to split your package into two (one with the frequently changing stuff and another with the rarely changing stuff) and use a bootstrapper to tie them together, but given the relative size differences between your frequently changing (database and pdf files) and your rarely changing (viewer & misc files) that doesn't buy you much (I'm calculating a greater than 80:1 ratio of frequent to rare, which gives me "< 2%" static content).
If you are vigilant at maintaining the component rules you can use "late scheduling" of the RemoveExistingProducts and avoid reinstalling the files that rarely change (except, of course, when they are changed) [which saves the time that would have been spent erasing and rewriting them] but you would still be shipping them with each build. If you are only adding/changing files (and you don't otherwise move any component out of any feature) you do have the possibility of using patching to supply your updates, but mixing MSP releases with MSI releases quickly explodes your testing and support matrix and you often no longer realize any size savings in your MSP files (unless you follow the "for any given build, release either MSI or superseding MSP, never both" rule, which requires new customers to apply the MSI and latest MSP. There can also be issues with MSP removal when adding files, so my recommendation in that case is to make your MSPs superseding and non-uninstallable (they will be uninstalled when the MSI is removed) to reduce your complexity and keep your servicing story more manageable. If all that added complexity is worth saving less than 2% of the size of your updating customers downloads (assuming that the database and PDF files all change every release) then go for it (just test every conceivable scenario before letting anything out the door). Of course, the savings using patching goes up the more you don't change, so my "back-of-the-envelope" analysis may not be correct. Blair -----Original Message----- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 4:49 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files ... > 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... ... ------------------------------------------------------------------------------ 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
