OK, so my nested installations now install and uninstall properly and even manage to rollback correctly if any one of the nested MSIs has a problem.

However, if any of my nested MSIs contain any advertising, then the self-healing does not run properly. I tried deliberately breaking a package (by deleting one of the files in the keypath) and then launching the app. The advertised shortcut detected the missing component and then tried to call the package source. However, on calling the source, it looked to the correct install folder, but the wrong MSI filename. The name it looks for is the name of the locally cached version of the installation that is created in C:\WINDOWS\Installer (a random name consisting of numbers and letters e.g. 3ae15r.msi). If I duplicate my source MSI package and rename it to the locally cached name, then the self-healing runs perfectly. Obviously this is not a suitable workaround as the locally cached MSI name is randomly generated for each individual install.

So is this a limitation of MSI nested installs or is it a bug with the Installer?

0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


Could the 'solution' be to disable advertising for the nested MSI packages? I have just learned that this can be done by setting the property DISABLEADVTSHORTCUTS = 1
Seems crazy that in order to take advantage of one feature of MSIs, you've got to sacrifice another.
I am assuming that this is just a limitation of the Microsoft Windows Installer - has anybody moved to schema 3.0 yet?, as I'd be interested to see what, if anything has changed/improved.

Answered 12/14/2004 by: ab2cv
Orange Senior Belt

Please log in to comment