Login to XP, Application Self-Repairs
Hello Forum,
Has anyone came across the following problem:
Package an application and install as an administrator. Test package works fine. Log in as a POWER user and the application automatically self repairs WITHOUT you attempting to launch the application
Against best practises we are using Roaming Profiles when testing so this should also be taken into consideration.
Event view has the following information:
Detection of product '{8E2D289F-F2F5-4E10-8BB6-93D6B640231F}', feature 'Complete', component '{44549DDE-3514-44A1-861F-EDF60DBA8037}' failed. The resource 'HKEY_CURRENT_USER\Software\App\... ...\Key\Value' does not exist.
Now the component has that registry key and is set as the keypath. The only other thing in that component is a create folder entry which is in the CreateFolders table.
There any some ICE03 and ICE33 warnings when you run validation but nothing that would affect this package.
Has anyone came across the following problem:
Package an application and install as an administrator. Test package works fine. Log in as a POWER user and the application automatically self repairs WITHOUT you attempting to launch the application
Against best practises we are using Roaming Profiles when testing so this should also be taken into consideration.
Event view has the following information:
Detection of product '{8E2D289F-F2F5-4E10-8BB6-93D6B640231F}', feature 'Complete', component '{44549DDE-3514-44A1-861F-EDF60DBA8037}' failed. The resource 'HKEY_CURRENT_USER\Software\App\... ...\Key\Value' does not exist.
Now the component has that registry key and is set as the keypath. The only other thing in that component is a create folder entry which is in the CreateFolders table.
There any some ICE03 and ICE33 warnings when you run validation but nothing that would affect this package.
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
aogilmor
18 years ago
you have included something in your package that doesn't need to be there, something very low level like a Windows shell component, and that's why it attempts to repair before launching the app.
Go thru your MSI with a fine tooth comb and make sure no superfluous reg entries are there.
This is a very common mistake with repackaging.
Go thru your MSI with a fine tooth comb and make sure no superfluous reg entries are there.
This is a very common mistake with repackaging.
Posted by:
PackMan999
18 years ago
Thanks for your post aogilmor,
I have now got down to the problem and think I should have maybe has some more information in my post. Here's what I have found...
COMCTL32.OCX was getting put down by my application. This already exists on the build so it was overwriting the version in c:\windows\system32. In the run key there are applications like QuickTime, SVG Viewer etc that are running and these applications self-repaired when you logged onto the workstation. When these applications self-repair they are replacing that file and then my application realises this file is also changed and self-repairs putting it back in. I hope this makes sense.
I deleted the file from my package and tested it and it works fine without the application self-repairing. (My application will work with the builds version so I'm going to leave it out completely!)
I then added it again to the package and done a WiseComCapture on the OCX and added it the the package and tested it. Self repair re-occurred as it had added advertising information. I deleted the advertising information, tested it again and this time NO self repair. I have tested this on numerous builds with different profiles and it looks like its resolved.
Thanks again for the post!
I have now got down to the problem and think I should have maybe has some more information in my post. Here's what I have found...
COMCTL32.OCX was getting put down by my application. This already exists on the build so it was overwriting the version in c:\windows\system32. In the run key there are applications like QuickTime, SVG Viewer etc that are running and these applications self-repaired when you logged onto the workstation. When these applications self-repair they are replacing that file and then my application realises this file is also changed and self-repairs putting it back in. I hope this makes sense.
I deleted the file from my package and tested it and it works fine without the application self-repairing. (My application will work with the builds version so I'm going to leave it out completely!)
I then added it again to the package and done a WiseComCapture on the OCX and added it the the package and tested it. Self repair re-occurred as it had added advertising information. I deleted the advertising information, tested it again and this time NO self repair. I have tested this on numerous builds with different profiles and it looks like its resolved.
Thanks again for the post!
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.