Due to severe limitations of the Microsoft Windows Installer (MSI) system it is required to create a bootstrapper in order to install multiple MSI files (due to pre/post-requisites). However, this introduces an distribution problem because you now have multiple files that need to be included with the distribution. There are of course multiple ways to distribute this as a single file.
1: An archive
You can put all the files into a single archive that users download. The obvious choice for MS Windows is of course a PK-ZIP archive. But this is not very user friendly. Users will first have to extract the archive, and then run the bootstrapper (which would be called setup.exe).
2: A SFX archive
Instead of distributing an plain archive file you could wrap it into a self extracting archive. Executing this SFX archive would prompt the user to extract and/or run the contents. But this adds yet another prompt to the whole installation process (#1: SFX prompt, #2: bootstrapper prompt, #3: main installer prompt). This is also not very user friendly, as it increase annoyance due to multiple prompts.
3: Single file bootstrapper
Of course there is the option to embed all the extract files into the bootstrapper. This is probably the most user friendly for a normal end-user. However, this is less friendly for system administrators, because usually bootstrappers are less manageable than the MSI files. An admin would rig the system so that all requisites are also installed when the main MSI is installed, thus the bootstrapper would not be needed.
4: Other?
An other unlisted method?
So what do you think is the best way to distribute a installer for MS Windows software that requires a bootstrapper?
We provide a single file bootstrapper for retail distribution and all single-user installations.
Volume licensing customers (e.g. 10+ seats) receive one (or more) MSI files along with instructions and a list of prerequsites that must be installed before our application will run (which slightly differ between XP, Vista and Win2k). The EXE blocks installation if the prerequisites are not installed, the MSI will permit installation under the assumption that the sysadmin knows what they're doing and might be installing the prereq's at the same time, before the next reboot.
Basically the single bootstrapper is for non-sysadmins, people who want a single click solution. System administrators and corporate IT support who prefer more fine grained control over their installation are happy for multiple files, even if it means more work for them. The single EXE file is available publicly, the instructions + multiple files are only available by contacting our sales team.
This method gives us the best of both worlds, as well as the ability to provide different default configurations for home and corporate customers - hints, tips, splash screens, auto-updates and welcome dialogs are all disabled by default for corporate installations but enabled for "single" users.
We use Wix to create MSI files which is hugely flexible and can easily be automated with build scripts.
To chain multiple MSI/EXE files together for distribution via single bootstrapper I would highly recommend DotNetInstaller. I'm in no way connected or affiliated with this product, but it has been a lifesaver on projects for generating highly configurable bootstrappers in unmanaged code.
I wrote up my recent experiences in developing a multi-language MSI and bootstrapper using these technologies here. This talks through the process from start to finish. Using DotNetInstaller you can download and install dependencies from a URL on demand, or embed them directly within the bootstrapper with ease. I did also consider WIX's own SETUPBLD bootstrapper generator and the GenerateBootStrapper MSBuild task but they are pretty basic. That said WIX 3.5 Burn utility is currently in the pipeline and could be a pretty decent alternative once it's released.
Regarding: 1: An archive: 2: A SFX archive
You could use a self-extracting .ZIP that automatically launches a Setup.exe. WinZip offers this support inexpensively. That way, it would be more customer-friendly. It can be configured to launch the bootstrapper without a prompt.
Regarding: 3: Single file bootstrapper
At the risk of sounding like an InstallShield salesman, InstallShield 2009 will take care of everything you're asking about -- it smooths over the MSI shortcoming of needing a bootstrapper. You could use the Release Wizard to create a single-.EXE all-in-one bootstrapper. Or you could create a web-deploy setup that is very small and then downloads the payload from a web site. Or you could put different features in separate .CAB files, and the user only needs to deploy those CAB files corresponding to the features he wants to install. InstallShield comes bundled with dozens of prerequisites ready to add to your Setup.
Depending on your siutation, MSI v4.5 and 5.0 might help you -- they have native support for multi-package transaction chaining. Of course, depending on what OSes you support, you may still need a bootstrapper to make sure the right level of MSI support is present.
I had a similar problem where I needed to distribute some optional support software, MSI installer, and another file just incase the MSI file needed it. I basically created a native application to handle the whole process. I wrote a blog about it here (http://blog.foldertrack.com/?p=45)
Related
Pitch
I'm looking for high level advise on how to structure a WiX and Burn MSI based installer solution for an application suite.
Question
Given the layout below how many distinct MSI packages should an installer suite utilize when all apps/features and shared libs go into the same installation directory?
One single MSI package for the whole suite is clearly too large (as shown by the current system)
One (complete) MSI package per application would duplicate the dll libraries shared between the apps, which would mean a duplication of 100s of MB worth of DLLs. (Plus, to me, unknown headaches with MSI refcounting)
One MSI package per binary library and executable?
I.e., many MSI files would only contain a single DLL or a single EXE
Can I make sure the EXE MSI package is only installed when its prerequisite library packages are installed?
Background
Our application suite is layed out a bit like MS Office in that we have one installation folder where a series of applications is installed to together with all their shared library files. That is:
C:\ProgramFiles\MyApplicationSuite
\ - App1.exe
\ - App2.exe
\ - App3.exe
\ - ...
\ - libxy.dll
\ - qt.dll
\ - ...
Up until now, we had one single InnoSetup installer, that could install all of the apps as features, that is, there was only one single Programs entry in the Windows Programs list. This worked well because most of the time the whole suite was installed anyway, and some installations would maybe not use one or two apps.
Since the single setup approach start to break, and Corporate Requirements force me to switch to an MSI based installation, I'm looking into how to structure such a beast the best way using WiX, Burn and granular MSI packages.
Some thoughts along the lines of what you already state on the topic of splitting or merging setups: Wix to Install multiple Applications. Have a skim of this and see if there are any variables that apply (release schedule, localization, build speed, etc...).
You can use merge modules or WiX include files (basically works like a normal header file include in C++, it is a preprocessor operation) to include shared components in several setups. They will then be properly reference counted and you can distribute updates to them in a controlled fashion.
Personally I like to split shared components completely away from my main MSI and install them via a separate prerequisite setup and then bundle it all together in a bootstrapper made with Burn or equivalent toolkits designed to allow installation of several MSI and / or EXE files in sequence. I find this yields good cohesion / coupling. This is debatable. An MSI is more "self-contained" when it contains shared, embedded components (merge modules / include files), but particularly for corporate deployment I like to split all shared components to their own prerequisite MSI. There are some very technical reasons for this that I would need more time to explain than what is available.
I will leave it at that for now, possibly returning and updating later.
Some Links (primarily for easy retrieval):
How to express a file dependency using WiX
WiX (Windows Installer Xml), Create universal variables
Wix Installer : Setting component condition property when doing a MSIEXEC admin install at command line
Merge module files into different locations
MSI Reference Counting: Two products install the same MSIs
We have a product with more than 100 'pieces' most of which are optional 'plug-ins'. We would like a non-programmer to be able to make a "customized" installer on a per-customer/sale basis. Our ideal would be simply a single executable/msi with a folder structure from which files/folders could be deleted, then when run the installer would simply not offer features corresponding to the deleted bits.
A separate, but similar issue is that the developers of these plug-ins are not installation experts and we would prefer not to have to edit shared installer source to add/remove one from our build-set. We've been using the "synchronized folders" feature of Advanced Installer for this, but we would like a separately selectable feature for each plug-in.
Is there an installer tool-chain that can support such(or similar) behavior?
If so does anyone have tips on how to actually implement it using said tool?
I created such a tool stack at my last job. We did product line development with dozens of service families, hundreds of features, thousands of merge modules and tens of thousands of files in a typical installer.
Each merge module was authored using IsWiX and compiled using WiX. We then used WiX XML as an input to our build automation system to generate InstallShield installers. A service family would have an XML file to describe it's portion of the feature tree and it would all get emitted into an empty InstallShield project.
Finally a product XML file would describe the INSTALLDIR, UpgradeCode and other meta along with which features to consume. We built dozens and dozens of installers off this common base code.
It would take days to explain everything but that gives you the idea. For a simpler environment you could create a UI to generate WiX code and then compile it into an MSI.
But I don't know that I'd ever give this to a non-programmer. Creating installers is programming.
There is no tool that creates features at runtime in the MSI package, at least no MSI based tool. This complicates too much the installer logic, as you would need a very complex custom action that reads the contents of the folders found next to the installer and then generate entries in the following MSI tables: Files, Directory, Component, Feature, FeatureComponents. And then inter-connect all of this.
That is not something easy to do at all, and very error prone is tried by something how does not have extensive experience in building MSI packages.
have you considered/tried any non-MSI package builders?
I need to create a custom installer that supports French, German, Spanish, Italian, Polish, Russian, English, chinese (mandarin script), more languages to be added for a .net based application.
This installer also needs to be able to check whether the target system has got adobe installed or not. If the target system doesnt have adobe or is a lower version than required then it should install from the CD. if it does then bypass that step.
The installer also needs to prompt the user to browse to any location on the system to pick up a file which will be place in the installation folder.
The installer also need to register this program in the add remove programs list.
Is there a custom installer that can do all of these tasks or do I need to build an application from scratch for it?
Thoughts... ideas???
Thanks for your time...
Short answer : Yes, all those things can be done, most of them easily.
WiX or NSIS are probably your two best free options. NSIS uses a plugin architecture for most of it's functionality, but the plugins are text-files, so you should have no problems downloading them. However, if your company is "funny" about licensing, then check the relevant licenses for each plugin early on - most are completely free to use, but Legal can fail to understand this sometimes...
Please find below pointers to the relevant sections of the documentation, so you can get it downloaded (I feel your pain by the way!)
Language Support
See Docs
Allow user to select a file and copy it
You will need the InstallOptions plugin. This allows you to create an extra page in your install wizard which can prompt for information. It allows various controls, one of which is a file explorer control (search for FileRequest in the link).
To copy the file, you cannot simply use the File instruction, as that extracts and copies files from the installation media, and will not act on files on the target computer.
Instead, you will need a plugin - e.g. this wrapper around the WinAPI. Alternatively, use the CopyFiles instruction.
Register program in Add/Remove programs
This is standard in both WiX and NSIS.
Detect Adobe is installed.
NSIS has the ability to check if registry keys exist, or named files exist, which are the two normal methods of detecting installed programs.
I would like to know how can I detect if help file is contained in setup file for windows platform application (msi or exe). Is there any method to get this information without installing the software first ?
Of course setup file can be created by many setup makers like innosetup, installshield and so on. So I wonder if there is some universal method to solve this.
For an MSI based install it would be very easy. For example you can use the Microsoft.Deployment.WindowsInstaller interop via C# to open the MSI as an InstallPackageClass then access it's Files collection to see if it contains the file you care about.
For a Non-MSI based install, there is no universal way and in most cases, no way period. See, that's kind of the point of MSI: to have a standards based package rich in meta data to be able to see what it's doing. When you do some proprietary script driven installer you lose that openness.
If it's a MSI file, open it up using Orca, and you can view file names.
For both of them, you should be able to do an administrative install, which would extract the files, but not register anything. Depending on where the exe came from, doing an administrative install changes, since each vendor(installshield, innosetup, etc) has their own way to run an administrative install.
for a MSI it's simply
msiexec /a <msi_filename>
For an exe you'll have to look up how to pass the /a argument.
I would like to build a setup, or something like that (1 file), to deliver a single file to a target system. Plugin for an application, installable to users AppData folder.
After some research I'm still not sure in which direction to look. I can create the setup project with Visual Studio 2010, but all of the options so far seem to be way too heavy or have some flaws.
SetupProject stubbornly wants to create an application folder which I don't need, and complains about installation to user folder. Cab doesn't seem to offer automatic install, oneclick is not available for the project, etc.
Is there an easier setup technology I could use?
Requirements:
Install -> Copy 1 file to a folder
under %userprofile%\3rdpartyapp\ if
it exists (xcopy).
Uninstall -> Delete the file and also
one folder with custom settings
(rmdir \s).
Distribution -> Free for commercial
use.
Maybe I should just pack the file in self extracting c++ exe?
It may be overkill for one file, but I like InnoSetup for creating setup packages. Check it out, and see if it suits you. It is very easy to use and deploy.
Take a look at WiX toolset. It allows creating MSI-based installers, and the installer could be quite simple:
Search for %userprofile%\3rdpartyapp;
Copy the file into it, if it exists;
Fail install or maybe create it, if it does not exist.
Uninstall would be very simple: it would need to remove the installed file. To remove a subfolder of 3rdpartyapp, you can use RemoveFolderEx element.
MSI registers the installed app with Add/Remove Programs Control panel. Uninstall is handled by Windows Installer service, therefore you don't need to copy any additional files or programs to support uninstall.
I think any setup technology is too heavy for one file. I'd go with creating a simple application that would extract the file from its resources stream and copy it into %userprofile%\3rdpartyapp.
Uninstall is trickier: there should be something that can handle the uninstall process. It could be a batch or script (js, vbs) file stored somewhere in user's profile, another simple application or the same one. (Installation process can also be handled with a script.)