MSI Self repair only works for installer.

Question

Hi Gents
  
 I'm trying to re-package Picasa3 and all seems to be going well apart from one problem.  When you load the application for the first time it asks what drives you want to scan, after telling the application it goes and places a file in the c:\Documents and settungs\USERPROFILE\local settings\application data\Google\picasa2\db3	humbindex.db(along with other files but this is the important one)
  
 This file has the settings of the drive and therefore doesn't flash up at the start asking any questions.  I would like this file to be dropped into each users local profile as they log on.  I decided to create a UserProfile feature in Wisepackage Studio with the files I needed so when the application was run for the first time it would see these files were missing and do a quick self repair, placing the files needed into the appropriate place thus resolving the problem I have!   
  
 Unfortunately this only works for whoever installs the MSI!  Any new users log in don't get any relf repair and are presented with the original problem.
  
  If I need to I'll try the active setup method but don't see any reason why this shouldn't work.
  
 Any help on this process would be much appreciated as im fairly new to this method.  
  
 Mike R

Answer

hmm maybe not Jonny, maybe not :)

"HKCU\Software\Classes" is excluded by default so anything written under this key will not travel along with the user.

So if everything fails then create a dummy entry alike the below, not maybe the best suggestion but the only thing that comes in mind.
"HKCU\Software\Classes\Software\RepairOnEntryPointPerLogonSession\<ComponentId>=<ProductCode>"

Answer

Fantastic idea!  
  
 I'll give it a try, i'll update you with my results. That sounds really promising though thanks again!

Answer

ORIGINAL:  jmcfadyen
 
 to all the people that have suggested making the file the keypath this is a bad move. It will result in permissioning errors etc as the initial files path will be written to the keypath. this will cause all users to look for that file during self healing (most users wont have access) ..
 
 Yes, it's a bad move to have a file as keypath for user-based files (components) as any admin user will have permission to read the keypath file installed to another user's profile therefore the component will not be found as broken due to read/write access.
 
 Regarding self-healing for such component:
 The Windows Installer metadata (registry) pointing to the filepath will point to the path for latest user's (keypath) filepath whom triggered a repair.
 So the keypath metadata will be changed during each repair; swapping back and forward between next-user, next-user, potential previous-user and so on.
 
 There are some other issues having a file as keypath but the issue here will be a repair for non-admin users and no repair for admin users.

Answer

Ha!!  That worked a treat AngelD, thanks a lot M8, thats been a real head scratcher for 2 weeks.  I hope this post comes in handy for other people with the same issue.
  
 Thanks again
  
 Mike [:D]

Answer

ORIGINAL:  AngelD
 ORIGINAL:  jmcfadyen
 to all the people that have suggested making the file the keypath this is a bad move. It will result in permissioning errors etc as the initial files path will be written to the keypath. this will cause all users to look for that file during self healing (most users wont have access) ..
 There are some other issues having a file as keypath but the issue here will be a repair for non-admin users and no repair for admin users.

Told ya I'd get some heat :) lol.  Thx for clarifying guys and glad you're up and running Mike.
 
 - J

Answer

This issue can be dependent on what installation type(per-user or a per-machine) you have selected. 
 Please verify ALLUSERS property and go through this link for reference.
 
 http://msdn.microsoft.com/en-us/library/aa367559(VS.85).aspx
 
 Jeeoo!
 Santro

Answer

When you view your transform in 'Installation Expert' view, where in the structure are your additional files? They should be in "[WindowsFolder]\Profiles\Local Settings\Application Data\Google\Picasa2\db3".

Answer

When installing the MSI it does ask if I want to make this app for all users, I say yes :)
  
 Yes i'm creating this folder structure in Windows\Profiles\Local settings etc.
  
 It does go to the correct forder because when I install the application it puts the file into my local UserProfile.  Just not when other people log into the station.

Answer

......sssssssssssssooo.....you want files to go into a local profile, but you select 'All users' when installing. What happens when you select 'Only for me'?

Answer

Even then it is not a big problem.
 Move the required files to the profile map of the userprofile folder in the packaging tool.
 Make from the moved files a keypath in de components.
 Do not forget the active setup key.
 
 For more information maybe this treat wil be a great help.
 http://itninja.com/question/gnu,-freeware-and-shareware-programs-to-cloning4997

Answer

Hi Gents,
  
 Got the self healing part working by placing a reg file into the HKCU and placing the files into a new feature that then triggers the healing process.  The only problem now is when the user logs onto another station that reg key now exists so the self healing doesn't fire off.  So back to the original issue.
  
 Any ideas how to get round this so every station they go to will recognise the files are not in place.
  
 Woudl active setup help?

Answer

Using Roaming Profiles?
 In that case no, Active Setup would also be roamed if not explicit excluded.

Answer

yes using roaming profiles

Answer

I'll probably get some *heat* for this since it goes against packaging standards and will fail validation...but due to your roaming profiles it may be your only way to go.  Using the same feature structure you have to trigger self heal, make the keypath the file you're looking to replace instead of the registry.
 
 You're in a bit of a predicament...You have a user specific file that needs to be created to run the application, you have users log on to different machines, and your profiles roam...you should toss a gasoline case with a lit match just to make it more interesting! lol.
 
 Good luck,
 
 - Jay

Answer

to all the people that have suggested making the file the keypath this is a bad move. It will result in permissioning errors etc as the initial files path will be written to the keypath. this will cause all users to look for that file during self healing (most users wont have access) ..
  
 you may need to resort to some custom scripts to call the API to trigger a specific set of actions from HKLM or deploy with login script other separate method.