I have an installer from a third party. Through trial and error I discovered it was an innosetup installer. When I call it with the /silent flag it installs just fine, until it executes installers for 3 dependencies (direct X is one, for example) which then require user input to cancel. I want to be able to run the installer and have it either install the dependencies silently or not at all. When going through the installer GUI normally it does give me 3 checkboxes at the end on the last page of the wizard (before I would hit the Finish button) that allows me to choose whether or not to install the dependencies. Is there a way of doing this that I don't know about? From my research it seems impossible without knowing the types and components available (and executing the installer with the /help or /? options had no effect) and I will probably need to get a new installer from the third party. The only other option I can think of would be to have some sort of timeout that after a certain period of time of inactivity from the installer I kill the install process (since the files I was interested in had already been installed at that point I think).
Checkboxes on the finish page sound like postinstall [Run] entries. There is no way to influence the selection of these from the command line, except that the original setup author can choose to have a different set of options selected for interactive install vs. silent install. (Or they might have extended the /LOADINF option to work with these, although this is unlikely.)
Given that this is a third-party installer, your best bet is to contact the original vendor and see if you can get them to change the default silent selection, or to add an additional command-line parameter to change the defaults.
Failing that, you could consider using a program such as AutoIt to auto-click the wizard GUI when run non-silently.
(If the things that it's trying to install really are dependencies, though, then you probably should let it install them. And it should be installing those silently too anyway.)
Killing the install process after a specified time seems like an excellent recipe for disaster.
Those are probably [Tasks] within InnoSetup's install, which you may be able to deselect by passing /tasks="" in the command line (along with the /silent). Here is a list of command line options: http://www.jrsoftware.org/ishelp/topic_setupcmdline.htm . Adding /suppressmsgboxes may help also.
It seems it is impossible to do what I wish without knowing more about the structure of their setup. I was however successful in solving my original problem by killing the third party installer after waiting a specified amount of time (which I got from reading this question).
Related
If I execute a Wix installer for first time it will install as expected.
If I re-run the installer it correctly enters maintenance mode (Repair/Change/Modify)
However if I re-compile the installer between the initial install and the re-run, it treats it as new installer. I have tried using the same Product Id but when the newly compiled installer is executed, I then get a message saying it has already been installed and must un-install the previous version.
As part of our development I am trying to resolve some issues with the Maintenance UI and don't want to have to run the installer twice every time I wish to debug the maintenance wizard. I would like the re-compiled installer to be treated as if it were the original installer.
Thanks for any pointers you may be able to throw at me, or other suitable resource
Technically this is not something that you should do. By rebuilding, you are altering the package, which means it is supposed to have a new package code. When it has a new package code, but matching product code and version, it is a small update. You can skip the uninstall and install by instead performing a reinstall via msiexec /fvomus your.msi or msiexec /i your.msi REINSTALL=ALL REINSTALLMODE=vomus.
As another approach, if what you are testing doesn't depend heavily on machine state, you can tweak some of the entry conditions for the maintenance UI such that it occurs on a first-time installation, and ensure that the package cannot install. This puts you in a simpler reproduction loop, but will require transplanting your finished code back to the real scenario.
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 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.
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
When trying to remove our application in Add/Remove Programs, the following error pops up, and the application fails to uninstall:
Error
'mFileBagIDE.dll' is not a valid short file name.
The curious thing is that you only get this error if the original installation DVD is not in the drive. If the DVD is in the drive, the uninstall works perfectly.
Here's the real kicker: we did not catch this bug until after our application was already widely deployed, and our clients' situations are such that it is likely many of them no longer have their original DVD. This means that the next version's installer (doing a windows installer major upgrade) will fail because it is unable to first remove the previous version.
So, my question is twofold:
What did we do to create this problem so we can avoid it in future releases?
Is there a way to tell our next windows installer to ignore this error and go ahead and remove the previous version?
Our current installer (the one that is causing problems) was generated using InstallAware. We're likely moving to WiX. But solutions in any platform (InstallAware, WiX, raw MSI tables) are appreciated!
UPDATE: I have the following row in both the InstallExecuteSequence and InstallUISequence tables in my MSI, which may very well be relevant, but I have no idea what the SRCDIREX property is, or where it is being set.
| Action | Condition |
|---------------|--------------|
| ResolveSource | NOT SRCDIREX |
Probably one of the actions (either standard or custom) that references the original MSI was not conditioned to run on installation only (for example, ResolveSource should be conditioned as "Not INSTALLED"). You might be able to workaround this with a patch (an MSP file) that changes the condition on the relevant action.
I would start by determining which action is causing the error. Here's how I would do that:
Install your app from the dvd
copy the msi file to some local folder, let's say "c:\temp"
Remove the dvd
kick off the uninstall like this: "msiexec /x yourapp.msi /L*v c:\temp\uninst.log"
When the error comes up, the uninstall is effectively paused. You can then check the end of the log to see exactly where you are in the sequence. That should help you to debug.
If the answer really is ResolveSource, regular patching may not be an option.
Heath Stewart mentions this in his blog -
http://blogs.msdn.com/heaths/archive/2007/10/25/resolvesource-requires-source.aspx
"In general, do not schedule ResolveSource. If this runs when installing a patch, for example, the user will have to insert the original media whether they would otherwise need to or not."
If that's the position you find yourself in, you could create a transform that updates the condition on your ResolveSource action, and apply that to the cached copy of the msi file manually. It's a bit of a pain, but I'm pretty sure that would work.
have you tried to copy those files to %WinDir%/system32 folder?
EDIT: Make a setup to copy all the setup MSI package to the disk, and install it from the diskdrive.
Remove every files uneeded to uninstaller. Adobe, HP and many other companys are doing that.