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.
Related
I have setup created with InstallShield 2015 Basic MSI.
Let’s say in this setup user can choose if he want to install Client or Server,
for each setup type ( Client or Server ) there are several features he can choose to install.
Now user choose to install Client setup and included 2 features under it,
If he run the setup again with UI he will enter the maintenance mode enable him to add more feature belong to Client.
My problem is that he can also run same setup again from command line (msiexec /I) and try to install the Server setup type, currently setup doesn’t block or prevent it and this may cause corruption of Client setup he already have installed.
So, I guess I should write a CA that will check if current setup is installed and check what action user is trying to run from command line and if it’s not uninstall block it ( still need to support running uninstall from command line ).
Is this logic correct? How can I know what is the command user run from command line? meaning that he run msiexec /I and not trying to uninstall from command line.
I wonder if there an InstallShield\MSI build in way \ property to prevent installing same MSI twice from command line ?
I'm having a hard time understanding you. I hope my answer is aligned with your needs.
When you first run the MSI it's in installation mode. When you run it again it's a maintenance mode. Depending on how you authored your installer, you should get a dialog with Repair, Change or Remove buttons. The Change button can be used to allow the user to add additional features or remove features. This can all be done from the command line as well using the ADDLOCAL and REMOVE properties. There properties take a , delimited list of feature names.
One place people make a mistake is using the conditions Not Installed | REMOVE="ALL" on their custom actions. This doesn't take into consideration the fact that you might have multiple features and come back during maintenance mode and reconfigure the application. MSI has feature and component installation and action state evaluators that can be used in conditions that are better suited for this job.
Update:
I would write a Type 19 error custom action that blocks the installation if the user is requesting a two conflicting features to be installed or the user is requesting one feature to be installed that conflicts with another feature that is installed. Use the feature request and installed state operators in your conditional expressions and schedule it after CostFinalize.
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.
InstallShield Express Custom Actions “Before System Search (Silent Mode Only)” and “Before System Search (Not in Silent Mode)” don’t appear to work as explained.
I have an installer that needs to work for silent and “loud” installs. I need one of these two “sets” to actually execute but not both (2 vb scripts under each). Depending upon if this is a clean install or a maintenance install, more than one set runs. I do not have steps under the Maintenance section.
This is my first attempt at a combined silent/loud install setup. I have been trying to get this to work for quit a while now. Trying different workarounds and express versions (2010, 2011).
You can try the conditions for clean install & maintenance install. Please find the conditions below :
For clean install : use Not Installed condition on your components
or sets or on actions.
For maintenance install : use Installed condition on your components
or sets or on actions.
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.