Hmm, sounds like Burn did not fully rollback the Bundle when your MSI failed. In that case, you might want to uninstall the previous Bundle before trying the new one. Also, the Burn log file should show you (during Detect) whether a package was already cached or not.
The Package @Compress and @Cache attributes are completely independent. Honestly, Cache=no is not well tested right now so its behavior may be a bit wonky still. Anyway, Compressed basically indicates whether the Package or Payload is stored inside a container. By default, marking a Package/@Compressed="yes" puts the package in the "attached container" which is the optional cabinet file appended to the end of the Burn engine. This can get you a single file container. There is a bit more discussion here: http://robmensching.com/blog/posts/2009/7/22/Burn-packages-payloads-and-containers The @Cache attribute indicates whether the Package should stay in the "Package Cache" after the install or repair (or even uninstall for ExePackages). Everything gets installed from the cache for security reasons (the Package Cache is locked down so we can download, verify and store stuff in the cache without Burn worrying about it getting swapped out by bad guys). Package Cache is also a lifesaver if you repair or ever do patching. Greatly improves success rate by reducing source resolution problems (which never go well for end users). On Tue, Jul 12, 2011 at 12:19 PM, Roy Chastain <r...@roychastain.org> wrote: > 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 > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ 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
