Software Deployment

so many people get this wrong don't be disillusioned.

I usually give the answer but never explain the reason behind all this. today I feel like helping so heres the deal.

if you have a keypath as a file when the component gets registered and the path to the keypath is written to the registry at the following location

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\<component code>

so by having a file in the profile this key would contain something like

c:\documents and settings\administrator\appdata\myFile.txt

the issue being that from a self healing perspective when the healing process is checked it looks up these keys finds the keypath checks the path listed (in your case if the user doesnt have access to another users profile) you run into issues.

By changing the keypath from the file to the HKCU that key now contains HKCU\software\test = xxx which all users will have access to.

Re your comment about how healing works the entire feature only gets in the feature that contains the entry point in question. All other features only get healed at component level (ie single component) except when another feature is broken.

I would suggest you check out my blog on self healing

http://johnmcfadyen.spaces.live.com somewhere in there is a self heal blurb.

Have you set a HKCU registry entry as the keypath for the component holding the file(s)?
Is the AppDataFolder used as the components directory?

Hi Bob,
the Userprofile, "Local Settings" and Appdata directories are not part of the user shell folders which are automatically enumerated by Windows Installer. You need to create those directories by yourself.

Otherwise, the absolute path to the source directory in the profile, which where active during the build of the package, is used.

If you use Wise, the "ProfilesFolder" is already set by a custom action.

If not, you have to set a custom action, which creates the Userprofile directory.
Something like this:
Set_CurrentUserFolder 51 CurrentUserFolder [%USERPROFILE]\

And call it between the CostInitialize and CostFinalize actions in the InstallExecute- and InstallUISequence.

Regards, Nick

Hi,

First i have to say that am using Wise 6

I've verified what was posted and suggestions and it still not working.
I don't understand why it behaves like this.

AngelD
The file itslef is set as Keypath, not a reg key
The directory of the component is a folder from which parent is LocalAppDataFolder, which parent was set to TargetDir. I changed this parent to PROFILES, just to try. Didn't work

nheim
You are saying:
Otherwise, the absolute path to the source directory in the profile, which where active during the build of the package, is used.

This seems to be exactly what is happening. I use Wise. I've try your suggestions, not working. Can you elaborate a little bit? Why wise is not doing this alone?

I've try your custom action too, not working.
I've also try to remove the file and creates the directory structure myself. Didn't work.

The application is installed by an admin
When a user logs, repair launches. Looking at the event folder reveals that MSI did not found the file under the ADMIN LocalAppDataFolder. He can't find it because he has no right on this folder. MSI is not even looking at the current profil.

I have no clue, anyone has?

I appreciate your help,

In your component that you have the file installing in. Set a registry key (HKCU) as the keypath instead of one of the files.

When the user then launches the software it will see that the key is not there and then re-install everything within that component/feature.

MIchael, thansk for the suggestion but:

There is already something that triggers the self-heal because there are missing HKCU keys. In my understanding of self healing, the entire feature is getting healed if something is missing in any component right? In this case, HKCU keys is missing, every components in the feature should also get healed . So i would expect this file in LocalAppDataFolder which is in another component to get also healed but it"s not. Instead I received an entry in the Event Viewer stating that the file in admin\Local settings\Application Data\AppName is missing.

Do you still suggest I try to create a HKCU dummy key and set it as Keypath in the component where I have a file in Local Settings\Appdata folder?

P.S.: I am about to give user permission to this admin LocalSettings.... folder, file and move on to other things but this is not the first time I am having this issue and I would like to understand what is going wrong once and for all.

Thks,
Bob

If you choose to use a HKCU as the keypath the AppDataFolder should resolve just find during repair.
The problem with having a file located under a user's profile folder is that for admin users the component will not be found as broken as an admin do have read access to other user's profile folder(s). Also during removal the file(s) in that component for the user whom latest triggered a repair will be removed and not the user who triggered the removal of the package.

At this point I would suggest that you enable Windows Installer Logging and take a look at the log that's being generated when the seaf healing runs. If you can't figure it out from there, post the log on this forum and everyone can take a look at it.

log on this forum and everyone can take a look at it.

I will do this.

Micheal, I did an experiment, I merged the two components together, setting the HKCU key as keypath. When the user launches the app the first time, KU keys gets populated and for the first time, the file is getting installed correctly under the current user profile... BUT.. every times the user launches the app, it keeps trying to repair and always looking under the admin files instead of using the file under his current profile ...weird.

Thanks

Ok, I have this fixed now.

I did what i explained in my last message, I merged the user\Local Setting\Application data files with HKCU keys, setting one reg key as keypath as suggested. This initiates the self healing on user 1st launch and install the reg keys and files in current user Local Settings\App data folder. That was the solution with my issue.

The reason self healing was still initiating was because there was a remaining trace of the former component for the file before I merged both component.

I am still trying to figure out why it was behaving that way. Only reason I may think is that having a file set as keypath when this file is located under LocalAppDataFolder bugs the installer in the way that it will always search in the folder of the user who originally installed the application.

Can't find anything else. If anybody thinks of any other reason, feel free to share.

Thanks to those who helped.

Bob

Glad to hear that you got it working.

I don't suppose you ran validation against your MSI at any point. I think that normally it will give you an error against the component that has only files installed under a user profile stating that it must use a HKCU registry key as it's keypath.

stating that it must use a HKCU registry key as it's keypath

I didn't run any validation.

This keypath thing for files under profile was new to me. Never thought it would create an issue.

Thank you for your help, really apreciated.
Bob

Hi Bob,
glad to see it worked out for you.
What you further could do, is to make the user profile self repairs working independent from availabilty of your package source.
Have a look at this tutorial from John McFadyen:
http://www.appdeploy.com/messageboards/fb.asp?m=7766
I use this technic regularly, to do the profiles stuff.

Regards, Nick

Hi jmcfadyen

Thanks for the useful information. This helps me understand what is exactly happening. It's good to understand instead of simply applying the solution.

I'look at your blog regarding the self healing too.

Good day,
Bob