Software Deployment

As far as I understand it the only time a child feature would be repaired is in this scenario

FEATURE1
FEATURE2
FEATURE3

entry point is activated in FEATURE2, self healing checks keypaths in FEATURE2 if one is missing a repair will repair FEATURE2 and FEATURE1 not FEATURE3.
But if there are no problems with FEATURE2 self healing moves to check FEATURE1. If there are keypaths missing here then a repair of all features is actioned.

So in your scenario it's a bit of an odd one. is the structure of your msi definately

HKCU FEATURE
FILE FEATURE

Check if the remote Installation option for the Features is Favor Local.I guess it will resolve it.

timmsie - There are only two features, the files are in the child and the HKCU registry entries are in the parent.

shweta_kar - I can't find the "remote Installation option" that you mention, but when I highlight the feature and click details, the "Attributes" field is set to "Favor Local" (instead of Favor Parent or Favor Source).



I am starting to wonder if it is supposed to work the way everyone says it does. I have created a very basic test MSI file with a parent feature with just one HKCU registry entry and a child feature with one component that has cmd.exe plus a few other non-key files. If I install it, and delete the HKCU entry, it repairs both features.
Here is the test MSI file that I built if anyone wants to examine it: http://cid-2c61a21e0f4ff27b.skydrive.live.com/self.aspx/.Public/test.MSI

But if there are no problems with FEATURE2 self healing moves to check FEATURE1. If there are keypaths missing here then a repair of all features is actioned.

If you think about it it's doing what I said it should above. Your entry point is in the child feature so that gets checked with no problems in it. Then the parent feature gets checked and there is a problem so the whole package gets repaired.

Which begs the question how does the current user feature ever work!!! I'm sure I've used it in the past too....

Where's John McFayden when you need him!

I can't find the "remote Installation option"Ignore that. I have no idea how he thinks that might help in a repair/self-heal situation.

This may fly in the face of years of MSI packaging but.......John McFayden was wrong.

I know that's like saying Adam Smith was wrong, but my testing indicates that if the parent feature needs a repair, the child feature gets repaired too. Also if the child feature needs repair and the parent does not, only the child feature gets repaired. So the HKCU entries need to be in the child feature. This also means the advertised shortcuts need to be in the child feature, along with the files they point to. The rest of the components would go in the parent feature.

It would be great if someone else can verify my findings so I don't feel so alone...[sm=rolleyes.gif]

I think the problem you're having may have to do with the advertised entry point you're using. Just off the top of my head, it makes sense that, if the advertised shortcut you're using points to a file (presumably in the child feature,) then the entry point will check both the child and the parent features for errors, because it comes from the child. Have you tried moving your executable and resulting advertised shortcut to the parent feature?

John McFayden was wrong.I don't know him, but I *do* know John McFadyen. From what I know of this John, I can't imagine he'd go to print (as it were) without having conducted exhaustive testing. Email him and ask: john.mcfadyen@gmail.com.

I think the problem you're having may have to do with the advertised entry point you're using. Just off the top of my head, it makes sense that, if the advertised shortcut you're using points to a file (presumably in the child feature,) then the entry point will check both the child and the parent features for errors, because it comes from the child. Have you tried moving your executable and resulting advertised shortcut to the parent feature?

The issue is not whether both the child and parent features get checked, the issue is whether both get repaired. If I move the shortcut to the parent feature, then no child feature checking will occur. The goal is to check both the files feature and the HKCU feature, and repair only the HKCU feature if only that feature needs it (like when a new user logs on).

I don't know him, but I *do* know John McFadyen. From what I know of this John, I can't imagine he'd go to print (as it were) without having conducted exhaustive testing. Email him and ask: john.mcfadyen@gmail.com.


I stand corrected, and so does timmsie (because I copied and pasted from his message [:D]). And I fully agree with your other point about exhastive testing (thus the Adam Smith reference), but my testing shows the exact opposite and so I want to resolve it. I'll send John an email with this thread.

The goal is to check both the files feature and the HKCU feature, and repair only the HKCU feature if only that feature needs it (like when a new user logs on).

You're saying two things here. It seems that you want the MSI to check the files feature, but not do anything about it if there are files missing? It seems to me then that you don't want the files feature checked at all.

You're saying two things here. It seems that you want the MSI to check the files feature, but not do anything about it if there are files missing? It seems to me then that you don't want the files feature checked at all.

Not true. Re-read what I posted. I want the MSI to check both features and if the HKCU feature needs repair but the files feature does not need repair, then repair ONLY the HKCU feature. Obviously if the files feature needs repair, I want it to repair that feature as well.

Hi Bob,

John is correct.

When the entrypoint in your child-feature is triggered the Windows Installer Resiliency feature (self-healing) checks to see if any component is broken in the child-feature (the same feature as the entry-point). If no is found broken the check goes up in the feature ladder (in your case the parent-feature) to once again check for any broken components. As it finds one for the component holding the HKCU entry a repair will be triggered and check each (all) feature again for broken components however; Component level healing is being performed.

That's what I said, so if that's the case, which it is. How does the HKCU top level feature work in only repairing that feature and not the rest of the msi.

The only way it would work would be to add all your entry points to the HKCU feature too

Hi Richard,

If a component is found broken in the same feature as the entry-point (that was triggered) a Feature level healing is in place which "repair" all components weither they are broken or not. For a Component level healing only broken components are repaired.

In some cases "non-broken" components are repaired, ex.
when the MsiFileHash entry is missing for non-versioned files
the version in the file is not proper set
user-profile files are set as keypaths

Only a verbose log would tell what's going on if non-broken components are repaired.

When the entrypoint in your child-feature is triggered the Windows Installer Resiliency feature (self-healing) checks to see if any component is broken in the child-feature (the same feature as the entry-point). If no is found broken the check goes up in the feature ladder (in your case the parent-feature) to once again check for any broken components. As it finds one for the component holding the HKCU entry a repair will be triggered and check each (all) feature again for broken components however; Component level healing is being performed.
Hi Kim,

I disagree with your last statement about Component level healing being performed on the child feature if a component in the parent feature is broken. The evidence based on my testing below indicates that feature level healing is being performed.

Here are my actual tests:

First package (following John's recommendations)
-HKCU entries in the parent, all in a single component, all other components including entry points in the child.
-Install MSI and click on advertised shortcut. Application launches without healing (as expected)
-Delete a non-keypath file. Click on advertised shortcut and application launches without healing (as expected since it only checks keypaths in components)
-Delete the keypath HKCU registry entry. Click on advertised shortcut and self-healing begins; the HKCU component is restored and the component containing the deleted file is restored (this indicates that it healed both features which is not desired)
-Event viewer shows detection of child feature failed and detection of parent feature failed

Second package
-HKCU entries and entry points in the child feature; all other components in the parent.
-Install MSI and application launches fine
-Delete a non-keypath file. Click on advertised shortcut and application launches without healing (as expected since it only checks keypaths in components)
-Delete the keypath HKCU registry entry. Click on advertised shortcut and self-healing begins; only the HKCU component is restored (this indicates only the child feature was healed, which is the goal)
-Event viewer shows detection of child feature failed, but no mention of parent feature
-Delete a non-entry point keypath file (a parent feature component). Click on advertised shortcut and self-healing begins; the keypath file is restored (as expected and desired).
-Event viewer shows detection of child feature failed and detection of parent feature failed.

Based on this testing, I maintain that the HKCU entries should go in the child feature, not the parent feature, which is the opposite of what John recommends.

so the good news is i just spent half an hour responding to this post and lost the lot due to timeout on the page. (yaay)

as I is now pretty late for me I will make this version real short. I will try to rewrite what i did earlier tomorrow. (sorry need to sleep sometime)

general deal is this

Complete
Feature 1
Feature 2 (default wise setup should work for you as desired)

HKCU
Main is what I used to use with IS setups as IS dumps all captures into a single feature (not great for Feature level / component level stuff)

You can use HKCU low in features but it doesnt scale well when you have multiple entry points in multiple features which is why I prefer to put it at the top. It does work but only in some occassions, where as I found the other way works regardless of the entry point used (something that is hard to determine when a user can access an app in multiple different ways using multiple different entry points.

I wrote this babble to work on Windows installer 2.0 as the text was written about 4-5 years ago. Things may of changed although in this case I doubt it very much.

I dont have orca on hand at home (I don't do much with manual packaging these days) mainly all automated packaging i.e. (wix) so I don't use much in the way of editors like wise etc as such I can't even test your config atm nor make too much comment.

I will check it out tomorrow and make some comments. I did find dodgy component codes could cause all this to go right out the window and perform really weird. And you were right BoB feature level one first feature and component level on all parents.

You may find that as the initial feature was at feature level it may be by design to work like this although I don't recall my testing to of worked like this. Using the Wise default structure would work around that I believe.

I will ask Caroline what her take is on this situation, she wrote most of this functionality I think so she would be the best person to tell you the design intention.

My apologies to write on this old thread..but after reading till last post I am wondering why Jhon didn't come back & confirm on same[:-]!!

probably cos he was too lazy.

you can do this both ways top or bottom feature. the purpose of the top feature was to ensure it was actioned regardless of entry points used by the end user.

it works the other way around however you need to ensure the HKCU appropriate for the triggered feature is in the entry point feature. (this requires more thought)

the intention of the original articale was to be generic for as many uses as possible. It was also written on windows installer 2.0 which was 8 or so years ago. the technology has moved on considerably since I wrote the article neither I nor anyone else I know has tested it thoroughly against windows installer 3.0 4.0 4.5 or 5.0.

you may find things are the same they may also be very different.

as for testing it again sure I will do it if someone wants to front up with some cash for me to do so. in reality i don't think anyone really cares that much this is pretty trivial for anyone with a few clues about them.

Thank you for update.