WIX Burn Bootstrapper not asking for admin rights for the MSI

The key thing to know is that there is a BootstrapperCore.dll in the WiX binaries that defines a BootstrapperApplication class that handles the integration with the Burn engine. I needed to create my own derived class and override the 'Run' method to launch my custom UI.

It was also helpful to use the WixBA project that defines the UI for the WiX bootstrapper as a reference for using the BootstrapperApplication class (src\Setup\WixBA\WixBA.csproj).

The markup I used to reference my custom bootstrapper DLL file is:

<BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost" >
  <Payload SourceFile="$(var.InstallSourceResources)Bootstrapper\FusionInstallUX.dll"/>
  <Payload Id="FusionInstallUX.config"
           SourceFile="$(var.InstallSourceResources)Bootstrapper\FusionInstallUX.BootstrapperCore.config"
           Name="BootstrapperCore.config" Compressed="yes"/>
</BootstrapperApplicationRef>

The configuration file consists of:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup
            name="wix.bootstrapper"
            type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">

            <section
                name="host"
                type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
        </sectionGroup>
    </configSections>

    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0" />
    </startup>

    <wix.bootstrapper>
        <host assemblyName="FusionInstallUX">
            <supportedFramework version="v4\Full" />
            <supportedFramework version="v4\Client" />
        </host>
    </wix.bootstrapper>
</configuration>

I also followed other examples and appended

[assembly: BootstrapperApplication(typeof([name of class deriving from BootstrapperApplication]))]

to the AssemblyInfo.cs file.

And lastly, Stack Overflow question Specify the INSTALLLOCATION of packages in WiX inside the Burn managed bootstrapper describes how to set and use Burn variables to help drive the installation.

Armed with this information I am now prepared to wreak havoc on the world with my very own custom Bootstrapper application!

tl;dr: "PECS" is from the collection's point of view. If you are only pulling items from a generic collection, it is a producer and you should use extends; if you are only stuffing items in, it is a consumer and you should use super. If you do both with the same collection, you shouldn't use either extends or super.

Suppose you have a method that takes as its parameter a collection of things, but you want it to be more flexible than just accepting a Collection<Thing>.

Case 1: You want to go through the collection and do things with each item.
Then the list is a producer, so you should use a Collection<? extends Thing>.

The reasoning is that a Collection<? extends Thing> could hold any subtype of Thing, and thus each element will behave as a Thing when you perform your operation. (You actually cannot add anything (except null) to a Collection<? extends Thing>, because you cannot know at runtime which specific subtype of Thing the collection holds.)

Case 2: You want to add things to the collection.
Then the list is a consumer, so you should use a Collection<? super Thing>.

The reasoning here is that unlike Collection<? extends Thing>, Collection<? super Thing> can always hold a Thing no matter what the actual parameterized type is. Here you don't care what is already in the list as long as it will allow a Thing to be added; this is what ? super Thing guarantees.