#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<mailto:r...@robmensching.com>
Sent: 5/10/2013 9:22 PM
To: Windows Installer XML toolset developer mailing
list<mailto: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
