I have a Burn package with a MSI that is marked as Compressed="yes". The Cache attribute was left off the MsiPackage element.
I run that copy of Burn and my MSI failed to install (due to errors in the MSI). The bootstrapper application shows as installed. I rebuild the Burn package with a new MSI file (same product and upgrade code, but different contents). I then run the newly created Burn package, without removing the previous one, it attempts to run the older cached MSI file. Is this designed and expected behavior? If so, what do I do to make it attempt to run the NEW MSI that is embedded in the Burn package? Is setting cache="no" sufficient? I remember seeing a discussion on all the effects of cache yes/no, but I cannot find it again. PS. Intuitively, embedded files should not be "cached" in the sense that an old one is run when a new Burn application is run. After all, we have already downloaded it so we should use it. Granted this view might be opposition to some orthogonal thought process that says that cache=yes should be consistent irrespective of compress=yes/no. ---------------------------------------------------------------------- Roy Chastain ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
