I have a folder with a 3rd party installer, the folder contains a setup.exe and all its CAB files next to it (and many related folders).
I want to be able t
I'm an InstallShield noob looking for help with a similar problem, but for your needs a Basic MSI Project should be sufficient.
If you are using the Project Assistant wizard, when you the get to the Application Files section you drag-and-drop your various folders and the setup.exe into the INSTALLDIR folder in the wizard and that's pretty much it, I think.
As I recall from other issues I had creating a non-installing MSI of SQL Server, Install Shield will automatically recognize your setup.exe and run that when the .MSI is run.
Problem Scenario: What is your scenario?
Silent Running?: If what you need is to just install silently, then there are command line switches for most setup.exe
wrappers that will let you do this, but it is different for every tool used to create the setup.exe
file. Installshield's setup.exe files require a silent response file, other tools do it differently. I wrote about Installshield silent uninstall a couple of days ago. And here is a piece on regular silent install and various types of Installshield setup.exe files.
Record response file:
Setup.exe /r /f1”c:\temp\my-answer-file.iss”
Basic silent install:
Setup.exe /s /f1”c:\temp\my-answer-file.iss”
If the setup.exe
is a wrapper for an MSI and you have a distribution system to rely on to distribute the pre-requisite components, then it is generally better to extract the MSI if you are in a corporate environment and use the standard features in MSI to run silently (the /QN
switch for msiexec.exe
):
msiexec.exe /I "C:\Your.msi" /QN /L*V "C:\msilog.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Quick Parameter Explanation:
/I = run install sequence
/QN = run completely silently
/L*V "C:\msilog.log" = verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst (see below).
File Extraction?: Getting the files out of a setup.exe
can be challenging, or very easy. It depends what it was built with, and that can be pretty much "anything" - from established deployment tools to proprietary software made by "anyone". To extract files from various types of setup.exe
you can find extensive information in this answer:
Essentially you use setup.exe /stage_only
for Installshield Suite executables. And setup.exe /a
for Basic MSI and Installscript MSI executables. And setup.exe /s /extract_all
for legacy Installscript executables. Clarifications below.
MSI Import: If you manage to extract the files and you see an MSI file there, then you should be able to import or open that MSI file in Installshield (or other deployment tools as well).
I'll try a quick "short-list" of extraction options (not sure if that is what you really need):
Already an MSI?: Do you know what that setup.exe
contains? Technically it could already be a wrapper containing an MSI file, or it could be the output of some legacy deployment tool and not be a Windows Installer at all. Let's just list a few options:
setup.exe /a
from a command prompt to see if you get an "extract files" dialog. If so, specify an output location and extract all files. This indicates an MSI setup wrapped in a setup.exesetup.exe /s /extract_all
from a command prompt to see if you can extract files from the CABs. This is for Installscript setups. Or try /extract_all:[path]
as well.setup.exe /stage_only
from a command prompt. Lots of elaborate details here.setup.exe /extract "C:\My work"
or setup.exe /x
dark.exe -x outputfolder setup.exe
. A WiX setup.exe file can only be extracted using the dark.exe tool from the framework itself. In other words you need to install WiX to extract a WiX setup.exe (as of now).setup.exe /X [path]
.It is impossible to cover all the different kinds of possible setup.exe files. They might feature all kinds of different command line switches. There are so many possible tools that can be used. (non-MSI,MSI, admin-tools, multi-platform, etc...).
Commmon tools such as Inno Setup
seems to make extraction hard (unofficial unpacker, not tried by me, run by virustotal). Whereas NSIS
seems to use regular archives that standard archive software can open.
General Tricks: One trick is to launch the setup.exe and look in the 1) system's temp folder for extracted files. Another trick is to use 2) 7-Zip, WinRAR, WinZip or similar archive tools to see if they can read the format. Some claim success by 3) opening the setup.exe in Visual Studio. Not a technique I use.
Some Links:
That sort of looks like a legacy Installshield
setup.exe
OR an Installscript MSIsetup.exe
. Despite similar appearances these are very different beasts.I would try the following to determine what you are dealing with:
setup.exe /a
If you get a dialog asking you for an output folder you probably have an Installscript MSI. Extract the files and then look for an MSI in the output folder.
If that does not work try
setup.exe /s /extract_all
orsetup.exe /extract_all:[path]
. Or try this answer.
Installshield Suite Project: Seeing as you want to distribute this setup as part of your own application deployment I would probably use an Installshield Suite Project - if you have a license for an Installshield version that supports this project type. See screen shot here.
The Silent_Install.bat
file (and the associated Silent_Uninstall.bat
for uninstall) should contain the command lines you need to use when inserting the package into the suite project. Then you also include your own application as part of the suite installation. Makes sure to test well in all deployment scenarios: install, upgrade, modify, uninstall, patch, etc... There are always surprises.
Repackaging: Alternatively you could re-package the setup with a capture tool instead of running it "as is" - in the existing format. Then you essentially "record" changes made by the setup by monitoring its installation. This works in most cases, but requires significant knowledge to clean up properly. There are also challenges for multi-lingual setups - which this appears to be
. This approach has been extensively used in corporations to convert legacy installers to MSI format - and it is still in use. The end result is an MSI that can be installed in silent mode in the standard Windows Installer fashion (which is reliable - much more so than a legacy setup.exe run in silent mode). I would still wrap the captured MSI in a suite project, although you in principle could add it to your own product's MSI. I would not recommend this - for several reasons. Most significantly that you could need to update the runtime setup on its own - without rebuilding your own MSI.