> 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. Yes, the log indicates that it is cached. Should it be? Do I need to file a bug about files remaining cached when the install errors?
To further expand on the topic of the Burn application being installed and cached files. I am confused about the following scenario. Without Burn, I would create a new MSI with a new product code and release that to my customers. That would run and take care of upgrading to the new version of the product. How does that work with Burn and cached files? Since (at least in the erring case) Burn does not seem to realize that my embedded (attached container) file is new, it runs the old one. Currently I have the InstallCondition for the .MSI set to "1" to always force it to run regardless of whether Burn thinks it is installed or not. I guess another way to ask the question is, "what would make Burn realize that a file, msi, exe etc - not just an embedded one - is actually different from the one that is cached"? > The Package @Compress and @Cache attributes are completely independent. Understood, but again, intuitively. attached containers should not be cached as a default. Since my file was cached and I did not specify, I assume the default for Cache is Yes. ------------------------------------------------------------------------------ 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
