Hello, I have an odd problem. It's not /really/ related to Burn and I believe the problem lies with the MSI - but I think (hope) you can help me out.
My scenario is this: When I upgrade the Bootstrapper one of the MSI Packages is always detected as *not* having a dependency to the old Bootstrapper, and thus it's dependency is not moved to the upgraded one. When Burns wants to uninstall the old Boostrapper it tries to uninstall the MSI (and fails, because other MSIs are dependent on this) - and this leaves two Bootstrappers in the ARP. I have read the logs and my Bootstrapper and Burn is behaving exactly as it should. I can see that it's registering the dependency, just like with the other MSIs I have. But later on I can see that it cannot find this dependency. This leads me to believe that the MSI must be doing /something/ to break this dependency. My question is this: What can cause a dependency to become unregistered? (I have tried to use the DependencyExtension, like I do for our ExePackages, but this just registers the dependency one more time - and the behavior is the same as stated in the scenario) -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSIPackage-unregistering-dependency-to-bundle-tp7582489.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
