I am starting to do some installer work using WiX (yay, not Installshield) and I was hoping to do some TDD of the installer. Does anybody know of an easy way to do this?
It sounds to me more like an integration test than TDD.
As far as i can tell there are no MSI testing suits per se.
Nevertheless you could try something like this ( assuming you have a contiunous integration server):
after successful build, install MSI on a clean virtual machine - if installation fails do something (mail, ticket, whatever)
run whatever integration tests you have on your project
After that you can be sure that installed application does what it should.
Does it make sence, if you create some script file that checks that files are on the right places. I expect make it as perl or python script
test_installer_wix.pl
msiexec /x product.msi # remove
msiexec /i product.msi /silent # install
ASSERT_EXIST_FILE(PFILE, 'productname/application.exe')
ASSERT_REGKEY_EXISTS()
and etc.
I want to add link to post about how to create unit test for WIX installer database: http://miroslawmiodonski.blogspot.com/2012/10/how-to-create-unit-test-for-wix.html
It might not be a bad idea to run a few standard tests on a generated MSI. MSI files support a lot of different deployment scenarios: admin install to extract files, advertised install for active directory, silent install, maintenance install, uninstall etc... Maybe it is indeed an idea to create a small test suite for this - perhaps it's even being considered for the WIX toolset for all I know.
However, I think the first, best step towards delivering a quality setup would be to run the MSI through the MSI validation suite. These are referred to as ICE (Internal Consistency Evaluators) and they are delivered as *.cub file with the Windows Installer SDK. Running these scripts tend to reveal lots of bad design constructs in the MSI. The WIX tool for this is called smoke.exe.
Related
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
I have asked this exact question on the Flexara forum, but got no response up to today, so I want to ask it here.
We currently have a InstallScript project which runs fine. The resulting setup can be made unattended/silent fine.
In this setup we have some features and invoke a number of third-party installations (that are a prerequisite for running our software).
However, we have customers that want an MSI file and therefore we resorted to the Basic MSI project type.
The setup is made without too much hassle (I'm fairly new to InstallShield) and I can generate a .exe and .msi from this project.
However the only issue I have left is invoking one of the third-party installers.
That third-party installer (made with NSIS) on its turn invokes another installer which is MSI based.
This results in having error 1500 - the fact that you cannot run a msi type installation while another is running.
I've tried scheduling the CA (that are used to invoke the third-party installers) as the first action and as last, but no success.
Before resorting on the more unorthodox scenarios (like creating a task on Windows Task manager that runs after our installer finishes, or at the next reboot and forcing a reboot - which our customers don't like) or a scenario that we don't bundle the 'faulting' installer (we really like to be able to hand over a single intaller and not multiple), I'd thought I ask your input.
I've tried searching for solutions everywhere on the internet, but either I'm failing due to wrong keywords or I just didn't stumble on the right post yet.
Are there any options left for us to create a single MSI installer that is able to invoke this third-party installer (which invokes a msi installer on its turn)?
Since an EXE bootstrapper is not acceptable, there is only one solution:
store the prerequisite installers in Binary table of your MSI
create some custom actions which extract them from this table and launch them
schedule them in InstallUISequence, for example right before Progress dialog
use searches to detect if the prerequisites are installed or not
condition your custom actions with the search results
Basically, you need to launch them during the installation UI. It won't work if you launch them during InstallExecuteSequence.
I don't think the basic MSI project supports this, but it may be supported by more advanced project types. Other setup authoring tools offer direct support for this.
You can try InstallShield's "Chained .msi Package" feature.
As part of our nightly build on windows, an installer package is created using NSIS. I would like to automatically test the "correctness" of the installer.
This might be things like:
Checking the platform of dll files.
Checking the install folder.
Testing the uninstall function doesn't leave any files behind.
Checking registry keys are created in the right location.
Are there any tools or techniques that could help me achieve this?
I don't think VM's or automated processes to push the package to the VM is an answer in itself. The real problem here is 'How do you know the integrated / deployed product will work?' I think the only answer to that question at this point would be to then have automated processes to test the application itself in the deployed state.
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.
Much searching has lead me to find several descriptions of how to create a bootstrapping msi, but these solutions all assume the msi is local or a standard Windows component. Is there a way to make an msi that downloads an installer (which is also an msi) with normal MSI or Wix code rather than by having the bootstrapper execute some non-native program to do so?
My experience with msi's has been it's not possible to run 2 at the same time. (could be wrong though)
What I ended up doing was to instead make an installer exe using Inno Setup (http://www.jrsoftware.org) and ISTool (http://www.istool.org) which downloads and installs the various msi's. With ISTool it's very easy to do.
I know it's not as chic or sexy as Wix, but it worked for me very well.
I would create a custom action that runs in the InstallUISequence. This would download the MSI if necessary (to the source folder), and then try to launch it as a nested installation.
Windows prevents two installs from being in the InstallExecuteSequence at the same time, so if you're looking for a silent install solution with a bootstrapper, you're SOL.
However you can start another install from the UI sequence, which is probably an OK solution as long as you advise your customers that certain other dependencies must be installed first if they're going to deploy via group policy or some other 'silent' method.
If it helps, I'm pretty sure you can also call MSIEXEC with a URL, eg. msiexec.exe /i http://some.domain/blah.msi /passive
I would suggest that you write a native app and have it run the first msi and then run the seccons msi. I wrote a blog on how to do this. Here is a link (http://blog.foldertrack.com/?p=45)