I notice that every time I rebuild my InstallShield project the file PROJECT_ASSISTANT\Interm\ISSetup.dll is updated. As described in the documentation, it executes InstallScript custom actions.
I always deliver a single exe PROJECT_ASSISTANT\SINGLE_EXE_IMAGE\DiskImages\DISK1\Setup.exe to my customers, and the installation runs smoothly without this ISSetup.dll.
So is this ISSetup.dll packed into the single setup.exe somehow? If not, how the Installscripts are executed on client machine?
I would like to tell you the project type (be a Basic MSI, InstallScript, or InstallScript MSI), but since I build my project from command-line (InstallShield 2012 SpringSP1 SAB) and am not able to open the project in GUI mode to view the properties pane, I don't know how to get this information from an .ism (XML format) file.
I forget the exact mechanics of where the file is included in each project type that may use it (sometimes it's directly in setup.exe, sometimes it's indirect). Regardless, ISSetup.dll is always the compiled InstallScript engine (the C++ part), and often has the compiled setup.inx (InstallScript part) "streamed" onto it. Something (perhaps setup.exe, perhaps a Windows Installer custom action) calls into it to run InstallScript code that we provided, or that you wrote.
So the short answer to the original question is: yes.
To answer the unasked questions, the Interm folder is an intermediate folder used for staging some of the files that get built into setup.exe or into the .msi file, and ISSetup.dll definitely receives updated compiled script code for each build of a Basic MSI or InstallScript MSI that includes custom actions.
I believe the ISSetup.dll is compiled into the MSI's binary table and extracted as part of the launching of the msi via msiexec.exe - at least for Basic MSI files.
The setup.exe wrapper probably contains the whole ISSetup.dll - perhaps statically linked or embedded somehow. Michael Uhrman (Installshield developer) will probably comment if he sees this question.
UPDATE:
I found a version of this ISSetup.dll file, see a screen shot from Dependency Walker below. In addition to the exported functions seen, there are also COM register and unregister methods exported (DllRegisterServer, DllUnregisterServer, DllCanUnloadNow, DllGetClassObject). The f-functions must be the various Installscript functions. The first 5 functions must be related to Installscript MSI.
Related
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).
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.
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 couple of dlls we like to install using an msi.
In our test environment, we are using regasm -codebase to register the dlls.
As I understand from googling, this is accompliched in an msi project by setting the register property to vsdraCOM.
The problem is that when we run the installer and checks the registry, the codebase path is set to the path the file were in when building the msi.
I'm going to expand on Hans' answer and that link info, and it may be more than a comment can hold.
That reg file will contain the path to the file and the link article recommends using [TARGETDIR], which is basically wrong if the file is not being installed to the application folder. The path to your file should be written as [#file-key] in the reg file that you import. In a VS setup project the file-key will be (just an example) something like _B049230C37DE4B6787C578DCEE30252A. Open your MSI file with Orca, go to the File Table and use the file key in the File column that corresponds to your file name.
That comes from here:
http://msdn.microsoft.com/en-us/library/aa368609%28v=vs.85%29.aspx
the 7th bullet point. It resolves to the file path wherever it is installed to.
The other thing that can be done is to let Visual Studio do its incorrect thing, then go to the Registry table with Orca, find the path and put that [#file key] in it such as [#_B049230C37DE4B6787C578DCEE30252A] and people sometimes do those kinds of updates with a post build script to update the MSI.
None of these are great, but they should work and get you out of using the GAC. VS setup projects really should be using that [#file key] syntax, and it's just a silly bug I assume.
Speaking as someone who's made a full time living writing installs for 18 years, my first suggestion would be to switch to Windows Installer XML. If you insist on using .VDPROJ, I would suggest reading: Redemption of Visual Studio Deployment Projects.
The concept is you use Windows Installer XML to create a merge module and then consume that merge module with .VDPROJ. In Wix, you use Heat to harvest the DLL. It will extract the COM / Regasm metadata and author it as Registry table entries. This provides a nice clean encapsulation using authoring best practices and avoids the need to do any post build hacking of the built MSI database.
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.