Yes, exactly. On Thu, Jul 22, 2010 at 12:26 PM, Lukas Haase <lukasha...@gmx.at> wrote:
> Dear Blair, > > Thank you very much for your comprehensive explanation. Together with > the comments from "Does the MSI-filename matter" I think I won't care > about minor and small updates and just ship always a major upgrade. > Morever if this is "best practice". The saving isn't it worth! > > Just one last comment on this: I will always ship anything and just > always change version and product GUID. > > But I will always keep the same UpgradeCode, won't I? This means that as > long as I keep the UpgradeCode the same the MSI will detect a previous > version and may upgrade it? > > Regards, > Luke > > > Am 22.07.2010 19:05, schrieb Blair: > > 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 > > > > > ------------------------------------------------------------------------------ > 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 > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ 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
