Hi!

I have seen from time to time that starting an application sometimes triggers self repair on other applications and I can´t figure out why.
Even if the two applications should share files/reg. values the self repair for the "other application" shouldn´t be triggered from starting another application or am I wrong?

Am I repackaging the applications wrong somehow?

Cheers
0 Comments   [ + ] Show Comments

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.

Answers

0
What does the Windows Installer-logfile say?
You can also check the EventViewer for extra details.
Answered 05/12/2011 by: pjbaars
Orange Belt

Please log in to comment
0
I looked at one computer with this issue and it seems like an ordinary self repair. It can´t find a HKCU key that I have never seen before from a program I know nothing about. The program that triggers this is a completely different program with no keys under that path.
Answered 05/13/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
You can diagnose self-repairs by deep diving into the logs.

Have you checked it already?
Answered 05/13/2011 by: pjbaars
Orange Belt

Please log in to comment
0
Where can I find these logs?
Answered 05/13/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
David,

if the conflicting file in question (let's say it's a DLL) happens to also provide an advertised entry point for the packages (i.e if it was registered by the MSI and there's a Darwin Descriptor with the registry entries), then any action that "calls on" this file will actually initiate a self-heal cycle. At that point if a new application has actually changed the component's registration data for that file, for example by installing the same file with a component that has a different GUID, a repair WILL be triggered.

There are more types of triggers for a self-heal than missing HKCU keys. There are a number of tables in an MSI besides the Shortcuts table that can create an entry point, off the top of my head, the Class, ProgID and MIME table are amongst these, but that list might not be complete. Then what triggers the install just depends on what the key paths for the components are.

As you probably know, this is actually the crux of the Conflict Management principles when building MSIs, making sure that if 2 or more packages install the same resources on a machine, they do it with components that are, to the highest extent possible, identical amongst packages (same contents and GUIDs). Same with why using Merge Modules can avoid these kinds of problems.

Rgds,

PJ
Answered 05/13/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
First set registrykey below to enable Windows Installer Logging in general:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Waarde: voicewarmupx

After this is done, reproduce the error and locate the logfile in %temp%. Logfile is in format MSIxxxxx.LOG. The x's are random generated.

You can also check the EventViewer for MSI Installer logs. If a repair is triggered, 2 entries are logged. In the logs you can find the exact component in the msi of the conflicting application that is producing the error.
Answered 05/13/2011 by: pjbaars
Orange Belt

Please log in to comment
0
Ok thanks all I´ll check these things out! Then it´s "just" a matter of figuring out how to avoid these things.
Answered 05/13/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
0
a matter of figuring out how to avoid these thingsAs Pieter mentioned, this is what Conflict Management is about.
Answered 05/13/2011 by: VBScab
Red Belt

Please log in to comment
0
the application event log should show the offending component name / product code in the event log.

The component code is of more use to you as the keypaths associated to the component act as the trigger for the self repair. You can find the component code list in here

HKEY_CLASSES_ROOT\Installer\Components
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components

If the component has two products listed it is probably your issue. You may also wants to check the value of each product has the same keypath value. If it doesn't this is likely to be your issue.

You will also need to reverse order of the guid this is well documented all over the place, i blogged about it somewhere once.
Answered 05/14/2011 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
0
Yes I saw the component GUIDS, thanks I´ll check it out and hopefully find a way to avoid these things in the future somehow!
Answered 05/15/2011 by: Agathorn
Senior Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity