I am trying to extract the file-contents of an InstallShield setup.exe-file. (My plan is to use it in a back-office tool, so this must be done programmatically without any user interactions.)
Is this possible?
(Initial research seems to indicate it will fail.)
If it is possible to have a generic solution, for all recent versions of InstallShield that would be best.
Otherwise, if a solution only works for some versions of InstallShield it would be a step on the way. (It would probably be possible to deduce which InstallShield version a setup.exe is by looking at version resources of the exe-file.
I found that some InstallShield versions support /b or /extract_all. However there is no good way of knowing, just launching the exe and hoping it will extract and terminate orderly rather then displaying GUI dialogs doesn't seem like a good solution. So I am therefore looking for a more stable way.
Ideas welcome.
There's no supported way to do this, but won't you have to examine the files related to each installer to figure out how to actually install them after extracting them? Assuming you can spend the time to figure out which command-line applies, here are some candidate parameters that normally allow you to extract an installation.
MSI Based (may not result in a usable image for an InstallScript MSI installation):
setup.exe /a /s /v"/qn TARGETDIR=\"choose-a-location\""
or, to also extract prerequisites (for versions where it works),
setup.exe /a"choose-another-location" /s /v"/qn TARGETDIR=\"choose-a-location\""
InstallScript based:
setup.exe /s /extract_all
Suite based (may not be obvious how to install the resulting files):
setup.exe /silent /stage_only ISRootStagePath="choose-a-location"
http://www.compdigitec.com/labs/files/isxunpack.exe
Usage: isxunpack.exe yourinstallshield.exe
It will extract in the same folder.
On Linux there is unshield, which worked well for me (even if the GUI includes custom deterrents like license key prompts). It is included in the repositories of all major distributions (arch, suse, debian- and fedora-based) and its source is available at https://github.com/twogood/unshield
Start with:
setup.exe /?
And you should see a dialog popup with some options displayed.
The free and open-source program called cabextract will list and extract the contents of not just .cab-files, but Macrovision's archives too:
% cabextract /tmp/QLWREL.EXE
Extracting cabinet: /tmp/QLWREL.EXE
extracting ikernel.dll
extracting IsProBENT.tlb
....
extracting IScript.dll
extracting iKernel.rgs
All done, no errors.
Related
I am not familiar with Windows installer builder tools, other than having a conceptual understanding of them. I have a hopefully simple installer-file-wrapping-problem to solve where i would need some advice from people who know this field better than myself:
I have a vendor provided vanilla Setup.exe installer along with a custom config.dat file.
I can run the installer with "Setup.exe /S" which picks up the config.dat file in the same directory for a silent install just as I need it.
I now want to wrap both files into a single file self executable installer "CustomSetup.exe" that if launched with "Run as Administrator" silently unpacks the two files into the same directory, runs the silent install command line "Setup.exe /S" and deletes the previously unpacked files and directory afterwards. Effectively giving me a single-file one-click silent installer with custom settings from the vendor provided vanilla installer.
What is the simplest, most straight forward and elegant way of getting this done?
Most InstallShield/WIX/Windows Installer Tools tutorial- and documentation-pages i could find want to take me to an elaborate installer-project-building-academy first, something that is certainly useful for developers needing to learn how to build complex installer projects, but feels like overkill for just getting this seemingly simple thing done. Is there a lean way to do this? Many thanks in advance for your help.
For the record, I have found the answer to my own question.
Running the Windows on-board IExpress (as Administrator) easily produced exactly what I was after. Just type "Iexpress" into the command search box, run as Administraor and fidlle with it. Alternatively, this is someones Video explaining it https://www.youtube.com/watch?v=vXZyq0cMuKI
I want get dir my setup create by install shield.
I use command parametter Setup.exe /path=[SETUPEXEDIR]\log.txt
My setup location is Desktop\myapp\Setup.exe
When use [SETUPEXEDIR] return temp folder
I want when use [SETUPEXEDIR] return me my Setup.exe location.
I use installshield 2016 version 23 SP 2.
I use MSI Script.
I want get location and use in command parameter prerequisites.
A little hard to comprehend exactly what you are asking, but as far as I understand you want to know the location where setup.exe is running from?
Variables
The first question is: what version of Installshield are you using?
The second question is: are you using Basic MSI or Installscript MSI?
The third question is: what type of release media are you using?
There may be more relevant questions...
A word to the wise: if you are indeed using Installscript MSI you should know that it is a very buggy type of project, and you should seriously consider switching to Basic MSI to save yourself grief. I can provide more information on this if you like. I had to abandon Installscript MSI entirely to make my deployment problems go away.
Installshield Properties
It seems different versions of Installshield may behave differently and feature varying support for these folder properties / variables. It also seems the properties may not work with all types of release media. And finally they may only work in Basic MSI or Installscript MSI respectively. The properties I have found are: PACKAGE_LOCATION, SETUPEXEDIR and SRCDIR. There also appears to be an Installscript method called GetCurrentDir() available in recent versions of Installshield, but the documentation warns about using it (see link).
Please visit the links above in sequence and read in detail about each property's (or method's) limitations. It is very important that you use the option (if any) that matches your requirements and scenario. For example PACKAGE_LOCATION works only for Installscript MSIs, SETUPEXEDIR is set by Setup.exe. If the end user runs the .msi package directly, SETUPEXEDIR is not set.
MSI Built-in Property
It seems to me that getting the built-in MSI property SourceDir might be an option to try. My quick test indicates that it works for both InstallScript and Basic MSI. However, I do not know if this works for all versions of Windows Installer. Please test on various Windows versions to be sure.
You should also be aware of the potential problem using SourceDir which is described in the documentation for SETUPEXEDIR. This goes for setups that are compiled into a single, compressed setup.exe containing all files - this launcher will extract the MSI file to a temp location and run from there. When I tried with an uncompressed network image it worked fine to use SourceDir.
Finally, if you use a setup.exe to compress all files and enable the caching of the MSI on the system, then you will be running from somewhere inside: C:\WINDOWS\Downloaded Installations\{GUID}\.
All of this could be different on newer versions of Installshield. I am testing with an ancient version I have available. Please test thoroughly on your version.
I should also mention the OriginalDatabase built-in MSI property. Check the link for documentation on how it will be set.
Some links:
Installscript project - Get Setup.exe location.
How to find the setup.exe directory?
Installscript Function For Testing
And just for reference, here is a quick and dirty function to test these properties from an Installshield custom action (this is for other people who may find this without having tested as much as you):
function TestFolderProperties(hMSI)
STRING svName;
NUMBER nvSize;
begin
// MSI properties
nvSize = 256;
MsiGetProperty (hMSI, "SETUPEXEDIR", svName, nvSize);
MessageBox ("SETUPEXEDIR: " + svName, INFORMATION);
MsiGetProperty (hMSI, "SourceDir", svName, nvSize);
MessageBox ("SourceDir: " + svName, INFORMATION);
MsiGetProperty (hMSI, "OriginalDatabase", svName, nvSize);
MessageBox ("OriginalDatabase: " + svName, INFORMATION);
// System Variables
MessageBox ("SRCDIR: " + SRCDIR, INFORMATION);
// PACKAGE_LOCATION is not available in my version of Installshield, enable and test
//MessageBox ("PACKAGE_LOCATION: " + PACKAGE_LOCATION, INFORMATION);
end;
Remember to add the export to the top of the setup.rul file:
export prototype TestFolderProperties(HWND);
Test compile to verify, and then create an Installscript custom action and put it in a sequence. Make "Return Processing" Synchronous (Ignores exit code) for the custom action. I put it right before InstallFinalize in the sequence, using immediate mode execution. Rebuild your release and run it. Try different release build configurations (msi with external source files, MSI only with compressed files inside, setup.exe launcher with external files, setup.exe with all files compressed inside, setup.exe with caching, setup.exe without caching, etc... the behavior might be different).
Looking for an installer that will take any number of files in a folder and make each file into an exe (not put them all into one exe). Will any installers easily do this? I haven't been able to find a feature name for this, so it's made it difficult to determine from a feature list.
Take a look at Nullsoft installer. About anything can be scripted w/ it.
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.
I've been looking at various different ways of making an installer (see How to create a robust, minimal installer for Windows? for details), and I've run into the same thing in a couple of them (WiX and the visual studio installer creator); there doesn't seem to be a way to say "When you build the installer, include every file matching c:\somefolder\*.xml".
I can go and select *.xml and add all the files that match to the project at once, but then if I add another .xml file to my program later, I'd need to go and add that to the installer myself.
Is this a core limitation of windows installer, that I can't just tell it "sort all the XML files in this folder out and don't bother me about them"?
WiX toolset contains an utility called Heat. It can generate the WiX authoring for you based on your needs. The output can be further transformed by XSL templates (-t switch).
Hope this helps.
InstallShield also has this ( see Dynamic File Linking ) but honestly I don't like this pattern in general. It's non-deterministic in nature. I speak from 14 years of experience when I say that if a file is added or removed from my application I want to explicitly add it or remove it from my applications installer. Any magic to automate this has always bitten me in that it takes what should have been a build time error and turns it into a run time error.
My best practice is to write some automation that compares what was available to be consume against what was consumed by the installer. The two lists must match 100% or otherwise fail the build. When the build fails you must choose to either add the file to the installer or cease to archive the file to the directory. With the right tooling, it's trivial to add a file to the installer and the result is 100% accuracy of developer intent being applied to the installer.