Software Deployment

[8D]

I'm probably stating the obvious here: Check the Application Event Log to see which component is causing the self-repair. Then within your MSI file, check this component's keypath. This should help you troubleshoot this issue.

[8D]

It sounds like the MSI has a file that is being reset with Windows File Protection. Then the MSI finds it changed and self repairs, then Windows File Protection changes it back, and so on.. and so on...

Check your event log for WFP events. You shouldn't find any. If you do, either take the file out of your MSI or change it to a more appropriate version.

I don't believe that file versions or registry key values are checked every time you invoke an advertised shortcut. It's my understanding that this would only be done during a "repair" of the feature or component.

Thanks everyone. It was a permissions problem with a registry key.

I'm glad your problem's gone away, but I don't understand your explanation.

You said: "Once you've fired up the app, it doesn't run again until you log off." If you didn't have permissions to create a registry keypath, the component would remain broken. Therefore, a repair would be initiated every time you invoked an advertised entry point - not just once per windows session.

WiseUser -

File and registry values/versions ARE checked every time you invoke an advertised shortcut, but it's only the key file or registry value for each component. If a component has multiple files / reg keys, only one of them will be checked, the one that is marked as the key. This is actually a great feature and you can use it to your advantage. If nothing in the app should ever change, then every file/reg is placed in its own component, each being the key. If anything changes, the self-repair will change it right back. If you have a file/reg that gets modified or automatically updated, you place them in a component with something that doesn't change, with the static file/regkey as the key. Then the modified files are never checked and will only be returned to their original state in a full repair or if self repair is kicked in because the static file/regkey for that component is altered.

I'm sorry VikingLoki, but I must disagree!

Windows installer stores basic component information in the registry, but not enough information to perform the checks that you claim it does. To do this, it requires access to the locally cached MSI - if not the source itself. Accessing this everytime would be too time consuming.

If an unversionned file (with no MsiFileHash table entry) was a keypath of a component belonging to a feature having an advertised entry point, the original source would be required every time an entry point advertising that feature was invoked - whether a component was broken or not!

Try this:

Create an MSI with a single feature and two components. Put an executable of your choice with an advertised shortcut in the first component, and a registry key of your choice in the second. Install your MSI, and perform the following tests:

1) Invoke your shortcut to ensure it works - it should not repair more than once.
2) Delete your registry key and invoke the shortcut again - a repair will take place.
3) Invoke your shortcut to ensure it has been fixed - it should not repair.
4) Change the value of your registry key and invoke the shortcut again - nothing.

Unfortunately I'm a bit too busy to test that out, but I think I might stand corrected on the registry key change now that I think about it. File change, definitely. Registry missing, definitely. Registry change? Yeah, you might be right that self heal isn't kicked in on that.

I'll have to play with that once I get everyone off my back. :-)

Hey VikingLoki, I respect you for coming back and admitting you might be wrong about the registry thing! [;)]

But, I'm still insisting on the file version thing too![:D]

The "Runtime Resource Resiliency" only checks for the existence of the keypath (file or registry), not the value or the version. The file versions would only be checked if a broken component (missing keypath) was found and a repair was initiated.

Unfortunately, this doesn't seem to be documented anywhere? The closest I can find is the following link:

http://www.microsoft.com/technet/prodtechnol/windows2000pro/evaluate/featfunc/wispro.mspx

Does anyone out there know where this stuff might be documented?

Hmmm. I'm looking at the documentation, they ALL say that self repair initiates if a keypath resource is "missing or corrupted". Well, what exactly does "corrupted" mean? Now I'm not sure if it means what I thought it meant.

I know I've seen packages fight, where both keep initiating self repairs to "fix" what the other "broke". What exactly must each do to the other to qualify as "corrupted"? (or were they deleting the other's files? Nah, why would that happen?) Now I wish I still had those dueling packages to find out exactly what they were doing to each other!