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\thumbindex.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
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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
Answered 04/15/2009 by: zipsantro
Purple Belt

Please log in to comment
0
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".
Answered 04/15/2009 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 04/15/2009 by: MikeRae1980
Senior Yellow Belt

Please log in to comment
0
......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'?
Answered 04/15/2009 by: VBScab
Red Belt

Please log in to comment
0
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
Answered 04/15/2009 by: Cybermage
Orange Belt

Please log in to comment
0
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?
Answered 04/28/2009 by: MikeRae1980
Senior Yellow Belt

Please log in to comment
0
Using Roaming Profiles?
In that case no, Active Setup would also be roamed if not explicit excluded.
Answered 04/28/2009 by: AngelD
Red Belt

Please log in to comment
0
yes using roaming profiles
Answered 04/28/2009 by: MikeRae1980
Senior Yellow Belt

Please log in to comment
0
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
Answered 04/28/2009 by: jcarri06
Senior Purple Belt

Please log in to comment
0
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.
Answered 04/28/2009 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
0
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>"
Answered 04/28/2009 by: AngelD
Red Belt

Please log in to comment
0
Fantastic idea!

I'll give it a try, i'll update you with my results. That sounds really promising though thanks again!
Answered 04/29/2009 by: MikeRae1980
Senior Yellow Belt

Please log in to comment
0
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.
Answered 04/29/2009 by: AngelD
Red Belt

Please log in to comment
0
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]
Answered 04/29/2009 by: MikeRae1980
Senior Yellow Belt

Please log in to comment
0
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
Answered 04/29/2009 by: jcarri06
Senior Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity