I have 2 Inno Setup installation packages. A is dependent upon one or more components in B. Normally, A would silently install B flagging just the components it needs installed. Suppose B is already installed with user selected components. Now A will be installed and needs its usual components from package B. How to ensure this? Can I just run the silent install as usual to only additionally install the needed components if they were not already? Will this remove already installed components if they are not selected?
You can just run the install silently with the required components.
Inno itself doesn't remove unselected components but the script can perform operations to remove features when a component is not selected.
If you have control over setup B and you've not done this then you don't need to worry.
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.
I am using Visual Studio 2013 installer to package my application. I then make a copy of the MSI, open it in Orca and remove all the dialogs to create a silent package. So I have two MSI's that should be the same other than one is silent and the other is not.
When I upgrade from a previous version (built in the same way) using the non-silent package, everything works perfectly.
However when I upgrade from a previous version using the silent package, it all works apart from I am left with 2 entries in Add/Remove programs. It all works though but looks ugly for the client. When i uninstall the latest version, Add remove programs still has the previous version listed in Add/Remove programs although actually the latest version is still installed.
As I say, the non-silent package works perfectly well, which leads me to think I must have everything setup correctly in Visual Studio and Orca must be doing something I didn't intend.
Any help would be much appreciated.
If you have two entries in Add/Remove Programs then the upgrade didn't work. A common reason is that one of the installs is Everyone and the other is Just me. If you delete the dialogs then you have altered the behavior that sets the ALLUSERS property, and your upgrade could default to Just me. In the absence of a decision to use one of these choices VS setups use ALLUSERS=2 which is defaulting to a per user Just me install, that's the likely reason. Elevation is involved too - VS setups would rather your MSI did a successful Just me instead of a failing Everyone if privilege state is not clear (and in MSI setups it often isn't).
You might need to go to the Property table and set FolderForm_AllUsers to "ALL" and ALLUSERS to 1 to force a per machine Everyone install.
How silent do you want it to be? If it requires elevation to install successfully then you need the elevation dialog to be shown or the install will fail silently if you force a per machine Everyone install.
I am using WiX to install a executable and I have used ManagedBootstrapperApplicationHost for CustomUI.
Is it possible to get the name of the feature being installed at the time of installation ?
If possible then how can we get the name of the feature ?
Any help would be appreciated.
Thanks.
Features aren't installed one after another. For example if 3 features are being installed, each with 10 files then the InstallFiles action will install all 30 files at the same time. Same thing with registry entries. So you can't display a UI that says "Installing Feature1" and then later on "Installing Feature2" because that doesn't happen. All you can know is that some list of features are being installed.
Your comment asks about finding out whether a feature installed successfully or not. This issue never comes up - there are never some features that install and others that fail. An MSI install is a transaction and it either all works or fails and rolls back and deletes changes it made so that the system is restored to its previous state.
It's not clear why the list of features is so important to display. If you use the MSI's internal UI there is a feature selection dialog where the user selects which features are to be installed; if you use the Burn UI the same thing is available, so the user can see what features have been chosen.
Inside the MSI the list of features being installed (after they've been selected) is in the ADDLOCAL property, but that's the internal name. It could be used to display a list of the features that were installed at the end, but again by definition what was chosen is installed otherwise the install would have rolled back entirely. I don't believe I've ever seen an install where the list of MSI features installed is displayed at the end - it's redundant info. It would be useful to know the scenario you have, or what problem you're trying to solve, and if you believe that you need to display a list because some might install and others might fail then there is no point, as I have said.
I want my installer to prompt the user to uninstall an existing installation before installing the new one if an installation already exists at the selected install directory.
Right now I'm trying to just call the uninstall dialog and let it continue its normal execution from there, but since it is already in the install sequence, it continues to run functions for installing, rather than uninstalling.
Is this even possible to do? And if not, how else might I accomplish the same thing.
I'm using a Basic MSI project, and due to the nature of my installation, I don't believe I'll be able to set up a Major upgrade.
I currently have a windows product with a bootstrapper that runs 5-6 MSIs during installation. A couple of those MSIs can be upgraded out-of-band by running newer versions of those MSIs directly on the system. The bootstrapper is currently used to manage uninstalling all MSIs when the main product is removed. Is there a way to remove the bootstrapper from the uninstall logic? I'd like to find a way for an uninstall of the main product MSI to handle the removal of all the other 'children' MSIs.
For example: I have a product installer Foo.exe that runs A.msi, B.msi and C.msi during an installation. During the lifetime of the application the user upgrades B.msi to B'.msi and C.msi to C'.msi, now the user has A.msi, B'.msi, and C'.msi installed (Only A.msi shows up in ARP). How can I get the uninstall of A.msi to remove B'.msi and C'.msi as well?
You should be able to uninstall the old products by authoring a major upgrade using the Upgrade table. Maybe check out http://www.appdeploy.com/tips/detail.asp?id=106 and http://msdn.microsoft.com/en-us/library/windows/desktop/aa372374(v=vs.85).aspx .
One possible way is to have A.msi install an Uninstaller.msi. The Uninstaller.msi is basically an empty msi with Upgrade table entries for the upgrade codes for A.msi, B.msi, and C.msi. The Uninstaller.msi also has the PublishProduct standard action condition set to '0' so that it will never run. Then, A.msi manually hooks up the Uninstaller.msi to the product A ARP entry. When the Uninstaller.msi is run it executes FindRelatedProducts, RemoveExistingProducts (removing all 3 msis), and finishes without registering itself as 'installed' by windows. This gets the job done in a single, rollback-able transaction. The only trick is figuring out how to get Uninstaller.msi off the system when all is said and done...