Alternatives to WiX Burn Bootstrapper? (Can the InstallShield LE bootstrapper be used?)

Question

Background information:

We used to have a Visual Studio 2010 based installer project, but our install situation got a lot more complicated, and with the projects going away anyway in 2012, we figured we'd start learning WiX / InstallShield LE.

The Problem:

InstallShield LE seems far too limited in the MSI files it creates to fit our needs -- (example, if you check the Office 2007 prerequisite, even though the error says you need "Office 2007 or later" it will fail if you have Office 2010 installed instead -- you can check one or the other, but you can't create an OR condition -- there's a lot more that's just the tip of the iceberg). -- The bootstrapper it creates, on the other hand, is super awesome!

WiX, on the other hand, worked great for making our MSI, but the Burn Bootstrapper has been just one headache after another -- we finally got it working -- but now on our clients' boxes, it's not only failing to elevate when it launches the MSI file, but it's getting detected as a virus by Symantec SONAR and the install is being blocked anyway! (This doesn't happen with InstallShield LE, and code signing certificates are too cost prohibitive for this project.) Honestly, I'd love to just NOT use the Burn Bootstrapper.

The Question:

What alternatives to the WiX Burn Bootstrapper are there? Could the InstallShield LE one be used? What about NSIS? (Does it integrate with Visual Studio 2010/Visual Studio 2012 at all?) -- I'm hoping to do web installs of our prerequisites to keep the installer file size down -- and yes, I have to maintain the .MSI as well (otherwise, I would just switch to full-on NSIS at this point).

Resolution:

While I couldn't make Christopher Painter's solution work, I marked it as the answer because I believe it is the best approach suggested. I went with a pretty evil little hack of a solution, but if you can make Christopher's approach work, I think that's the way to go. If you can't, maybe my hack will get you unstuck.

BTW, accepted answers and upvotes are appreciated. Consluting RFP's even more so. :) — Christopher Painter
+1 FWIW, I thought you did a nice job of describing your problem and laid out specific conditions ahead of time (as evidenced by the fact that nobody needed to ask additional questions in this comments area...) — Lynn Crumbling
Is the only issue with Burn the false positive by the virus checker? If the virus checker is causing issues, the failure to elevate is very likely a symptom of that (since most virus checkers prevent/terminate processes that they suspect of being virus). — Rob Mensching
@BrainSlugs83 it isn't clear from the outside why the Burn executable get's picked up. After a few of these comments popped up all over, I sent the executable to all the major vendors so they could update their signatures. The issue seems to have dropped off a lot since then and now it's often antivirus products that are out of date that have issues. Additionally, signing the Bundle always seemed to avoid false positives by the tools. If there is more we could do in the WiX toolset, we will do it. It isn't clear what that is... or that this is still a major problem any longer. — Rob Mensching

Christopher Painter Christopher Painter · Accepted Answer · 2013-01-21T03:46:51

For around $2K you could upgrade to InstallShield Professional. However, if you are mostly happy with ISLE and can live with only having 1 feature and no customizations of the UI, I can solve the problem regarding Launch Conditions for you.

See my blog article:

Augmenting InstallShield using Windows Installer XML - Certificates

The concept is you author a WiX merge module that searches for the two office versions and schedule an Error custom action (MSI Type 19) that uses the two searches in a logical or condition. Add that to your ISLE project and you've just "blended" the two technologies.

Professional also gives you the PRQ (XML prereq file) editor. Then again throwing the 30 day eval on a VM can get you the same result.

Here is the WXS side of it:

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Module Id="ISWIX.REQUIRE.MSOFFICE20102013" Language="1033" Version="1.0.0.0">
        <Package Id="10ed24f2-6c07-4066-9f39-ba9f66c2667b" Manufacturer="ISWIX, LLC" InstallerVersion="200" />
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="MergeRedirectFolder"/>
        </Directory>
        <Property Id="OFFICE2010FOUND">
            <RegistrySearch Id="findOffice2010" Root="HKLM" Key="SOFTWARE\Microsoft\Office\14.0\Common\InstallRoot" Name="Path" Type="raw" />
        </Property>
        <Property Id="OFFICE2010X64FOUND">
            <RegistrySearch Id="findOffice2010X64" Root="HKLM" Key="SOFTWARE\Microsoft\Office\14.0\Common\InstallRoot" Name="Path" Type="raw" Win64="yes" />
        </Property>
        <Property Id="OFFICE2013FOUND">
            <RegistrySearch Id="findOffice2013" Root="HKLM" Key="SOFTWARE\Microsoft\Office\15.0\Common\ProductVersion" Name="LastProduct" Type="raw" />
        </Property>
        <CustomAction Id="ErrorNoOffice20102013" Error="[ProductName] setup requires Microsoft Office 2010 or 2013." />
        <InstallUISequence>
            <Custom Action="ErrorNoOffice20102013" After="AppSearch">Not OFFICE2010FOUND and Not OFFICE2010X64FOUND and Not OFFICE2013FOUND and Not Installed</Custom>
        </InstallUISequence>
        <InstallExecuteSequence>
            <Custom Action="ErrorNoOffice20102013" After="AppSearch">Not OFFICE2010FOUND and Not OFFICE2010X64FOUND and Not OFFICE2013FOUND and Not Installed</Custom>
        </InstallExecuteSequence>
    </Module>
</Wix>