All true. However, changing the UpgradeCode wouldn't actually hide the
"superseded" Bundle in any way. You'd still see it and be able to remove it
and otherwise interact with it. I wasn't sure if hiding the Bundle was
desired by ACKH.
On Sat, May 11, 2013 at 8:19 AM, Heath Stewart <hea...@outlook.com> wrote:
> #3 was an explicit design goal - that upgrades Just Work. If you want to
> hide a patch bundle, use a unique bundle UpgradeCode.
>
> - Heath from Windows Phone
> ------------------------------
> From: Rob Mensching <r...@robmensching.com>
> Sent: 5/10/2013 9:22 PM
> To: Windows Installer XML toolset developer mailing
> list<wix-devs@lists.sourceforge.net>
> Subject: Re: [WiX-devs] Burn patch bundle limitations
>
> 1. Yeah, seems like a reasonable thing for the engine to detect. It'll
> be challenging to not elevate though because the engine will still need to
> write it's registration to the per-machine Uninstall key. So I'm not sure
> you'll be able to get rid of the elevation prompt completely, but it's an
> interesting thing to investigate.
>
> 2. This is a reasonable request as well. It isn't trivial to implement
> because it'll need to handle when multiple patches are installed and
> uninstalled. Probably have to implement a stack of patched versions and
> reapply the correct version on removal of patches. Not trivial.
>
> Note: We need to be *very* careful about creating communication between
> versions of Burn. The more intertwined Bundles shipped with different
> versions of Burn get, the more complicated it will be for us to do
> *anything* in Burn.
>
> 3. It seems like if a patch Bundle has the same UpgradeCode as a patch
> Bundle with a lower version, that the lower version patch Bundle will be
> removed when the new version is installed. This does not handle the case
> where you want the new patch Bundle to "hide" the old patch Bundle until
> the new patch Bundle is removed but that's not a scenario I think we should
> bother with. It seems correct to me that Installing multiple patch Bundles
> where some of the patches are superseded that all the patch Bundles still
> around stay visible. That way the user can remove patch Bundles in whatever
> order desired and the appropriate set of patches are applied to the
> machine. It also seems reasonable that a new patch Bundle removes an old
> patch Bundle. If the latter doesn't work, I'd consider that a bug in Burn.
>
>
> On Fri, May 10, 2013 at 12:01 PM, Hoover, Jacob <
> jacob.hoo...@greenheck.com> wrote:
>
> 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).aspxit
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
