Update.exe searches for original.MSI-file

Using IS Dev 7.04, we built and deployed a release for a standard project. At that time, the project's path variables pointed towards the reference directory tree of our PVCS version control system. Accidentally, this directory was NOT saved in the state it had at that time, making it hard to rebuild the version at later times; what has been done, was marking the file versions of that build with a "version label", so that the state of the input for the IS project should THEORETICALLY be reconstructed at later times. This task was carried out and seemed to yield a reasonable result.
We needed that whole thing to build an UNCOMPRESSED setup to create a patch, since the setup we had deployed had been compressed.

The patch (a monolithic UPDATE.EXE sized about 7 MB) at first seemed to work, but the more we tested the more a problem occured, where application of the patch was aborted with an error message saying that the install engine was unable to find "x:\install\<project_name>.msi" (yes, .MSI and not .MSP), andfinally bails out with error -1603, which indicates - besides others - a "general failure", where the .MSI file name given is the same as recorded in the registry under the prioduct key of the application which was about to be patched, which seems to be HKLM\ SOFTWARE\ Classes\ Installer\ Products\ <Product_GUID>\ SourceList, values "LastUsed Source" and "PackageName"

So, if the original version of the app had been installed from a path which was not available any more (like a CD ROM or unconnected network drive), the patch would fail!

BUT, if the original install was done from the "reconstructed" input for the IS project, this seems NOT to happen! That is, you CAN install the original version from a removable media, and patch it while the media is NOT inserted, ready or present at all! But what are the preconditions for this to succeed without this dreaded error message and the following abortion with error -1603? Of course I read and honoured all known sources in the Knowledge Base, about "successfull patching" and how to prepare a paroject for patching, to my knowledge all theses conditions are fulfilled.

Looking for reasons and solutions, I found that the inputs for the IS project for original version differ in that the "old" input referred some files through dynamic links that were NOT present in the "new original" version. Could that be the reason for the patch failing in the situation described above?
Sorry for the complicated scenario, but I think this problem will be of importance to anyone who is about to deploy minor upgrades or patches, and who is silly enough not to save the input directories referred to (via the path variables) from the IS project which is subject to the patch, especially if dynamic links are used. It's not safe to rely on version labelling in the VCS used.

Has anyone else encountered this problem or any insights in the inner workings of the patch mechanism which can lead to the "prompt" for the original MSI file?

TIA.

Let me add some lines from the verbose log file:

--------------------------------------------------------
...
1: InstallShield Install driver started, version:7.07.262.0
...
SHIP UNICODE 2.00.2600.02 Calling process: C:\PROGRA~1\GEMEIN~1\INSTAL~1\DRIVER\7\INTEL3~1\IDRIVER.EXE ===
...
MSI (s) (98:13): Note: 1: 1729
MSI (s) (98:13): Produkt: <ProductName> -- Die Konfiguration ist fehlgeschlagen.
...
--------------------------------------------------------

which at the end leads to MSI error 1729 (Configuration Failed), which is scarcely documented in IS's KB, and which is "available since WI 2.0"; this "documentation" is a bad joke!

Does anyone know how MSI's error 1729 can be avoided? Is it bound to a certain OS or WI subversion?

wernerf

wernerf

wernerf

lavocat