Install multiple exe with wix toolset - windows

I have three products which have their installers in .exe files.
Let us say the installers for the three three products are
Product_A.exe
Product_B.exe
Product_C.exe
I want to create a msi file using wix toolset which will install these three exe installers.
What is the best way to do this?
I want to also fail my MSI in case any of the three exe fails to install.
I am new to these so please help.
Any example would be highly appreciated
I also plan to uninstall these products once I uninstall my msi.
Thanks in advance for any help

Tools: There are a number of tools available for MSI creation. Some commercial and WiX - the open source solution. Here is a quick summary of tools. The commercial tools are excellent but expensive, WiX (free, open source) is also excellent but has a learning curve (XML text sources). Remember that a setup consultant can help you make such packages pretty quickly in most cases, but you might need the knowledge in-house. Long review of tools.
Cohesion & Coupling: You might need to create 3 different MSIs to install these products, or you could put them all in the same MSI. Here are some considerations to decide what to do. Remember to not be dogmatic but practical - what will work best for your particular case? You can allow only some of the tools to be installed by exposing features in the MSI you make - allowing only some features to be installed from a single MSI. Feature sample screenshot.
Setup.exe: There is also functionality to allow a setup.exe bootstrapper / installer launcher to install multiple MSI files wrapped inside it in sequence. WiX has the Burn component, and commercial tools have various options for the same (InstallShield Suite Projects, prerequisites, etc... - info here).
Details: As to the actual setups. You need to determine what they actually install (bullet point 3) - prerequisites and all (COM, COM+, GAC, Java, VC++ runtime, etc...). That might or might not be available to you via 1) documentation of in-house expertise (developers). 2) You can extract files from the setup to look at (check if they are MSI files already coming out of the setup.exe!), 3) install the setups and inspect the application operation with dependency / profiling tools. 4) The best is to find the old setup scripts used to compile the old setup exes. 5) You can also "capture" old setup EXE files to auto-convert to MSI. This needs serious cleanup at times from experts and it requires expensive tools - generally. See more info here. There are probably further approaches too. Developers will dump files in place, start registering them and install runtimes and keep going until things (appear) to work in order to figure out what to do in the setup (have them jot down some good notes).
Packaging Team: Note that most big companies have whole teams to take care of such setup conversion to MSI - generally referred to as "application packaging". If you are in a big company, maybe try to locate them and see if they can help (or just get them to capture your setup for you - with the expensive tool - for you to clean up - it is no picnic to clean).
Links:
A long answer on features, setup.exe launchers and how to decompose and bundle setups

Related

Generate an installer

Over the years our InstallShield code has grown un-manageable and messy. We're about to design an InstallShield 2015 installation from scratch for a new major release, and I was wondering if there's any way to automatically capture a set of system changes to use as a cleaner starting point for developing a new install package. Ideally, I would like to turn on some capturing software, install the oldest release from which we support an upgrade, install the latest service packs, and then apply the manual changes that will get the new release running on the system. Then I would turn off the capturing software, and it would provide an InstallShield project pre-loaded with all the files and registry entries (GAC changes, .NET assemblies, etc) that were created as part of that install. Then I could add steps to delete those that we no longer needed and do some other clean-up and refinements. Does such a thing exist?
Yes, this is called a repackager most often, in the enterprise world where sys admin and packagers prepare applications for deployment on the company machines.
Flexera has one that can create a project for InstallShield, but it is sold together with their AdminStudio solution, which is not cheap.
We (at Caphyon) have a repackager included in Advanced Installer (the architect edition) which also requires you purchase license. And of course the generated project will be compatible only with Advanced Installer, where you can configure your installers as you wish.
I think there is also a free repackager, AppDeploy from Dell, but I never used it, so I don't know how accurate it is and if you can use the results created into InstallShield or if it generates directly an MSI.
If you started looking more careful you will probably find other repackager tools, but you should know that building such a tool is not an easy task so choose carefully. Also probably only the one from AdminStudio will be able to generate a project that can be read by InstallShield.
If you already have the source projects from the older editions I would personally not try using a repackager. Instead I would go for cleaning up all the configurations which you do not understand and re-build them from scratch.
A repackager as good as it can be still has some problems. It can capture incomplete data, for example if you have a custom action that runs different code based on the OS where the installer is running the repackager will capture only its effects on the OS where you run it. On another one might run differently and have another output.
Also if your installer has prerequisites and you run the repackager on a machine where those prerequisites are installed then the repackager will not capture anything related to this, so by accident you can forget to include required prerequisites in the new package.
There is also the things like meta-information which few repackagers can detect. For example files associations which are actually a set of file and registry entries connected together or environment variables, scheduled tasks, etc...
Most repackagers capture all this data and simply show it to you as configuration files and registry entries, instead of creating the correct entities in your projects, i.e. files associations, environment variables or scheduled tasks in their correspondent views.

Are Visual Studio Setup projects suitable for complex setups?

Are "Visual Studio Setup" projects suitable for complex setups in different versions?
The application is rather large (> 500,000 lines of code) and is under continuous development. Every 6 to 10 months a new version gets released. We have multiple configuration files (INI and XML), registry keys, database migration scripts, etc. The application is in the progress of being migrated from Visual Basic 6.0 to .NET. The old installer was build with Installshield. The feedback to Installshield is: Bad adaptability, bad reuse - that's why we are evaluating "Visual Studio Setup" as an alternative.
Other products we consider:
Free Solutions
WiX
NSIS
Commercial Solutions
Installshield (again...)
Wise
Advanced Installer
Is Something missing?
Solutions we don't like to consider:
Inno Setup (it just doesn't feel right)
No, no, no and no to Visual Studio Deployment projects. I've been there on "large" projects (15,000 files with thousands of merge modules and hundreds of InstallUtil custom actions because VDPROJ exposes almost nothing of the underlying MSI such as creating services). I could go on for hours about how horrible it truly is.
I have a team of four installation developers and we use a mix of WiX and InstallShield. Our typical install has nearly 100 features, 800 merge modules and 15,000 files. We deploy nearly every type of resource you can imagine including chaining third-party installs to create complete products or systems. We are able to do this for over a dozen products each building off of multiple integration, release and maintenance branches. The four of us support an organization of over 400 people with around 250 developers.
We are able to do this because InstallShield actually can give you a fair amount of reuse. You use product configurations and features / merge modules to create encapsulations of groups of files and business logic. Still, WiX does a better job (although much harder to learn and feature holes here and there that we still need InstallShield for), so we have been slowly transitioning our baseline over to WiX where possible.
Don't go there!! We thought it was feasible for a few simple installers but it has turned out to be a nightmare... At a first glance the VS setup projects look ok, but soon you'll realize the various deficiencies - meaning that you'll write a bunch of custom action code for accomplishing just the simplest tasks (e.g., service handling and installation into well-defined special directories that are just not accessible from the "nice" setup project GUI).
You can only use some very basic forms to get user input (password input is for instance not possible). There is no automatic incrementing of installer version numbers. The file handling is horrible - you manually have to pick each and every file. That is, you cannot just say "install all files in this directory into that directory" - fantastic task to sit and manually scan for new files in a directory with hundreds of files.
No, go for WiX, although the learning curve might seem slightly worse than for the VS installers - but I have regretted it many times that we didn't do that.

Capturing all changes during an application install on Windows

I need to monitor and report on all changes (folders and directories added, permissions changed, registry entries added) that are made during the installation of a software program. Can anyone suggest a tool that is capable of doing this?
Thanks, MagicAndi.
Note: Please see my other answer below as well.
Seeing as you want to create a Wix setup, I want to add a new answer with some hints on how to accomplish this in the quickest way.
I would recommend using the InstallRite (no longer available) software to get a log of changes done by the installer you got. This tool does not allow you to convert the capture into an MSI, but it gives you a good change log (which does contain a bit of junk). The PictureTaker tool appears to have been renamed and is now commercial - it does allow conversion of the capture to MSI though.
There seems to be a new capture tool called Scalable Smart Packager CE (link removed Nov, 2017 - target site has changed and looks a little suspicious). I have not tested this tool thoroughly.
Once you have your log or capture, you can convert to WIX in 2 "fast track" ways:
Use the dark.exe WIX MSI decompiler (if you have an MSI already)
Use the heat.exe WIX harvester tool (to auto-generate WIX XML for folders, registry etc..)
If you use the dark.exe tool you should get a complete WIX XML file that you can then compile again - but you should clean it up a bit (take out the UI junk, then link with WIX's detault built-in GUI etc...).
Using heat.exe is the cleaner way. You simply run the heat.exe tool against a folder, and it will create WIX XML elements for you to install those files. You will then need to put it all together in a WIX source files along with other required sections. I can provide you with a basic WIX "minimal sample" to get you going (I don't seem to be able to attach files here).
Looks like this is a duplicate of a question answered already on ServerFault (my bad!). The answers given there are:
Process Monitor from SysInternals Software
Total Uninstall from Martau.com
UPDATE: Stefan Kruger's comprehensive list of repackaging tools at installsite.org.
Your question is a bit open ended since it is not entirely clear what the overall goal is:
Application Repackaging: capture all changes and then package them into a deployable package format such as MSI (or similar).
Reporting / Monitoring: just looking for a way to "see what happens" during an installation.
For application repackaging the main tool is AdminStudio (the main competitor "Wise InstallStudio" was pulled from market due to legal issues, see Wise section here: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc).
AdminStudio has very comprehensive feature sets and a hefty price tag (and learning curve). You could try to use the trial version to do your repackaging and see if the resulting MSI is useable. If it is not you can convert it to a Wix MSI relatively easily via the dark.exe Wix tool.
Then there used to be more light weight tools such as PictureTaker and InstallRite which I suppose were better suited for "reporting purposes" but could be used for MSI creation. Both these tools seem to have disappeared as well.
There seems to be a new capture tool called Scalable Smart Packager CE (removed broken link Jan, 2018 - the tool appears discontinued). I have not tested this tool thoroughly.
UPDATE: I just removed a broken link to Scalable Smart Packager CE (appears discontinued). For repackaging software / tools, perhaps see Stefan Kruger's comprehensive list at installsite.org. Hard to keep up with all these tools that are useful but end up deprecated.
You could use the method suggested here: Tracking file and registry changes, or you can try to locate the old version of WININSTALL LE on a Windows 2000 Server CD in \VALUEADD\3RDPARTY\MGMT\WINSTLE.
I believe Advanced Installer allows capture, but I am not sure you can export a proper MSI file with the trial version (or at all for that matter).
I've used Process Monitor on multiple occasions to document the impacts of installing COTS software on servers. Has always seemed to do the trick.
There is a programme called "sandboxie"
You'll need to configure it once its installed for it to work properly.
run sandboxie. drag and drop the installation file into the gui and watch it try to install.
Sandboxie creates a log of everything that happens. While it redirects all of the exe - DLL - inf - scripts and everything else into a quarantine file instead.
The SB GUI then lays out the file structure to all the intended installation locations.
Any download Im not too sure is legitimate, now gets downloaded and executed straight through SB's web browser feature. I can then check it all out and it never infects my system if it is naughty.
On the other hand...
If it was a online installer.exe that was executed in SB gui, youll now have a copy of everything that makes up the installer package. Place it all in a file on a USB, make a simple autorun.inf and .bat file with notepad++ to create ya own offline installer
Hope this helps...

Are there any limitations with Visual Studio Setup Projects?

Are there any limitations that I might face when using VS Setup Projects?
I plan to use them, but am not sure if this would be a good idea.
Well, in a more advanced setting: VS Setup Projects cannot be automated, e.g. you cannot put your project and the VS Setup Project on a build server and have them built automatically. This might not be an issue for a smaller shop or a single developer, but for a larger enterprise-level development environment, this alone can be quite a killer criteria.
In order to get around this, we use WiX for our setups - more work once up front, but works nicely with continuous integration.
Marc
They are OK, if your starting from scratch I would say look into WIX, or even pony up the cash for Install Shield or one of the other commercial ones, would save you time and money in the long run.
Builds can be very slow, especially if you have a lot of binary files. I have a project with a lot of product images that get packed into the install package, this takes a LONG time, even on a fast machine.
Visual Studio Setup projects lacks a number of key features that Windows Installer Provides. Most notable of these is the 'Feature' feature that allows you to setup several tools that the user can choose to install or exclude. As already recommended, use WiX or a 3rd party full-featured installer tool.
It depends on your project I suppose. It used to be a pain to use to set up web projects, but I think there is an addin now that makes creating a web app setup a lot easier.
More limitations...
There is no way in setup project to perform validation on data that has
been provided by the user on the UI dialogs (acquisition phase).
There is no way to designate a custom action to run with elevated
privileges(System account).
There is no way to make your custom action execute during UI sequence.

HOWTO and best working installation (MSI) chainer +/ bootstrapper

Our product has several products that customer can install created as separate installation packages (MSI).
We have a requirement to have single package for the installation that will:
Show one UI with progress
Allow user to choose which features/packages to install
Have ability to constrain one feature to another (e.g removing or adding effect other)
Support single elevation (UAC)
nice to have ability to auto update (not must)
support command line + silent installation
the package should be built out of the isolated installations (chain them)
raise error / messages for missing prerequisites
Support patches over time and major upgrades
Today we do almost all of the above using MSI with nested installations which is bad practice and we face too many issues in our solution.
i know that there are several bootstrappers out there (m$ generic bootstrapper which i think is not good, BURN is the WIX version which is not mature enough)
Do you know of other? that work and tested already ?
What is the best method to do (without unification of the MSI into a single MSI)
dotNetInstaller looks promising. I was experimenting with it to install java as a prerequisite. It comes with a GUI editor so you don't have to sort out the xml to create a project. The config file is in xml, and the InstallerLinker can be run from the command line. It could be integrated with a build server, though some msbuild tasks would be nice.
project home:
http://dotnetinstaller.codeplex.com/
tutorial:
http://www.codeproject.com/KB/install/dotNetInstaller.aspx
Create an InstallShield InstallScript package. Use the InstallScript package kick off the .MSIs with "-qn" one by one. I do this and am successful with it. I believe it meets your all the requirements you listed.
Until Wix's Burn is ready we really don't have much of a choice when it comes to bootstrappers.
If you are using InstallShield as your msi designer, one thing you could try is making an InstallScript project that contains all the different msi packages. You could then silently install only the desired packages. InstallShield is pretty expensive though, so if you don't already have it, you'll probably have to end up rolling your own bootstrapper.

Resources