Software Deployment

Hi,

I gone through your entire issue.I think the main problem is your feature struture.You have create a main feature which is doing a user based installation and machine based feature is kept as a child feature.
I will suggest you since you want a User Feature and a Machine level feature make it into two different feature,dont make it as a child feature.Also I will suggest you move the component which have shortcut to User level Feature.Try this it can help you.

Regards,
anks_09

Thanks for the quick response.

I have tried what you said. I have moved the COMPLETE feature to to the root, and made my SBClient component a member of my CURRENTUSER feature. It now looks like this:

CURRENTUSER Feature
---->CurrentUser Component
---->SBClient Component
COMPLETE Feature (No Parent)
---------->All other components

When ran as the user, the event log shows the same thing, except now the component has moved to the CURRENTUSER feature:

Detection of product '{B404DA78-5837-4D6C-8859-29DC47C56C5A}', feature 'CurrentUser' failed during request for component '{E1F2B76D-8CA3-49E4-9510-EBD0ACED8ED4}'

Any ideas?

Go back to the original config:

CurrentUser (Parent Feature)
---->CurrentUser Component (Only HKCU reg keys)
---->Complete Feature
--------->All other components including advertised shortcut to app (No HKCU stuff)

Now make sure you do not have any empty features or components. Make sure you look for errors in your tables(F4). Scroll through your components tab, see if any are empty. Now recompile & test.

Thanks kiptek.

Tried what you have suggested, put the app back to the original config, made sure my advertised shortcuts are in the COMPLETE feature, but still the same issue:

Detection of product '{B404DA78-5837-4D6C-8859-29DC47C56C5A}', feature 'Complete' failed during request for component '{E1F2B76D-8CA3-49E4-9510-EBD0ACED8ED4}'

I did have 1 empty component which I have now deleted, but the app as logged above is trying to repair the COMPLETE feature again, rather than just the CURRENTUSER feature, but still no luck

any ideas?

This seems correct.

When the "user profile-fix" occurs the repair is done at Component level, meaning the actual resiliency check. If a component is found broken; in your case the CurrentUser component, the feature-tree will be checked again and any broken component will get repaired.

The event ID 1001 tells you which entrypoint that triggered the resiliency check:
Detection of product '<Property.ProductCode>', feature '<Feature.Feature>' failed during request for component '<Component.ComponentId>'

The event ID 1004 which component that was found broken:
Detection of product '<Property.ProductCode>', feature '<Feature.Feature>', component '<Component.ComponentId>' failed. The resource '<Component.KeyPath> OR <Component.Directory_ for empty KeyPath column>' does not exist.

{E1F2B76D-8CA3-49E4-9510-EBD0ACED8ED4}
Search the components table for this GUID and find out what component has a problem. Once you find it, it should give you an inclination of what is wrong as it looks like a different GUID from what you reported earlier.

This component is my SBClient component as mentioned earlier in the post. This component is installed correctly, and it contains my advertised shortcuts. As it is installed correctly I thought self repair would have left this component intact, and just repaired the currentuser component. (The currentuser component is the only component that's keypath does not exist, therefore i would have expected the app to only try to repair this single component.

As the event log error is saying, it is actually trying to repair my SBClient component and I am trying to understand why, when this is installed correctly.

Hi,

I am experiencing the exact same issue:

I have a Package with this set up:

CurrentUser (Feature) - Contains Current User Components
MainProduct (Feature) Contains all the other comps.

My Shortcuts and main program exe are in a componenet in the MainProducts Feature and when checking the event log it is this component kicking off the self repair despite the main program exe being intact as expected in the key path.

I've created a new component and copied each object into it and noted that the component initiating the self repair changed to the new one as I moved the main program exe (as keypath) across.

Very Strange!

Beefy, did you get any where nearer an answer?

Try doing it the otherway:

Machine (Parent Feature)
[blockquote]User (Child Feature)

[/blockquote]Ill explain why if you want :)

Paul,

As the feature structure (user parent, machine child) is to to minimize the time the resiliency check takes it would be interesting to hear your version why to revert the features.

Inabus,

I'll test as you suggest, but as AngelD so rightly says, my main issue is that this package is rather large (all files extracted is nearly a gig in size) and the pain is that self repair obviously takes an age for each user if the main feature is installed each time a new user launches the app.

Mark,

I don't think you fully understand how the resiliency check works.
It will be done twice if a broken component is found; the first will be quick if the feature tree has the "CurrentUser" feater as parent and "Machine" as child feature. When ever a broken component is found during the initial self-check every feature in the package will be checked again meaning, when a broken component is found in any feature that component will get repaired.

For more info have a look at John's blog entry:
http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!123.entry

/Kim

OK:

Ill give an example:

User (Parent Feature)
Component1 (Advertised Shortcut)
Component2 (HKCU Reg keys)
[blockquote]Machine (Child Feature)
Component3 (Some other exe)

[/blockquote]Now, I install application, it works obvviously however I now delete either Component1 which is the advertised shortcut or, if any other user logged in, Component2 which is the current user registry keys, then the application will self-repair and load however if I delete Component3 and lauch the application then it will fail to repair the deleted Component3, this is the case for any file that I would delete under the Machine feature, in the above example. Of course if a file I delete is initiated from another entry point, like an extension, then self-repair can work, it just wont work from a shortcut in the User feature.

It all depends on what your after to be honest, by having the feature layout as described above I agree that you dont get the entire application "checked" when a new user logs in, but is it worth loosing normal self-repair across your entire application????

1) Entry point is invoked. Entry points are tied to key paths. For instance, a shortcut may be tied to an EXE which is a key path.

2) Windows Installer checks all key paths in components under the "entry point" feature, as well as components in that features's parent, and that features parent, all the way to the top feature.

3) Are any key paths in the entry point feature or its parents missing or corrupted?
[blockquote]No
[blockquote]Application opens
[/blockquote]Yes
[blockquote]Windows Installer checks all key paths in entire application

The original "entry point" feature with broken key paths geta a feature-level repair (entire featire is reinstalled, not just broken component)

If broken key paths are found elsewhere in application, each component with a broken key path gets a component-level repair (component only is repaired)

[/blockquote][/blockquote]The above is an overview of MSI self-repair, I copied it from a doc I have next to my PC here, so it may have typo's and is also a flowchart which i cant document :)

Regards,
paul

Kim,

Thanks for that! I will move my shortcuts and application exe to the top (Current User) feature!

Kind Regards,

Mark.

ORIGINAL: wynnem

Kim,

Thanks for that! I will move my shortcuts and application exe to the top (Current User) feature!

Kind Regards,

Mark.

I wouldn't do that.
Just have the user part in the "top" feature and add everything else in the "child" feature.

User (Parent Feature)
Component1 (Advertised Shortcut)
Component2 (HKCU Reg keys)


Inabus, generally you would keep the entry points as deep in the feature structure as possible.

If you take this as an example

HKCU Feature
HKCU Component

Word Feature
Word Component + entry point
Excel Feature
Excel Component + entry point

You cannot easily predict which of word / excel the user will run, therefore putting the HKCU at the top of the tree allows either the word or excel entry points to be executed and maintaining the HKCU heal.

moving the HKCU down into the features as you discussed is dependant on specific entry points being run to ensure HKCU is deployed

Your method would work only in the instance your HKCU was split into Word / Excel components and each HKCU item was moved to the appropriate feature.


Word Feature
Word Component + entry point
Word Component + word specific HKCU
Excel Feature
Excel Component + entry point
Excel Component + excel specific HKCU