This is gonna take some explaining but here it goes.
I need to author a multiple instance MSI which installs dynamic instances - i.e. instances defined when the user installs the package, not hard-coded in the MSI file. Now, I've already gone through the pains of creating a bootstrapper and using the MSI api to dynamically create a transform (MST) and apply it to the original MSI; after much tinkering, install and uninstall works fine (I'll post details as they're needed).
Basically, the MST contains transforms for ProductCode, ProductName, PackageCode (in Summary Info), changes GUIDs for all components (otherwise uninstall fails in silly ways) and the install location is protected from conflicts by the bootstrapper. Also, the bootstrapper starts the install with the command line parameter MSINEWINSTANCE=1, as detailed here.
However, I'd also like to upgrade an installed instance (via major upgrades), which is the main reason why the UpgradeCode is unique (or so I thought). However after I increment the MSI version and try to start it (again via the bootstrapper and passing in the desired instance's ProductCode via the MSIINSTANCEGUID property), it fails; the log says:
=== Verbose logging started: 12/13/2011 17:43:56 Build type: SHIP UNICODE 5.00.7601.00 Calling process: C:\Windows\SysWOW64\msiexec.exe ===
MSI (c) (5C:D0) [17:43:56:120]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (5C:D0) [17:43:56:120]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (5C:34) [17:43:56:120]: Resetting cached policy values
MSI (c) (5C:34) [17:43:56:120]: Machine policy value 'Debug' is 2
MSI (c) (5C:34) [17:43:56:120]: ******* RunEngine:
******* Product: D:\TestArea\AMLDC.msi
******* Action:
******* CommandLine: **********
MSI (c) (5C:34) [17:43:56:120]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (5C:34) [17:43:56:135]: MainEngineThread is returning 1625
=== Verbose logging stopped: 12/13/2011 17:43:56 ===
and a UI message pops up saying that 'the system administrator has set policies to prevent this installation'. Obviously that's not true (the policies would appear in the log and a rather more explicit message would be provided).
The 1625 error code seems to correspond to "ERROR_INSTALL_PACKAGE_REJECTED".
Any ideas to what I could try next? I'm thinking what the MSI engine should try to do in this case is examine the UpgradeCode, apply the original transform (which should be cached and reachable via the product code I give it via the MSIINSTANCEGUID parameter). However it's clear the engine never reaches that stage (it should be logged in the log file, right?)
Sigh, this has been much more painful than it should have been.
Edit: some time later...
Quick note on changing component GUIDs: it's only really necessary for non-file components (I have some registry entries I use to keep track of instances). If I don't change their GUID they aren't cleaned up correctly at uninstall, as detailed here. For files it works fine if the key paths are different, and I've verified that by only changing the registry component ones in my code.
So I've learned in the meantime that major upgrades probably won't work for me unless I change the UpgradeCode for each instance (because FindRelatedProducts only looks at the UpgradeCode, I think), and I tried something else before going there: minor upgrades.
Starting the installer for a new version with /fvamus together with MSIINSTANCEGUID={existing-instance-product-code} seemed to work, right up until I've tried adding a new file to the package (which I expect to happen in the future)... when of course it doesn't work (the component for the new file is not installed at reinstall, of course).
So I'll probably either have to change the UpgradeCode with the transform and see what that implies, or mess around with the output property of FindRelatedProducts through some custom actions and see if I can convince major upgrades to work that way. However the initial problem (the 1625 error) was precisely with major upgrades so not sure if I can do something about it without knowing the cause. To be entirely clear: what I pasted above is the entirety of the MSI verbose log, it doesn't seem to do anything before returning with error 1625. I also tried removing all the rows in the Upgrade table of the MSI and there was no change in behavior.
I also can't spend much more time on this silly issue so if nothing else works I'll be forced to do a silent uninstall followed by a regular install with the same settings. I cringe at the thought but if it can't be helped...
Edit: in all fairness, it probably would have gone faster if I didn't start on the MSI path altogether and coded my own installer from absolute scratch, with gzipped streams and simple xcopy. Even with a msbuild task that would have compressed the files from visual studio or something.
I just tried this
msiexec /i <package>.msi /n {<InstanceProductCode>} REINSTALL=ALL REINSTALLMODE=vomus /qb
As described here: http://msdn.microsoft.com/en-us/library/aa369528(v=vs.85).aspx
This does work for me even if i add new files to the next version of the MSI.
Couldn't you make your instances as features? Then they will be selectable during installation and upgrades works well with them. There is even special action "MigrateFeatureStates" for loading state of already installed ones.
As for components that refused to clear - probably you need to specify persistent="no" for them explicitly? Then they must be removed during uninstallation.
This has been sitting here for quite a while so I thought I'd close it. The way I went in the end was to uninstall the previous instance and do a normal install afterwards. Seems to go pretty well, all things considered; gets the job done.
Related
We have a msi package which installs a Windows Service. At end-of-day, the windows service downloads a new msi package from a public blob location and kick off reinstalls.
The reinstall command =
msiexec /i GatewayService.msi /qn REINSTALL=ALL REINSTALLMODE=vamus /L*V msi.log
What we want is as follows:
This should reinstall the whole msi package again w/o any check on
any conditions
Whatever files are in the new msi should be copied to installed dir and files not in the new msi should be trashed.
So essentially what we want is like UNINSTALL old msi and RE-INSTALL new MSI in one command.
We were wondering
if the REINSTALL/REINSTALLMODE flags value are correct ?
Sometimes we see an orphaned Windows Service in TaskManager. Any idea why the re-install command resulted in 2 instance of Window Service?
Suggestions would be grateful!
You produced a log - take a look and see if there are any mesasges about removal of components being unsupported. Also set MSIENFORCEUPGRADECOMPONENTRULES=1 on the command line and the install will fail if you broke a minor update rule. If it does fail, then the author of that MSI is breaking update rules and Chris' advice to do a major upgrade is required and not optional!
The services may not have ServiceControl actions to stop and start them, so they'll just keep running over the update because nothing is telling them to stop. This can be complicated by in-use files requiring updates because your silent install has no file-in-use dialog to prompt to shut down processes.
You can get an apparently orphaned service process if the service shuts down (the process ceases to be a service) but the containing process is still running. That might be normal if the service responds to the shutdown but continues afterwards for some time, that depends on the code in the service.
Your commandline indicates that you are doing a minor upgrade. Your requirements indicate a major upgrade would be more suitable for you.
How To: Implement a Major Upgrade In Your Installer
Minor upgrades are very picky and breaking rules are likely causing your duplicate service problems. See:
Changing the Product Code
When I try and apply a minor upgrade to my application, I launch the installer and (depending upon the combination of settings I try) I get either a:
repair/remove dialog
prompt for the install directory
I don't believe I should get either of these prompts. I'm mostly expecting the installer to automatically apply the upgrade and not prompt for anything. I think I'm doing everything correctly in the Visual Studio setup project:
upgraded the version from 1.0.0 to 1.1.0
left the product code the same
updated the package code
left the upgrade code the same
launch the installer with the parameters REINSTALLMODE=vomus REINSTALL=ALL
I've tried just about every combination of codes/flags and techniques, but cannot seem to get the update applied.
Any ideas of what else I can try?
To get it to work I:
upgraded the version from 1.0.0 to 1.1.0
left the product code the same (said No when prompted by Visual Studio)
updated the package code (Visual Studio did this automatically)
did not change the upgrade code
launch the installer with the parameters REINSTALLMODE=vomus REINSTALL=ALL
Just as I had indicated in my question, and it seems to be working. I can successfully apply an upgrade. However, when I run the installer I am still prompted with a repair/remove option. But, that's a different question I guess.
Just first things first: Are you sure you haven't re-used the package GUID in both MSI files, or at some point during deployment work and testing?
Try rebuilding both MSI files with new GUIDs to "de-couple" them from any existing cached versions and then try test installing again. Change both the package code and product code. Better yet: test these new versions on a clean virtual machine to ensure a proper test environment unaffected by past sins. Your developer system could have gremlins in its Windows installer database due to package guid clashes. If this is the case package installation becomes total XFiles - the strangest things can happen.
More details:
If the package GUID is the same for two MSI files, Windows Installer will treat them as the same file by definition - no matter what they contain. This can cause all kinds of strange problems that are hard to clean up and debug. Note that this can happen even if you just forgot to update it once since installation of an MSI will cause it to be cached on the system in the C:\Windows\Installer folder (this folder is hidden and protected). This cached copy will be re-used if an MSI file with the same GUID is launched (at least this was the case for earlier versions of Windows Installer - there could be fixes for this now).
If you are using Installshield you should enable the "always generate packaging GUID" feature to ensure this never happens. Package GUID should always change for every single build - there is no reason whatsoever to keep it hard coded. I believe WIX takes care of generating the package GUID automagically, unless you specifically override it.
We have an installer solution written in Visual Studio 2005 Installer; that calls a C# custom action and we have hit a known issue, regarding the fact that on an upgrade - the old install code is run and not the new code, because Windows is running a cached version of the custom action dll. We know this and although not over the moon about it - we have moved on.
When we release a new version of the installer and a user runs it, we now want it to check to see if an ealier version is installed - if there is one; we want to display a message telling them that they have to remove the old version via Add/Remove Programs. We know if they do a manual uninstall followed by an install, then all is fine and dandy - BUT it doesn't matter how many times we tell our users, via documentation; that this is what they have to do - they will still try and just run the new installer, without removing the old version first.
Therefore, we would like to put up a message and thus force them to to what they are told !! I've seen some installers do this ( though of course not sure what installer package was used to create these ). We only have VS 2005 and of course orca !!
Cheers,
Chris.
This can be done through a custom launch condition:
create a search which determines if the old version is installed (you can search for a component, registry entry or file)
use the search property as a custom launch condition
For example, if the search property is OLD_VERSION, the launch condition can look like this:
Condition: NOT OLD_VERSION
Description: An older version was found. Please uninstall it using "Programs and Features" in Control Panel.
When OLD_VERSION property is set to a value (an older version is found), this launch condition will show the message and stop the install process.
This doesn't quite make sense. Have you remembered to change the package GUID in your new setup? The package GUID identifies a specific setup file, and if two MSI files have identical GUID they will be treated as the same file regardless of whether they are or not. This could trigger a cached version of the MSI to be invoked and all sorts of hell breaks loose.
I would recommend reading up on "major upgrades" which will allow automatic uninstall of the existing version before the new version is installed. You also need to make sure you understand the basics of the technology before deploying to the wild. You must NEVER use identical package GUIDs for any MSI files. It's practically always wrong, and will lead to very mysterious problems.
I can't write up the whole major upgrade solution here, but basically it involves authoring the "Upgrade" table of your MSI to detect versions to uninstall. You need to change the package code, product code and version number (only 3 digits matter) and keep the same upgrade code (two MSI files with the same upgrade code "know" they are related - i.e they are from the same product family). Check MSDN for samples of major upgrades.
NB! If you have deployed MSI files with duplicate package GUIDs to your developer machine, it could have stray installs that must be cleaned up with MSIZap or similar. Use caution, or better yet test your new installer on a clean test system. Developer systems are full of junk and not generally good for MSI testing.
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.
I often get a problem with Windows Installer trying to uninstall a package, but it complains that:
The feature you are trying to use is on a network resource that is unavailable.
Is there a known means of uninstalling such packages when the original MSI is simply not available?
Please note that Microsoft has now released an official tool to resolve these issues, without the problems that previously existed with MSIZAP.
Microsoft Fixit: Fix problems with programs that can't be installed or uninstalled
Take a look at a tool called MSIZap released by Microsoft.
UPDATE:
MsiZap.exe has been deprecated for quite some time. Its use is unsupported on all recent versions of Windows, and it is considered a very unsafe tool to use.
I added a link to a newer Microsoft support tool designed to clean out installations, but this tool also appears deprecated at this point. I have removed the link from the comments section.
Perhaps try the tool linked to in saschabeaumont's answer below.
FYI, this post explains the root problem https://superuser.com/q/293542/245923
You can uninstall it using the product code:
msiexec.exe /x {your-product-code-guid}
You would obtain this code from the MSI itself, or whatever tool you are using to build the MSI.
Note that when you uninstall a product, it uses a cached MSI, since only the original MSI knows how to uninstall itself. When you use the product code, it uses the cached MSI from C:\WINDOWS\Installer.
Update, Stein Åsmul: There is a whole list of cleanup approaches here (recommended).
UPDATE:
This newer support tool can be tried on recent Windows versions if you have defunct MSI packages needing uninstall. This new tool appears to have been deprecated as well.
Perhaps try the tool linked to in saschabeaumont's answer.
It is not normal or standard MSI behavior to ask for the original source media - it indicates a badly designed MSI package. If you experience this with a vendor MSI it is highly recommended that you report the problem to their support team. Here is a more comprehensive explanation of the problem: Why does MSI require the original .msi file to proceed with an uninstall?
In most cases MSI packages can be uninstalled from add/remove programs from the control panel even if you don't have the original installation database for the MSI - the uninstall is run from a cached copy of the original MSI in the system folder %SystemRoot%\Windows\Installer (in some cases this cached MSI could be missing, see section 12 here for potential causes).
Earlier versions of MSI tended to trigger this problem (asking for the original installation media) more often (Office back in the day), and legacy MSI files can still cause uninstall problems that can only be solved using the msizap.exe tool (this tool is deprecated, outdated and no longer supported). This command line tool (msizap.exe) also had a GUI available (MSICUU2.exe), both tools are deprectated (try the link to the new cleanup tool listed above).
Just for the record: If you have access to the original MSI that was actually used to install the product, you can use this to run the uninstall. It must be the exact MSI that was used, and not just a similar one. There is a unique package guid assigned to each MSI file, so Windows will know if it is the right one.
Related answers:
wix - custom action dialogbox on silent uninstall of application
Uninstalling an MSI file from the command line without using msiexec
You didn't do something crazy like go to C:\Windows\Installer\ and delete the files in there did you?
One drawback of MSI files is you need the complete MSI file in order to uninstall or repair the application. Windows loves to store a copy of the MSI. It also renames the MSI file from a common name to a GUID with no table (that I can find) to map original names (example: Office2010.msi) to the new GUID so you have a PC with many GBs of wasted space that you can't delete. A machine that's not even 1 year old can easily hit 8 GB (example: mine).
There is an MSI cleanup utility from Microsoft, Windows Installer Cleanup Utility (deprecated tool, unsupported and unsafe to use - perhaps try this answer instead: Uninstall without an MSI file).
Or CCleaner can usually do this
Control Panel --> Add/Remove programs?
EDIT:
Your post mentions nothing about using add remove programs to uninstall the app, you said the "Windows Installer" (MSIEXEC - see the link below), which is not the same thing.
http://msdn.microsoft.com/en-us/library/aa367988(VS.85).aspx