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)
Related
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.
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.
We are installing several web sites using msi's as part of continuos integration tests.
For each build we want to uninstall the old msi and install a new one.
Problem is we do not have the old msi after the build server has done a get latest and rebuilt the system.
Is there a way in which we can uninstall the msi without having access to the orginal msi?
Yes you can, if you know the product code. Just type
msiexec /x [ProductCode]
on the command line. Or you could do it through the Add/Remove programs applet.
If you want to find the physical file, Windows actually stores a copy of the msi when it runs it - you will find it somewhere in your %WINDOWS%\Installer folder, but it will have been given a random name so could be quite hard to find :)
Alternatively if you don't know the product code (which you should) then try searching for your app name under the HKEY_CURRENT_USER\Software\Microsoft\Installer and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData registry keys, you will find the product code there. (quick hint: you can also search for UninstallString values in the registry).
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.
I often get a problem with Windows Installer trying to uninstall a package, but it complains that:
The feature you are trying to use is on a network resource that is unavailable.
Is there a known means of uninstalling such packages when the original MSI is simply not available?
Please note that Microsoft has now released an official tool to resolve these issues, without the problems that previously existed with MSIZAP.
Microsoft Fixit: Fix problems with programs that can't be installed or uninstalled
Take a look at a tool called MSIZap released by Microsoft.
UPDATE:
MsiZap.exe has been deprecated for quite some time. Its use is unsupported on all recent versions of Windows, and it is considered a very unsafe tool to use.
I added a link to a newer Microsoft support tool designed to clean out installations, but this tool also appears deprecated at this point. I have removed the link from the comments section.
Perhaps try the tool linked to in saschabeaumont's answer below.
FYI, this post explains the root problem https://superuser.com/q/293542/245923
You can uninstall it using the product code:
msiexec.exe /x {your-product-code-guid}
You would obtain this code from the MSI itself, or whatever tool you are using to build the MSI.
Note that when you uninstall a product, it uses a cached MSI, since only the original MSI knows how to uninstall itself. When you use the product code, it uses the cached MSI from C:\WINDOWS\Installer.
Update, Stein Åsmul: There is a whole list of cleanup approaches here (recommended).
UPDATE:
This newer support tool can be tried on recent Windows versions if you have defunct MSI packages needing uninstall. This new tool appears to have been deprecated as well.
Perhaps try the tool linked to in saschabeaumont's answer.
It is not normal or standard MSI behavior to ask for the original source media - it indicates a badly designed MSI package. If you experience this with a vendor MSI it is highly recommended that you report the problem to their support team. Here is a more comprehensive explanation of the problem: Why does MSI require the original .msi file to proceed with an uninstall?
In most cases MSI packages can be uninstalled from add/remove programs from the control panel even if you don't have the original installation database for the MSI - the uninstall is run from a cached copy of the original MSI in the system folder %SystemRoot%\Windows\Installer (in some cases this cached MSI could be missing, see section 12 here for potential causes).
Earlier versions of MSI tended to trigger this problem (asking for the original installation media) more often (Office back in the day), and legacy MSI files can still cause uninstall problems that can only be solved using the msizap.exe tool (this tool is deprecated, outdated and no longer supported). This command line tool (msizap.exe) also had a GUI available (MSICUU2.exe), both tools are deprectated (try the link to the new cleanup tool listed above).
Just for the record: If you have access to the original MSI that was actually used to install the product, you can use this to run the uninstall. It must be the exact MSI that was used, and not just a similar one. There is a unique package guid assigned to each MSI file, so Windows will know if it is the right one.
Related answers:
wix - custom action dialogbox on silent uninstall of application
Uninstalling an MSI file from the command line without using msiexec
You didn't do something crazy like go to C:\Windows\Installer\ and delete the files in there did you?
One drawback of MSI files is you need the complete MSI file in order to uninstall or repair the application. Windows loves to store a copy of the MSI. It also renames the MSI file from a common name to a GUID with no table (that I can find) to map original names (example: Office2010.msi) to the new GUID so you have a PC with many GBs of wasted space that you can't delete. A machine that's not even 1 year old can easily hit 8 GB (example: mine).
There is an MSI cleanup utility from Microsoft, Windows Installer Cleanup Utility (deprecated tool, unsupported and unsafe to use - perhaps try this answer instead: Uninstall without an MSI file).
Or CCleaner can usually do this
Control Panel --> Add/Remove programs?
EDIT:
Your post mentions nothing about using add remove programs to uninstall the app, you said the "Windows Installer" (MSIEXEC - see the link below), which is not the same thing.
http://msdn.microsoft.com/en-us/library/aa367988(VS.85).aspx