Just wondering how an installer such as a setup.exe contains the files it's supposed to install, when it's an offline installer. I get that I can create a msi or a setup.exe easily in Visual Studio, but what if I, for example, would want to write an installer with a custom gui with raw c++ (if possible)? How does a singular executable contain all the necessary files (such as the dll's)?
As Ken said, Windows Installer is a complex service. If you are into learning about it here are some resources:
Intro for Windows Installer:
https://learn.microsoft.com/en-us/windows/win32/msi/windows-installer-portal
How files are bundled inside an MSI:
https://learn.microsoft.com/en-us/windows/win32/msi/using-cabinets-and-compressed-sources
If you just want to build a native MSI use existing tools, there are plenty of options free or paid.
Related
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 to re-package this 3rd party installer into something that I can use in my main application installer as a prerequisite (or as a chained msi package).
I want to not just extract/copy those files on the client machine, but run the installer.
Is it possible to create a MSI from all those files using Installshield? I can't seem to find a project type that would do it.
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?
Are you taking over the handling and update of an old setup and need to convert it to a proper format?
Are you trying to re-package a third party vendor setup.exe?
Are you trying to get hold of the files inside the CABs? Or just to extract the files so they can be re-packaged some other way. For some reason?
Are you trying to install the whole shebang as easily and reliably as possibly in silent mode?
Some other problem 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:
Extract MSI from EXE (a plethora of links on the subject)
There is also Michael Urman's "hand's-on": Programmatically extract contents of InstallShield setup.exe
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:
Administrative Installation: Try to do a 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.exe
Installscript setup: Try to do a setup.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.
Installshield Suite Setups: Try to do a setup.exe /stage_only from a command prompt. Lots of elaborate details here.
Advanced Installer: Try to do setup.exe /extract "C:\My work" or setup.exe /x
WiX: Try the following from a command prompt: 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).
Wise: Wise is no longer marketed, but many older setups remain. You can try to extract files with setup.exe /X [path].
Repackaging: One way to create an MSI package from older-style, legacy setup.exe installers, is to "capture" the changes done to the system by using an Application Repackaging Tool which monitors changes made to the system whilst a setup.exe is being run.
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:
How do I extract an InstallShield Cabinet file? (this I have never tried)
Uninstall and Install App on my Computer silently
How to make better use of MSI files
That sort of looks like a legacy Installshield setup.exe OR an
Installscript MSI setup.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 or setup.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.
Is it correct msi file is the Windows equivalence of deb file in Debian?
In Debian/Ubuntu, after I compile a program into an executable, I can create a deb file out of the executable using a program called checkinstall. Then I can install a deb file by dpkg.
In Windows,
what is the program/command that can create a msi file from an executable built from source code?
What is the program/command that can install a msi file?
Thanks.
The Windows Installer consists of an SDK, database specification and runtime service. Introduced in 1999, it originally had redistributables that were nesseccary to "bootstrap" onto the system before and MSI could be installed. Various versions of this runtime have been been baked into various versions of Windows for a very long time now so generally this is no longer a concern. You can simply install the MSI.
Technically the SDK does come with some tools that could be used to create an MSI. However this would be like using notepad and CSC to write a .NET app. Almost no one would actually do it this way. One notable tool does come from the SDK: ORCA.exe. ORCA is a database editor which is very useful for examining MSIs and making minor modifications to already built MSI. It technically can be used to create an MSI but very few outside of Microsoft back in the early days ever did.
For the most part Microsoft left installer authoring tools to third parties. Windows Installer XML (open source), Industrial Strength Windows Installer XML (open source), InstallShield, Visual Studio Deployment Projects, InstallAware and AdavancedInstaller are a few to list. It is outside of the scope of Stack Overflow but I will link a 2 minute video showing how to use Visual Studio, WiX and IsWiX to create a simple MSI with a shortcut for a single EXE:
https://www.youtube.com/watch?v=nnV_OU6fk8c
Disclosure: I'm the project maintainer for the IsWiX on GitHub.
As for how to install an MSI. An MSI is a database not a program. It is installed by the Windows Installer service msiexec.exe
There is an extensive command line documented at:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367988(v=vs.85).aspx
There is no standard tool for creating MSI installer files. There are many, many third-party tools, free and paid, that will help you to create MSIs; you'll have to do some searching and comparing and figure out what works best for you. The command to install an MSI is the MSI itself, you don't need to explicitly run it with any other program like you do with deb/rpm packages.
Is there any way to compile the Nullsoft Installer Script (NSI) setup as a MSI package instead of an EXE?
Unfortunately, No.
NSIS lets you create scriptable, procedural installation packages. It's simple, easy to use and has a number of features not present in Windows Installer.
Windows Installer (MSI) creates database driven, transactional installation packages. When written properly a Windows Installer package is very robust, a file gets corrupted/deleted and it will be automatically reinstalled. Windows Installer is aware of UAC and only elevates when required, basically if you're creating software for the corporate market, you will need to provide an MSI.
Check out The Definitive Guide to Windows Installer for a good introduction to understanding MSI.
NSIS installers can be wrapped in MSI files using the MSI Wrapper. It is a small tool that I made for wrapping NSIS and Inno Setup installers. It uses WiX to compile the MSI but there is a GUI to help you instead of an XML file.
It was made because I needed a tool for creating MSI files based on traditional EXE installers. I needed support for uninstall and upgrades and only wanted the wrapped installers to show up once in the Add/Remove programs in the control panel.
I also wanted to be able to pass command line parameters to the wrapped installer when the MSI is installed.
If you want to use it or help me improve it, you can find it at http://www.exemsi.com.
I share the opinion that wrapping an executable installer in an MSI package is not the ideal solution. However, when you already have the exe it can make a lot of sense :-)
No (And there are no plans to support .MSI output), try WIX
My problem is the following:
I have multiple applications that I want pack in one installer so when the user runs it, they will be installed automatically instead of installing or copying each single application.
I have a program that's already a setup file (.exe) and two .exe files which can be executed manually and do not need an installation. So what I want is:
Build an installer so when the user opens it - the .exe file of the setup program gets installed and the other applications which dont need to be installed will be copied somewhere in a path.
Whats the best solution?
I think you need a packaging programs to create an installation package, such as:
AdvancedInstaller
InstallShield
InstallAnyware
The first two of them have a freeware version. Maybe you can see if the required features are available in the freeware version.
I would suggest Advanced Installer (allows easy chaining of installs) if you have no significant deployment experience. Otherwise I would suggest Wix and its "Burn" feature (ability to chain installers in sequence). Please read the following answers for context:
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
Windows Installer and the creation of WiX
Wix to Install multiple Applications
Read this if you want to get going with Wix quickly
when I build solutions in Visual Studio, that generates installer files as .exe and .msi, .exe files are useful for what?
The .EXE file that is created by the installer project is a bootstrapper for the .MSI setup file. It is used to launch the .MSI setup file.
Generally, both will launch the setup program and allow the user to install the application. However, sometimes the setup.exe file will run a custom validation routine to determine if the user's computer meets the minimum requirements for installing the software.
For example, if the user does not have Windows Installer, they will not be able to launch the .MSI file, but the .EXE application will still run and inform them that they need to install Windows Installer first. For .NET applications specifically, the .EXE file verifies the presence of the appropriate version of the .NET Framework, and if it is not present, it prompts the user to download and install it.
You can customize the prerequisites that are required for your application in your installer project using Visual Studio. See these MSDN articles for details on how to do that:
http://msdn.microsoft.com/en-us/library/ms165429(v=VS.100).aspx
http://msdn.microsoft.com/en-us/library/7eh4aaa5(v=VS.100).aspx
Others have commented on the how (.exe bootstraps the .msi) but part of the reason why is that users know that .exe files are the things you run. I don't think your average user knows that .msi files are something that you can click on to install an application.
The .exe file is made for installing the prerequisites of your application.
Let's say your application uses the .Net 3.5 framework, you can tell the installer project to include the installation of the needed libraries if they're not already installed.
You may also deactivate it, so only the .msi is being created.
This page shows how to activate and configure the prerequisites setup, just uncheck the checkbox in order to deactivate it.
You also find more details on the process of Bootstrapping on MSDN:
the capability to automatically detect
the existence of components during
installation and install a
predetermined set of prerequisites
.exe files are useful for executing your programs that you've just built in Visual Studio, assuming you're not doing web applications.
Pretty much every Windows program out there is executed using files with an .exe suffix.
Installer exe files are normally just the msi wrapped in a bootstrapper. The bootstrapper can do anything, but normally its purpose is to ensure the user is running a sufficient version of Windows Installer, then extract the msi and invoke msiexec.exe to start installing the msi. Generating installers as exe's is deprecated these days, but some still do it.