We use InstallShield 2010 to install our software using the InstallScript approach. There are some prerequisites that may be installed as necessary. In the OnBegin callback, we execute some logic to validate the system before continuing with the installation. If the user cancels the installer at this point, the installation will exit, but the prerequisites are not uninstalled. I have a few questions.
1) Is it possible to perform our custom validation before the prerequisites are ever installed? This doesn't appear possible within InstallShield 2010 based on everything I've read, but I'd like to have that confirmed.
2) Is there a way to force the prerequisites to be uninstalled if the user cancels the installation?
3) Are there alternatives that would allow the prerequisites to be installed after the OnBegin callback? I read something about prerequisites being tied to a particular feature, but it is unclear how to do this in the UI.
1) The answer to your first question is also probably the easiest most plausible solution. You should be able to get your custom validation to run before the other prerequisites by creating your own prq file with all the custom validation logic wrapped up into it. To create your own .prq file you can just copy an existing prq in the SetupPrerequisites folder and rename it. Then open the Redistributable view in InstallShield. The copied/renamed .prq file should now show up in the list, and you can right click and select Edit Prerequisite. Then change the Properties,Conditions,Files To Include,Application To Run, etc.
For example, suppose your validation is an executable that runs and sets a registry key depending on success. You could check if the registry key exists as a condition of whether to run the prerequisite, include the exe and any dependencies in the Files to Include tab, run that executable in the Application to Run tab, and in the Behavior tab set the drop down of what happens if the launch conditions are still not met to Abort the setup
After you're satisfied with all your prerequisite settings, right click again and select Set prerequisite order... and make sure that your custom validation prerequisite is at the top of the list.
2) Yes, there is probably a way to run some custom actions that will ensure all your prerequisites get uninstalled on a rollback, but that seems complicated and I personally wouldn't recommend it. What if the user already had the prerequisite installed on their machine and then they aborted your install and it uninstalled software they already had on their machine? They may not be too happy about that.
3) Not totally sure about this, but I don't think it's possible to have the OnBegin function execute before the prerequisites run. I say that because normally the prerequisites are launched outside of the MSI execution by a Setup.exe or something similar, at least from my understanding. Then the MSI is launched after the prerequisites complete. If the OnBegin runs as part of the MSI execution (which I believe it does) then it can't be launched before the prerequisites are launched.
Suite and Suite/Advanced UI projects available in newer versions of InstallShield handle this more directly, but how about putting OnBegin before OnBegin by wrapping one InstallScript installation in another?
Regarding your other sub-questions...
Prerequisites are handled in a fire and forget manner, and are designed to install things that may have already been present (and skip the installation in that case), so there's no direct support for uninstalling them.
Feature prerequisites are available in Basic MSI projects. For InstallScript projects, you are encouraged to use script code including LaunchApplication or similar approaches, however this can end up requiring reimplementing a prerequisite-style architecture if you don't just launch another InstallScript installation.
Related
I have a setup for a VC++ application built with dotnetinstaller. Being a native application, the VC++ redistributables are a prerequisite. However, nowadays these change very often (every 6-8 weeks). This means we release a new version of the application, but newer version of the redistributables are also released and installed on a customer machine before the customer actually installs our application. The result is the old redistributables from our setup will fail to install, since a newer version exists. This, in turn, results in the failure of the setup, therefore the application MSI will not be executed.
Currently, the workaround is to open a command prompt elevated as administrator and run the msiexec with the right parameters. I want to find a better experience for the customers.
The VC++ redistributables are added as required prerequisites. That means the required_install property is set to true. The result of this is that failure to install the prerequisite means installation failure. Although allow_continue_on_error and default_continue_on_error are set to true, the user is informed about the failure and can continue with other prerequisites, but the setup fails in the end and the MSI execution does not start.
I have tried making the VC++ redistributable optional prerequisites by setting the required_install property to false. However, this leads to another undesired behavior. If any required prerequisite is missing, then the dialog of prerequisites is displayed and I can check/uncheck the optional ones (and therefore skip them if I don't want them). However, if all required prerequisites are found and only the optional ones are missing, the setup does not display the prerequisites dialog and go straight to execute the MSI.
I need an option to make these pre-requisites optional in the sense that failure to install them will not stop the execution of the MSI; however, I do want the users to see they are missing, if the case, and have the option to install them.
Is this possible in some way with dotnetintaller?
It seems there is a key where the version of the VC++ redistributables are installed, which is HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\VisualStudio\14.0\VC\Runtimes\{x86|x64|ARM}. This is documented here: https://learn.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=msvc-160
However, the version is stored in a string with the form v14.28.29913.00 as seen here:
There are also DWORD values for Minor, Major, Build, and Revision.
One solution using dotnetinstaller is to combine installedcheck operations, using installedcheckoperator. An example can be found here.
The latest version of dotnetinstaller, 3.1.415, supports parsing strings in the form v[version] such as v14.28.29913.00, making it, therefore, simpler to check for the VC++ redistributables version.
I have created my application's setup in installshield - basic MSI project...
Now when i am installing it, it allows me to run .exe multiple times simultanious...
Please let me know, how can i stop it.....
There is already a safe guard automatically built-into Windows Installer. If two or more of your installs actually try to install only the first one will install. The others will throw a message saying another install is already in progress. This is enforced by the _msiexecute mutex.
If you want to gate the situation earlier, you'll have to write your own custom actions to create your own custom mutex, tear it down when the install is complete and check for it when starting the install. However, I'd mark this problem as Functions as Designed and move on.
I have asked this exact question on the Flexara forum, but got no response up to today, so I want to ask it here.
We currently have a InstallScript project which runs fine. The resulting setup can be made unattended/silent fine.
In this setup we have some features and invoke a number of third-party installations (that are a prerequisite for running our software).
However, we have customers that want an MSI file and therefore we resorted to the Basic MSI project type.
The setup is made without too much hassle (I'm fairly new to InstallShield) and I can generate a .exe and .msi from this project.
However the only issue I have left is invoking one of the third-party installers.
That third-party installer (made with NSIS) on its turn invokes another installer which is MSI based.
This results in having error 1500 - the fact that you cannot run a msi type installation while another is running.
I've tried scheduling the CA (that are used to invoke the third-party installers) as the first action and as last, but no success.
Before resorting on the more unorthodox scenarios (like creating a task on Windows Task manager that runs after our installer finishes, or at the next reboot and forcing a reboot - which our customers don't like) or a scenario that we don't bundle the 'faulting' installer (we really like to be able to hand over a single intaller and not multiple), I'd thought I ask your input.
I've tried searching for solutions everywhere on the internet, but either I'm failing due to wrong keywords or I just didn't stumble on the right post yet.
Are there any options left for us to create a single MSI installer that is able to invoke this third-party installer (which invokes a msi installer on its turn)?
Since an EXE bootstrapper is not acceptable, there is only one solution:
store the prerequisite installers in Binary table of your MSI
create some custom actions which extract them from this table and launch them
schedule them in InstallUISequence, for example right before Progress dialog
use searches to detect if the prerequisites are installed or not
condition your custom actions with the search results
Basically, you need to launch them during the installation UI. It won't work if you launch them during InstallExecuteSequence.
I don't think the basic MSI project supports this, but it may be supported by more advanced project types. Other setup authoring tools offer direct support for this.
You can try InstallShield's "Chained .msi Package" feature.
Our product has several products that customer can install created as separate installation packages (MSI).
We have a requirement to have single package for the installation that will:
Show one UI with progress
Allow user to choose which features/packages to install
Have ability to constrain one feature to another (e.g removing or adding effect other)
Support single elevation (UAC)
nice to have ability to auto update (not must)
support command line + silent installation
the package should be built out of the isolated installations (chain them)
raise error / messages for missing prerequisites
Support patches over time and major upgrades
Today we do almost all of the above using MSI with nested installations which is bad practice and we face too many issues in our solution.
i know that there are several bootstrappers out there (m$ generic bootstrapper which i think is not good, BURN is the WIX version which is not mature enough)
Do you know of other? that work and tested already ?
What is the best method to do (without unification of the MSI into a single MSI)
dotNetInstaller looks promising. I was experimenting with it to install java as a prerequisite. It comes with a GUI editor so you don't have to sort out the xml to create a project. The config file is in xml, and the InstallerLinker can be run from the command line. It could be integrated with a build server, though some msbuild tasks would be nice.
project home:
http://dotnetinstaller.codeplex.com/
tutorial:
http://www.codeproject.com/KB/install/dotNetInstaller.aspx
Create an InstallShield InstallScript package. Use the InstallScript package kick off the .MSIs with "-qn" one by one. I do this and am successful with it. I believe it meets your all the requirements you listed.
Until Wix's Burn is ready we really don't have much of a choice when it comes to bootstrappers.
If you are using InstallShield as your msi designer, one thing you could try is making an InstallScript project that contains all the different msi packages. You could then silently install only the desired packages. InstallShield is pretty expensive though, so if you don't already have it, you'll probably have to end up rolling your own bootstrapper.
I am having a small problem regarding pre-requisites and launch condition for setup.
For example, my setup is having one launch condition requiring "Software1" and one prerequisite installing "Software2".
So, if a system does not have both requirements "Software1" and "Software2" on installing the setup:
Is it shows the prerequiste dialog for "Software2"
Is it shows the launch codnition for "Software1".
I am observing the behaviour that I am getting a prerequiste dialog box using my setup.
Is there any way to set the order or to show the launch condition as first dialog while installing the setup?
If you are using InstallShield prerequisites in your installation, they will be installed by the setup.exe, not the MSI. Launch conditions are handled by the MSI, which will not be run until after the prerequisites are installed. Basically, this means that you can't show launch conditions until after prerequisites have been installed.
That being said, you may be able to configure the conditions on the prerequisites in such a way that the prerequisites would not be installed if you know in advance if a launch condition cannot be satisfied. The net effect of this is that the launch conditions are shown without installing prerequisites, but this isn't a really simple way to achieve this.
In InstallShield 2009, you can configure "feature prerequisites" that will not be installed until after features have been selected. In this case, prerequisites associated with selected features will be installed at the end of the Install UI sequence, or, if the installation is being run without a UI, just before the Install Execute sequence.
without more detail on what sort of installer system you're using, it is going to be hard to help. Assuming you're using the built-in stuff in visual studio, look on google for visual studio msi custom actions. I believe one of the allowable actions is to start another executable.
Assuming you're using MSI launch conditions, you cannot tell which order launch conditions will be evaluated.
If you do need to check something in a specific order, you'll need to use a Custom Action rather than a launch condition.