This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: What causes an auto-repair?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 06, 2007
02:15 PM
What causes an auto-repair?
One of my main concerns if I have to replace some existing dll's with my seperate add-on install, is that the auto-repair functionality would kick off when the customer is using our main product. I have been doing a lot of research on auto repair / resiliency, but I cannot find specific details as to what causes it. Basically the only thing I can find says it will happen if there is a missing file, or the file is corrupt. Is there any documents or KB articles that I have missed that go into more detail as to what would or would not cause an auto-repair? Some of the questions I have in mind are:
1) Does windows installer just check for the presence of a file, or does it also compare a specific version?
2) If I replace a few existing dll's with a higher version, would this kick off the auto-repair?
Thanks in advance for your help.
1) Does windows installer just check for the presence of a file, or does it also compare a specific version?
2) If I replace a few existing dll's with a higher version, would this kick off the auto-repair?
Thanks in advance for your help.
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 06, 2007
03:24 PM
In my experience, anyway, I haven't seen anything but a missing file or registry key kick off an auto-repair. I don't believe that it checks version numbers -- or even if it did, the repair would not replace a higher versioned DLL with a lower-versioned one.
One thing that did come to mind ... would it be possible to update those DLLs with an upgrade to the original installation kit?
I would say this: Give it a try! Find yourself a test machine (physical or virtual) and run your test... see what happens. 🙂
Hope this helps.
One thing that did come to mind ... would it be possible to update those DLLs with an upgrade to the original installation kit?
I would say this: Give it a try! Find yourself a test machine (physical or virtual) and run your test... see what happens. 🙂
Hope this helps.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 06, 2007
04:11 PM
Read up on the Windows Installer properties REINSTALL and REINSTALLMODE, which are used during a repair/reinstall.
It all revolves around the key identified for the component(s) that make up the feature(s), and under what conditions it will reinstall its resources. The default for a standard reinstall/repair is REINSTALLMODE=omus which is:
o - Reinstalls if file is missing or an older version is installed.
m - Rewrites all required computer-specific registry entries.
u - Rewrites all required user-specific registry entries.
s - Overwrites all existing shortcuts.
Hope that helps!
It all revolves around the key identified for the component(s) that make up the feature(s), and under what conditions it will reinstall its resources. The default for a standard reinstall/repair is REINSTALLMODE=omus which is:
o - Reinstalls if file is missing or an older version is installed.
m - Rewrites all required computer-specific registry entries.
u - Rewrites all required user-specific registry entries.
s - Overwrites all existing shortcuts.
Hope that helps!
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 07, 2007
10:14 AM
The entry points to advertisement are generally documented in the document Platform Support of Advertisement; however, there obviously may be undocumented entry points to auto-repair. Invoking a COM Server is the most common form of invoking an advertised entry point (ie, ATL.dll can often be associated with MSDE and thus become a very common way to invoke MSDE auto repair without intending to do so).
An easy reproduction of that issue is to include the MSDE object with installshield, install it with one product and then subsequently attempt to install something with self-registration set to "Yes". You should see an auto repair dialog appear during the self-registration process for each file.
Simply removing a file an then attempting to launch a standard shortcut will not invoke auto-repair because nothing tries to actually trigger it.
At run time, experience has demonstrated that you will see REINSTALL set to the feature that triggered the auto repair entry point. However, you may see that Windows Installer schedules components to be reinstalled despite the fact that their features may not actually be listed by the REINSTALL property. You will see something similar to:
Feature1 Installed: Local Request: Null Action: Null
Feature2 Installed: Local Request: Reinstall Action: Reinstall
Component1 Installed: Local Request: Null Action: Local
Component2 Installed: Local Request: Local Action: Local
During auto repair the REINSTALLMODE property is set to pocmus, which may explain why files not included in the feature triggering the auto-repair are replaced if they are missing.
Because altering a version of a file on a system would not constitue that file to be replaced by Auto repair (unless the file's version was lower, but it takes a lot of time & effort to check), Windows Installer does not inspect version information for Auto Repair. Specifically it's looking for missing advertised entry points to invoke auto repair. Once it's determined that, though, the auto repair behavior would normally invoke a reinstallation of missing files. Existing files should be left untouched.
An easy reproduction of that issue is to include the MSDE object with installshield, install it with one product and then subsequently attempt to install something with self-registration set to "Yes". You should see an auto repair dialog appear during the self-registration process for each file.
Simply removing a file an then attempting to launch a standard shortcut will not invoke auto-repair because nothing tries to actually trigger it.
At run time, experience has demonstrated that you will see REINSTALL set to the feature that triggered the auto repair entry point. However, you may see that Windows Installer schedules components to be reinstalled despite the fact that their features may not actually be listed by the REINSTALL property. You will see something similar to:
Feature1 Installed: Local Request: Null Action: Null
Feature2 Installed: Local Request: Reinstall Action: Reinstall
Component1 Installed: Local Request: Null Action: Local
Component2 Installed: Local Request: Local Action: Local
During auto repair the REINSTALLMODE property is set to pocmus, which may explain why files not included in the feature triggering the auto-repair are replaced if they are missing.
Because altering a version of a file on a system would not constitue that file to be replaced by Auto repair (unless the file's version was lower, but it takes a lot of time & effort to check), Windows Installer does not inspect version information for Auto Repair. Specifically it's looking for missing advertised entry points to invoke auto repair. Once it's determined that, though, the auto repair behavior would normally invoke a reinstallation of missing files. Existing files should be left untouched.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)