4

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.

Community
  • 1
  • 1
BrainSlugs83
  • 6,214
  • 7
  • 50
  • 56
  • 2
    BTW, accepted answers and upvotes are appreciated. Consluting RFP's even more so. :) – Christopher Painter Jan 23 '13 at 01:39
  • 1
    +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 Feb 14 '13 at 03:22
  • 1
    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 Feb 27 '13 at 13:54
  • @Rob I agree. But telling a giant multi-national company to change their IT department's world-wide antivirus solution for an app that about %1 of the corporation is using isn't really feasible. – BrainSlugs83 Apr 10 '13 at 20:54
  • 1
    @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 Apr 10 '13 at 21:00
  • @Rob, What was the time frame when you sent that off? (Are we talking about weeks ago? Months ago? Years ago?) – BrainSlugs83 Apr 19 '13 at 00:19
  • 1
    @BrainSlugs83 about a month ago. – Rob Mensching Apr 19 '13 at 04:21

4 Answers4

4

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>
Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • I haven't really seen any examples of MSE projects -- can they do everything an MSI can do? Will the ISLE built setup.exe preload my prerequisites before it calls my WiX built MSE? With IS-PRO on a VM, if I edit the XML, will ISLE be able to open the IS-PRO generated project (and build it properly?) -- as an aside -- could I just edit the ISLE project file by hand and fix the conditions that way? – BrainSlugs83 Jan 21 '13 at 04:16
  • Apologies, I made a fail there: I typed "MSE", but I believe it should be "MSM". Looking at the [WiX MSM tutorials](http://wix.sourceforge.net/manual-wix2/authoring_merge_modules.htm) now. – BrainSlugs83 Jan 21 '13 at 06:12
  • Another fail -- looks like that link is to the tutorial for version 2 -- [this](http://wix.sourceforge.net/manual-wix3/authoring_merge_modules.htm) is the tutorial for version 3 -- I knew something wasn't write when they had their GUIDs exposed there. :-) – BrainSlugs83 Jan 21 '13 at 06:13
  • Hmm... Can you elaborate on this "Error Custom Action (MSI Type 19)" business? Examples, etc.? – BrainSlugs83 Jan 21 '13 at 07:04
  • 1
    I updated to include the WXS side. For the InstallShield side you have to go to redistributables and add the module (you will likely need to browse to it's location if it's not in your search path ) – Christopher Painter Jan 21 '13 at 14:07
  • 1
    Basically this builds an MSM (C/C++ .LIB) that serves as a form of encapsulation of a business rule. You can then add this to one or many installers to implement the behavior. I can give you a 15minute conference call / screen sharing session today if you need more information. – Christopher Painter Jan 21 '13 at 14:11
  • So -- uhh, I created an MSM -- but there's no where that I can find in the UI of the ISLE project to consume it... what now? I did some googling -- and found that this is a [known issue](https://connect.microsoft.com/VisualStudio/feedback/details/589033/support-merge-modules-in-installshield-le)? ISLE can't consume MSM files??? >. – BrainSlugs83 Jan 21 '13 at 17:03
  • 1
    ISLE can't consume MSM files? I wouldn't believe everything you read on the internet. Most people posting are application developers who don't take setup development seriously. In solution explorer go to your ISLE project and expand (2) Specify Application data. Double click Redistributables. Righlt click the list that comes up and select Browse for Merge Module. – Christopher Painter Jan 21 '13 at 17:19
  • Well... that got me past that, I'm still not convinced Install Shield is the right route -- the VSTO 4.0 prerequisite is failing when I set it to download, and when I set it to include itself in the exe the installer balloons up to 248 MB ... which is definitely not an option (Already the installer that downloads all the prereqs is 3.7 MB, which is ridiculous) -- not to mention the VSTO web downloader from the Windows SDK, not only works, but is only 2.7 MB (or the x64 version is 3.4 MB)... I'm pulling my hair out here. – BrainSlugs83 Jan 23 '13 at 01:25
  • Take a look at #6 - Prepare for release | Releases | Builds/Express/Single Image | Setup.exe tab page. On there you will see "InstallShield Prerequsities Installation" where you can control whether to include the prereq in your EXE or to download it as needed during the install. – Christopher Painter Jan 23 '13 at 01:35
  • That setting is global. If you select the "follow individual selections" option you can go to #2 Specifiy Application Data | Redistributables and right click the prereq in the list. Select Properties and then select from the Build Location drop down. – Christopher Painter Jan 23 '13 at 01:38
  • Right, #2 was how I was doing it before -- cool tip about the global setting in #6 -- when I switch it in #6 though, it suddenly adds the .NET 3.5 prereq. to my installer (I already had the .NET 4.0 prereq.) -- weirdly I can't reorder this prereq. -- it doesn't show up in the list -- only when the installer is run does it show up. The really crazy thing though, is that specifying download from web in #6 causes the download to work now! Even stranger -- when the installer goes to download .NET 4.0, it is now flagged as a virus by Norton AV as well. This is really just plain nuts. – BrainSlugs83 Jan 23 '13 at 05:17
  • 1
    One of your other preqeqs must be expressing a dependency on the .NET 3.5 prereq. If you add it explicitly you should be able to sort the order. Yes, bootstrapping and chaining is complicated stuff. ISLE doesn't provide the prereq editor so if it doesn't work out of the box you are kind of stuck. This may or may not be the right tool for you. It's hard to say without looking at your entire situation. That said, I have made really complicated stuff work using ISLE but then again I'm a special kind of crazy. – Christopher Painter Jan 23 '13 at 13:42
  • I looked directly at the .prq file -- VSTO 2010 has the .NET 3.5 dependency. -- I think ISLE is too much of a headache for me, I really just needed a bootstrapper for an .msi that currently works. For now, I just created an oldschool .vdproj and stole the setup.exe out, and packaged it with my WiX generated .msi file (I'm now in the running for the worst hack ever awards, for 2013). -- Since the prereqs don't change, I can just hold on to the setup.exe as a resource for the life of the project. Thanks for all your help by the way. – BrainSlugs83 Jan 25 '13 at 22:04
  • I have my own TFS instance with many samples to pull from over time so I guess I get going faster. – Christopher Painter Jan 25 '13 at 22:30
2

I'd like to get all the issues you raised about Burn fixed. If you could file bugs on the issues, that would be very helpful.

In the meantime, if you're using WiX toolset v3.5+ you might look at setupbld.exe. That tool can create a tiny pre-req installer that launches a pre-req and then a single MSI.

Note: our goal in the WiX toolset is to ultimately subsume what that tool does with Burn so bug reports where Burn does not work are much appreciated.

Rob Mensching
  • 33,834
  • 5
  • 90
  • 130
  • 1
    PS: I've submitted the Burn engine to the whitelist for Symantec. Hopefully that will help them reduce the false positives. – Rob Mensching Feb 27 '13 at 14:18
  • Thanks, Rob! -- I may get to revisit this issue in a few months -- I'll let you know how it goes, and file bugs at that time if the issue still persists. – BrainSlugs83 Apr 10 '13 at 20:56
0

NSIS can be integrated with Visual Studio (2005/2008/2010 and 2012) by an addon called Visual & Installer. Inno Setup is supported too. If you are looking for simple and cheap solution go for this (both NSIS and Inno Setup are freeware systems with huge community around.)

I don't have any experience with WiX, but NSIS and Inno Setup cannot create MSI files(s), only EXE file(s).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Slappy
  • 5,250
  • 1
  • 23
  • 29
  • I have a requirement to build MSI based installers -- executables are fine for end users, as they can install prereqs and what not, but admins will need to be able to deploy the MSIs. – BrainSlugs83 Jan 21 '13 at 14:20
0

In the end Install Shield LE ended up being too much of a headache for me, what I ended up doing was creating an old school 2010 dummy .vdproj based setup project with the correct prerequisites (Windows Installer 3.1, .NET 4.0, and VSTO 2010).

I built it once, and stole the setup.exe (I made sure other things like the upgrade code, etc. matched my current WiX based .msi file -- and the that .msi it generates was the same name I wanted to use, etc).

I package that setup.exe up with my WiX based .msi file and everything works great -- it's definitely a huge hack -- but it's the only solution I could find that both works out of the box(-ish), and does not set off Symantec SONAR anti-virus.

I do not build the .vdproj every time (I've only built it once, I deleted the .msi file, and harvested the setup.exe), so there is no future dependency on Visual Studio 2010 going this route.

For a less hacky approach, see @Christopher Painter's answer -- if you can make his approach work for you, I recommend his approach over mine.

BrainSlugs83
  • 6,214
  • 7
  • 50
  • 56