OK, done some testing:

* WixBundleInstalled does indeed report the installed state of the bundle,
before and after DetectBegin.

* A bundle can indeed install zero MSI packages and be installed. The
installation state of the bundle is independent of the installation state
of the MSIs contained within it.

The most common approach in sample code therefore appears to be slightly at
odds with how Burn works: that is, people writing Bootstrapper Applications
appear to be targeting installed/uninstalled MSI packages, not the Burn
package. (I suspect this is from trying to use Burn as a bootstrapper!)

Alasdair



On Sun, Apr 13, 2014 at 8:26 AM, Alasdair King <alasdairk...@gmail.com>wrote:

> Thanks Sean! However, I don't understand the discrepancy between your
> suggestions and what appears to be common practice in third-party sample
> code.
>
> My understanding is that a Burn bundle is a set of MSI windows installers
> packaged together inside a wrapper that handles the UI and logic. So it
> seems to me that you could have a Burn bundle installed but none of its MSI
> packages installed. Conversely, you could have the MSI packages in a bundle
> installed, but not the bundle*.
>
> So when I write "installed" I mean that the Burn *bundle* is installed,
> but not necessarily any of its packages.
>
> However, my model isn't reflected in most of the sample code I've seen,
> which checks for the presence or absence of an MSI in the
> DetectPackageComplete event.
>
> Actually, I realise now the significant exception to this is the MBA code
> in the WiX 3.8 source code! This uses the DetectBegin event and the
> Installed parameter, as you suggest. (Does Installed map to
> WixBundleInstalled?)
>
> SUMMARY: third-party sample code checks for the status of one of the MSIs
> to determine the installed state of the bundle, which seems to be incorrect
> to me. The WiX code checks for DetectBegin and Installed, which makes more
> sense. Neither uses WixBundleInstalled, though perhaps this is set by
> Installed after Detect. Is there any guidance on the recommended approach?
>
> * Delving into the registry seems to support this: the "Uninstall" entry
> (HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall)
> points to the bundle executable, not the cached MSI in the Package Cache -
> as I'd expect. Meanwhile I can see my MSI package in
> HKLM\Software\Microsoft\Windows\CurrentVersion\Installers (with the
> "SystemComponent" value set.)
> --
> Many thanks,
> Alasdair
>
>
>
>
> On Sun, Apr 13, 2014 at 1:22 AM, Sean Hall <r.sean.h...@gmail.com> wrote:
>
>> It depends on what you mean by installed.  The engine will install the
>> bundle when it runs Apply.  So if .NET gets installed but your MSI fails,
>> your bundle is still considered as installed.
>>
>> If you want to know whether your bundle is installed, then you should be
>> able to rely on the WixBundleInstalled property.  If you're having
>> problems
>> with it, please file a bug at http://wixtoolset.org/issues and provide
>> the
>> log.  You could also use the fInstalled parameter of the OnDetectBegin
>> event.
>>
>> Sean
>>
>>
>> On Sat, Apr 12, 2014 at 4:16 PM, Alasdair King <alasdairk...@gmail.com
>> >wrote:
>>
>> > I'm working on a C# Managed Bootstrapper Application. I don't quite
>> > understand how my bundle is identified as already-installed or not.
>> >
>> > Examples I have read simply check the installed state (PackageState) of
>> one
>> > of the MSI packages - for example,
>> >
>> >
>> http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/
>> > This is then used as the install state of the bundle.
>> >
>> > I have two problems with this:
>> >
>> > 1 It isn't correct, is it? What if a user has PackageA.msi installed,
>> but
>> > not through my bundle, and my MBA tests for PackageA.msi - this logic
>> will
>> > identify that the Bundle is installed when it isn't.
>> >
>> > 2 The WiX help says there is a property:
>> > WixBundleInstalled - gets whether the bundle was already installed and
>> will
>> > be set to 1 once the bundle is installed.
>> >
>> > So my question is:
>> > Why use the MSI package install state rather than "WixBundleInstalled"?
>> >
>> > (Testing indicates that this property is not in fact set for installed
>> > bundles. So is the answer "because WixBundleInstalled doesn't work
>> > properly"?)
>> >
>> > Thanks!
>> > Alasdair
>> >
>> > --
>> > Alasdair King
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Put Bad Developers to Shame
>> > Dominate Development with Jenkins Continuous Integration
>> > Continuously Automate Build, Test & Deployment
>> > Start a new project now. Try Jenkins in the cloud.
>> > http://p.sf.net/sfu/13600_Cloudbees
>> > _______________________________________________
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> >
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
>
> --
> Alasdair King
>



-- 
Alasdair King
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to