Using Installshield 2010 and Basic MSI project.
I have an exe that was previously installed by my installer. That exe needs to be running during an installer upgrade. Is there a way to guarantee that the installer won't try shutdown the process? Basically, I would like the behavior to be : If file doesn't exist, lay it down, otherwise ignore it.
I have made the exe a key file in a component and set it 'Never Overwrite' to true. Should this give me my desired behavior ?
Never Overwrite will be used by future installers to determine if the file will be overwritten or not by other MSI packages. Basically, this attribute should have been set for the installed EXE.
A good approach is to use a file search to determine if the EXE exists. The search property can then be used to condition the new component.
Windows Installer doesn't automatically close applications, but it does show a FilesInUse dialog which offers this option to the user.
Related
I'm building a setup executable using Visual Studio 2015 Setup Project template.
I added an external executable in the file system of my package that the user needs to install to be able to run my program. Then, I added this package as a custom action on Commit.
I want my install package to recognize if this external executable is already installed on the user computer by looking at the registry of looking at a certain folder structure on the computer (the method to check is not defined yet).
How can I set up this kind of check for the custom actions ? I've seen that there is a Condition property when clicking on the .EXE in the Custom Actions window, but all I can find about this property is that, which does not really answers my problem.
VS setups offer a registry search, and that search will set a property name that you define (in uppercase). If the registry entry exists, meaning that you don't need to run the program, then you give the custom action a condition of NOT FOUNDREGISTRY assuming FOUNDREGISTRY is the name of the property.
Having said that, if that program is a redistributable that installs something then:
They are typically smart enough to figure out if they need to do anything or not, and that includes seeing if what's already installed is an older version, so they should run anyway because it's a newer version. So it may be best to just run it anyway.
If the executable wraps a MSI-based setup then it will fail because you can't install an MSI-based setup with a custom action in a VS MSI setup.
I have a written a setup script for my own Windows EXE using InstallShield Premium 2012. My EXE, however, ultimately relies on the presence components provided by a Microsoft EXE called AccessDatabaseEngine.exe.
In order to run this AccessDatabaseEngine.exe executable with my installation, I added it as an embedded binary resource then used the Custom Action Wizard to launch AccessDatabaseEngine.exe as "Deferred Execution in System Context" as an "After PublishFeatures" Install Exec Sequence. This worked as expected: The AccessDatabaseEngine.exe launches after my Setup completes most of its work.
However, once I see the UI for the AccessDatabaseEngine.exe and acknowledge its UI prompts, I see "Error 1500", which states that another installation is in progress.
I understand that two MSI packages cannot be running at the same time unless you tweak the registry to allow it, which I do not want to do on my customers' workstations, which are Windows 7 32-bit machines.
I would like to successfully implement one of these options:
OPTION ONE: Have the user launch my Setup.exe program, which will at some point launch the Microsoft AccessDatabaseEngine.exe without generating any error message. I just don't know how to do that without causing the Error 1500 to appear...
OPTION TWO: If it's possible to somehow wrap my Setup.exe along with Microsoft's AccessDatabaseEngine.exe into a single EXE, then I could provide my end users with that single EXE and it would first execute the embedded Setup.exe and, once that's done, it would execute AccessDatabaseEngine.exe.
I realize that I could implement OPTION TWO as a .bat (batch) file, but I want to deliver only a single EXE to my end users and have that single EXE install everything needed for my software to operate properly.
Any ideas?
What you describe here is exactly what InstallShield's prerequisites are designed for. Launch the prerequisite editor from the Tools menu and add files, command lines, and conditions that carry, install, and detect the installed footprint of the AccessDatabaseEngine.exe; then use the redistributables view to include that new prerequisite in your project.
Once you've done this correctly, InstallShield's setup launcher will check to see if the prerequisite footprint is present, and, if not, it will run the prerequisite as described. Since this is done before it launches the main .msi file, it avoids having two .msi files installing at the same time.
See Defining InstallShield Prerequisites, Creating an InstallShield Prerequisite, and Setting Installation Conditions for an InstallShield Prerequisite in the help for more details. For defining where these end up in your built installer, see Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level or Specifying a Run-Time Location for a Specific InstallShield Prerequisite. Note that when dependencies of a prerequisite are added, they often use the release-level setting, so unless you really want a mix of locations, you're best off specifying this in the release.
Apparently there are TWO settings that determine if a prerequisite ends up in its own, separate folder (a release folder below the folder that contains setup.exe), or if it gets embedded into a single setup.exe file.
The first setting is available in the Installation Designer under Application Data | Deliverables. Find your PRQ prerequisite listed there with a check mark, right click it, and view Properties. You will see a Build Location dropdown--one of the options is Extract From Setup.exe. That's the way mine was set.
But then there is SECOND setting, and that's in the Installation Designer's Media section, under Releases. In my project, I had a Releases root, then a PROJECT_ASSISTANT branch, then a SINGLE_EXE_IMAGE branch. I left-clicked SINGLE_EXE_IMAGE and viewed its property sheet. In that list is an entry near the bottom of the list that says Setup Prerequisite Location. Double-click the right column (where its value is listed) and you will see a selection there that also says Extract From Setup.exe.
This second setting OVERRIDES the one specified in the deliverables section, and that's why it wasn't working as specified in the prerequisite setting. That's because I was using the "Copy From Source Media" setting.
So if you have multiple prerequisites and you want all of them to be included in the setup.exe then it's okay to use the Extract From Setup.exe settings. But if you prefer to configure where the prerequisite ends up, then choose the Follow Individual Selections options in the Releases' Setup Prerequisites Location section and then ensure that you've selected the correct option for each of your prerequisites.
Even if others had suggested doing this in previous answers, those explanations weren't clear to me and I wasted a lot of time before ultimately discovering what's actually going on.
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.
In an InstallShield project I have a VBScript custom action that conditionally needs to execute a certain file packaged with the install.
Normally I get the current directory of a vbs using code such as
sCurPath = CreateObject("Scripting.FileSystemObject").GetAbsolutePathName(".")
Which, if it returned the location of the Setup.exe that initiated the install, should work.
However when running the install, the current path (on XP) is C:\Windows\system32 instead of the location of the Setup.exe file I was expecting.
Assuming the output of my InstallShield build looks like the following
Disk1
->Setup.exe
->ISSetupPrerequisites
-->Req1
-->Req2
-->...
->OtherReqs
-->ConditionallyRunMe.exe
How could I run "\OtherReqs\ConditionallyRunMe.exe" from a VBScript custom action?
Thanks!!
(Note: I realize there are ways to conditionally run exe files from withing InstallShield, but in this case the requirements are not supported by InstallShield - unless there is a way to use a VBScript custom action return value as a condition to run another file?)
After a lot of messing around, I got it (actually found it in the InstallShield manual, and not Google, go figure :))!
This line of VBScript does the trick
disk1Path = Session.Property("SETUPEXEDIR")
The line above points to where ever the setup exe file was, so from there it's trivial to run any exe included with your install media.
Other useful ones I found, which I'll past here for reference are
'points to app data\downloaded install directory
MsgBox Session.Property("SourceDir")
'where the software wants to install to on the users system
MsgBox Session.Property("INSTALLDIR")
Not sure why it's so hard to find a good reference on MSI Standard properties (even just a list). The closest I found was this, but not all of them work (and not specifically for InstallShield at all). If anyone finds a good link with documentation about MIS Standard properties and their description please add a link here, so no one has to waste as much time on this as I did :).
Is Visual Studio's Setup Wizard project able to only deploy some of the files only if it finds a certain key into the registry (a) ? If not, then maybe launch another installer file when that certain reg key is present (b) ?
(a) I have been trying to deploy a winamp plugin through VS's .msi files. 2 problems:
the path to {winamp}/plugins folder has to be obtained automatically
on failure, user should be presented with a dialog to choose where to install the plugin to
(b) In an attempt to overcome (a) the NSIS installer was used for only packaging the winamp .dll plugin; however, this introduced another issue:
if user does not have winamp installed, the NSIS generated sub-installer must be manually canceled, and this invariably causes the main VS generated installer to fail (while it shoud not, winamp is not an essential part of the good functionning of the whole app I am deploying)
I have failed in 2 ways to conditionally launch the sub-installer on a certain reg key detection (tried to look for the ProgID key of Winamp). First failure was because the ProgID key is not found even on machines that do have winamp installed (manually checked for the key, it was there), and second failure was due to the fat that such conditional launch could not be applied to just the sub-installer, but to the main installer only.
I am thinking of dumping the VS project wizard altogether and just move to NSIS installer wizard.. but I would not want to learn to script it for deploying each component of my solution. Any GUI version for it ? Or should I start learning Orca and use it on the VSPW's output .msi file ? Or what ?
Thanks
If you want to use a MSI the approach is this:
- create a search for the registry entry
- use the search result (it's stored in an installer property) to condition the components of your files
- use the same result to condition the installation folder dialog
This can easily be done in commercial setup tools. But if you want a free solution, Sandeep is right, Wix is very good.