1) +1 for this feature, it just hasn't been implemented as of yet. From http://msdn.microsoft.com/en-us/library/windows/desktop/aa372388(v=vs.85).aspx / http://msdn.microsoft.com/en-us/library/windows/desktop/aa370131(v=vs.85).aspx it looks as if there is a means of detecting if the existing install supports LUA.
>From a quick scan, it looks like for this to work you could tweak ><\src\burn\engine\msiengine.cpp> MsiEngineDetectPackage to call >MsiGetProductInfoEx function to query for the >INSTALLPROPERTY_AUTHORIZED_LUA_APP property and store that as an attribute of >BURN_PACKAGE. From there, I haven't dug deep enough to know all the places >where fPerMachine is being used. In addition, it looks like you'd want to do >some verification of the signature of the patch verses the existing install >via WinVerifyTrust. 2) This is probably caused because your MSI is hidden in ARP and the bundle is the visible entry. 3) Not sure on this. I'm thinking my process is a bit unique. (I'm also still using MsiMsp to make patches.) -----Original Message----- From: ACKH [mailto:forforumh...@hotmail.com] Sent: Thursday, May 09, 2013 5:54 PM To: wix-devs@lists.sourceforge.net Subject: [WiX-devs] Burn patch bundle limitations Hi all While building an installer using WiX 3.7.1224.0 I came across some limitations of the Burn engine which I would love to see removed. I'm absolutely willing to help implement the necessary features but please be aware that I'm not yet familiar with the Burn code base. Therefore I'm hoping for some guidance from you WiX developers. Namely the limitations are as follows: 1. LUA patching / UAC patching: Creating a Burn patch bundle containing only UAC patches and installing this bundle after the base bundle has been installed leads to a UAC prompt although the UAC patches contained in the bundle do not require elevation even when installed by a user. It seems that Burn does not support LUA patch Bundles. I found the following topic which is almost a year old: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-LUA-Patching-td7578580.html I checked Bobs approach and changed MspPackage/@PerMachine to "no" but in such a case the patch installation fails. Personally I find UAC patching quite useful and I dislike the idea that the Windows Installer technology offers me something that cannot be used by Burn. As I'm not yet familiar with the technical details of the implementation I'm hoping for some insight here. Would it be practicable to support UAC patching in Burn or is this a given design limitation? If so, are there other approaches you have already considered? Where in the Burn code base should I focus on to gain more insight? 2. Version number in ARP after patching a Burn bundle: Installing a Burn patch bundle correctly leads to an entry in the ARP (in "View installed updates" on Windows 7) but in the main ARP view ("Uninstall a program") the version number of the patched Burn Bundle is not changed at all. I found the following topic where this behavior is confirmed: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-Version-and-patching-td7579655.html#a7584962 Resulting from this topic is the following feature request: http://sourceforge.net/p/wix/feature-requests/725/ This feature request is still open. I consider this feature important because I realized that most users are totally unaware that there is a separate list in the ARP for patches. Because of that many users are simply unaware that the product changed if the version number didn't. Again, it would be helpful if you could give me some advice where I should focus on in the code to get a better understanding and hopefully provide a solution for this. 3. Superseding Burn bundles: When building Windows Installer patches (.msp) WiX offers me the Supersede attribute of the PatchFamily. This way a newer patch will replace an older patch and the older patch is not visible anymore in the ARP. I could not find anything similar in Burn, i.e. Burn patch bundles do not seem to offer me a supersede option. Again, this would be helpful because if I create multiple Burn patch bundles containing cumulative patches I would be nice to be able to get rid of older patch bundles in the ARP. I found the following topic that addresses this issue but it did not get anywhere: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-Bootstrapper-Second-Patch-does-not-supersede-first-Patch-td7581779.html Am I missing something here or does this functionality not exist in Burn? Is this by design and on purpose? If not where in the code would I need to dive into to get a better understanding? I'm really grateful for what you guys are building here. The WiX toolset so far has helped me tremendously in deploying applications. Regards ACKH -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-patch-bundle-limitations-tp7585779.html Sent from the wix-devs mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
