The structure you have created looks OK, as long as you are using a Set Directory custom action to handle any installation to the current user's Documents and Settings folder, as this is often a cause of problems depending on where you are trying to install to precisely.

To diagnose the problem, start up Event Viewer and check the Application Event Log. All missing key paths which cause a repair are reported in the application event log by component GUID, so it becomes quite simple to track down which key paths are missing at repair time. If any of these key paths are in the Complete feature then of course the entire Complete feature will be repaired.

If you enable verbose MSI logging in the registry, you should also find that the repair generates a log file in the TEMP folder and of course a verbose log contains time stamps of each action start and end, so if all else is well, you can quickly check whether any particular action is taking a long time.

One other thing occurs to me. Since your repair is installing some files, what compile options are you using in terms of the internal CAB file size?  If the files needed by your user repair are all in the same CAB as the rest of the install, the process of extracting them will require the entire CAB to be transferred and unpacked into the local temp folder, before the files are able to be installed.  So you may find that specifying a maximum size for your CAB files, or playing with sequence numbers and number of CABS so that the user files are in their own, small, CAB file, will significantly speed up the install.  On the other hand, if you have compiled with external uncompressed files specified, then this will not be an issue, as the required files will just be copied from the source media.

Hope this all makes sense

...if you have the 'Complete' feature as the HKCU child's parent! It's repairing everything in 'Complete', exactly as you've designed it to.

Separate out one component into a new feature, provide it with an advertised entry-point and make this new feature the child's parent.

Guys,

way I understood it was any and all PARENT features of a triggering feature will also be included in the repair process. My advice therefore would be to position your CU feature at the top level, 'next to' your main feature.

This should make repairs triggered from your CU feature ONLY repair the CU settings.

Rgds,

EDIT: I might have misread something here... disregard this post :p. Like EdT said, have a look through the event log to identify the components missing their keypaths.

PJ

It was Friday, I had other things on my mind and I got things about face. The OP has the feature structure correctly configured.

I'll get me coat...

EdT,

I completely agree, which is why I retracted my statements (suffering from MondayMorningitis). Is there a delete button for posts? Cause I couldn't find that ...

Only explanation left therefore is a component in Complete that's triggering a feature repair, so then the eventlog is the best place to start for troubleshooting (on XP that is, I hate the Windows7 eventlog for tracking MSI operations...)

The original poster of a comment can't delete the comment - but you can always edit the content of the comment...

Cheryl

Thanks for you replies and tips, i'm going to work on it today. I will let you hear the result.

Oke guys,

I stlll got my repair problem, the eventviewer shows this:

Detection of product '{A98198EF-49CE-422E-A0A0-40E6433DCE56}', feature 'CurrentUser', component '{68E14B26-CA50-4EF7-B715-25033B334FDC}' failed.  The resource 'C:\WINDOWS\system32\config\systemprofile\Application Data\AspenTech\' does not exist.

Installation is done trough GPO machined based so before the user logs on.
The folder needs to be documents and settings\application data\AspenTech offcours.
The systemprofile folder above is from the elevated installation account i think, and it makes scence he tries to repair it. But he still repairs the whole package instead of only my CurrentUser Feature.

The location quoted in the path is under the System32 folder so cannot be a user profile issue. This location will not have write privileges for a standard user so you need to establish why it is necessary, and if it is not necessary, or the path is resolving incorrectly during a GPO install, then you need to apply a condition to this component to prevent installation during a GPO install (or perhaps during the first time install)

I would recommend Installed

This is not true for a first time install, but is always true thereafter.

Just a note: use a hkcu reg entry as keypath instead of a file in the profile

Need your help again guys.

I have the components in de CU feature now that they are not installed during the first install (Complete= Installed) condition.

There is no advertised entry point in this feature to the shortuct..It is the parent feature of the complete feature. What is best way to trigger a repair now for the CU feature. If i got this i'm close to the peferct solution.

Thanks again.

If you read back over my previous posting, you will see that the repair process in the parent USER feature is triggered by any advertised entry point in any child feature,  because key path checking starts at the feature where the advertised entry point was triggered, and moves UP the feature tree to include any parent feature(s) regardless of whether they have an advertised entry point or not. Just make sure that you follow AngelD's advice and specify a registry key in HKCU as a key path to the component requiring repair in the user feature. Note also that registry key path checking is based on the EXISTENCE of the registry key and NOT the content of the key.

You expect people to read your responses. Got it.

The folder path  windows\system32\config\systemprofile  is incorrect if I understand your previous postings correctly. If my understanding is correct, then it would appear that you need to add a "Set Directory" custom action to define the correct target folder for the user files, most likely by referencing the appropriate environment variable as part of the path.

[!EnvironmentVariable] is the correct syntax in case you are not already aware.