Hm ok. For me it would be great having such a UpgradeCodeSearch
element to not need a custom Burn Bootstrapper...
BTW: Also returning a string with all detected UpgradeCodes would be great :-)
Best regards,
Tobias
2011/10/23 Rob Mensching :
> Burn does exactly what you ask. It comes in the
> IB
Burn does exactly what you ask. It comes in the
IBootstrapperApplication::OnDetectRelatedMsiPackage(). Your BA gets all the
information.
What does not exist is an "UpgradeCodeSearch" element to create a property
from some discovered ProductCodes.
On Fri, Oct 14, 2011 at 1:29 PM, Tobias S wrote:
As posting that feature request maybe some additional words :-)
Personally I frequently use the FindRelatedProducts +
(GetRelatedProducts in DTF) to detect other installed MSIs.
E.g. for my DTF implementation I use the limitation that it only works
in case GetRelatedProducts returns exactly one p
would allow us to query for further information in a
different element or UX.
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Friday, October 14, 2011 10:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn in 3.6
3. I
nto the latest codebase.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Thursday, October 13, 2011 9:56 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Burn in 3.6
1. Documentation in Burn is lacking. I personally still tend
1. Documentation in Burn is lacking. I personally still tend to optimize
fixing bugs over writing documentation. If find this to be optimal because
fixing bugs sometimes changes what the documentation would say.
You might argue that lack of documentation prevents people from finding bugs
(because
6 matches
Mail list logo
