Just out of curiosity, I would like to understand the behaviors of those self contained installer programs and try to write a simple installer myself.
I did some search on Google and did not really find a useful article explaining it. However AFAIK, an installer should have a small chunk of code residing in the top of the executable. It pulls data out from the rear of the executable and interprets them as files according to an inventory file (probably xml?). Other operations such as writing register entries can also be specified in the inventory file.
Now is my guess of the file structure true? If so I think I just need to read about the PE format and then it would be conceptually easy for me to implement it. If my guess is wrong, I would love to know how exactly it works.
Thanks for your time!
Normally installer packages are self-contained compressed executables (SFX) that contains:
A small installer executable
A compressed file structure with files to extract
Some configuration files (xml, ini, json, properties) to define file destinations, registry entries, desktop/start menu shortcuts, instalation modes
Extra files (dll, icon/image resources) to make the installer work.
For MSI packages, it's a bit more complex. It's a propietary format packaged as a SQL database in a COM structured storage file. It contains also a virtual file system inside the installation package (file access using file streams).
You can review some free tools and check many typical features to make installer executables like:
Wix (For MSI installers) http://wixtoolset.org/
Nullsoft Installer (NSIS) http://nsis.sourceforge.net/Main_Page
Inno Setup http://www.jrsoftware.org/isinfo.php
For Windows it's pretty much
Declarative: MSI, AppX, ClickOnce
Imperative: any number of third party tools, scripts and home grown EXEs
MSI is typically your best choice. The runtime is already part of windows so when you double click the MSI database MSIEXEC takes over. The point of the declarative models is to separate what needs to be done from how you do it. The imperative models are basically some simple to complex framework to write procedural code to do the actual installation work.
It's far to broad of a question to ask in detail how any of these work at a low level. For MSI it's all in the Windows Platform SDK documentation on MSDN.
Related
This question might seem to be duplicated with this and this that are similar. But it is not! First- I am getting this error from the setup file and not from the program that I am distributing Second -the version is different, the directories in Installshield 2009 an 10.5 differ. .
I'm trying to fix an error caused by Windows compatibility mode in my setup, which is built with Installshield 10.5. So far my research led me to a conclusion that i need to add [this][3] to my manifest file. I saw that Microsoft's tool mt.exe could extract a manifest file from a dll, however I did not see anywhere that it can extract it from an executable file.
So my questions are the following:
Is there any way to view the manifest file of a Setup.exe built with Installshield?
Is there any way to configure this manifest file for the certain project in Installshield?
[3]Can one edit an InstallShield setup.exe's manifest file?
As far as I know, mt.exe will work fine on EXE files; both EXE and DLL files are Portable Executable (PE) files, and PE files use the exact same structure for resources such as the manifest. Visual Studio, CFF explorer, and countless other tools (including raw resource APIs) will also work to view and possibly update manifests in general.
However for a built InstallShield setup.exe, there is a twist. InstallShield uses areas in the file to store information that are not described in the PE format. Tools that update the resources on an EXE can inadvertently destroy this data as they do not expect it to be there, nor do they know how to detect or adjust it.
InstallShield 12 or so and later allow you to specify a manifest, and it selects the manifest from files it ships that you can update before it adds them to the setup.exe. In addition, there is a tool called ISReMan that is aware of the extra information and can update the manifest correctly when that data is present.
By the way, it's generally helpful to mention the actual problem you're trying to solve, in case the method you've chosen (in this case updating the manifest) is not the correct solution. Note as well that InstallShield 10.5 is over 10 years old, and knows nothing about UAC, PCA, and other Vista and later technologies; adjusting the manifest may not help fix, say, an elevation-related problem.
Note as well that I am paid to work on InstallShield, so I may be biased when I recommend things like upgrading. :)
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 would like to create an installer of my program.
However because the installation is quite complicated, I need something more advanced than installshield limited edition.
I have to run another installer from my current one. It doesn't matter if the user press "cancel" or installs the program, I just need to run it.
I have to install a directory structure on user computer which has a lot of files, that's why i'm going mad with wix: 100 files and I should write all of them with my hands in that xml file? Are we mad?
I have to install files from point 2 into a registry key. That's why I was using wix
I played with nsis long time ago and I liked it, but the language is not so nice.
Wix has "similar" problem. I would love using something like C# and things like that otherwise I'll stick with wix but I need a way to add files faster to xml file, can't add 100 files manually.
Any suggestion?
You can give Advanced Installer a try. It has folder synchronization, which means it can batch add contents of folders, with the possibility to filter out certain file name patterns, for example you'd want to filter *.pdb files and add all the rest to the project automatically.
I use it myself and never had a problem.
Wix Heat can generate the wxs source files for you.
You should look at InnoSetup. It has an IDE available that allows drag and drop of files (and multiple select in a file selection dialog), can launch other applications (including additional setup files), create and modify registry settings, and supports pretty complex scripting if needed. It's pretty easy to use, and the documentation is pretty good. It comes with pretty comprehensive sample installations, too.
The installation scripts are created by the IDE and then compiled into an installer, so the script source is editable by hand if needed. It's also not XML, but more like an INI file, so it's a little easier to work with manually as well.
Best of all it's free, and so is the IDE.
I would go back to using NSIS, if you use the HMNSIS editor http://hmne.sourceforge.net/ to write your scripts you can use the Wizard mode to make a list of the files and directory structure you will use in your installer.
Running other installers and registry settings are also easily done with NSIS.
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.