App installing to userprofile
Posted 15 July 2005 - 18:49
I have an app which installs to C:\Documents and Settings\%userprofile%\Application Data
AllUsers property is 1 for this app and it installs and works fine for an administrator. This app has no shorcuts. Its a plug-in. User cannot install this app because Allusers=1 and when an adminstrator installs this, all the files get copied to Adminstrator profile in the C:\Documents and Settings and regular users wont have access to this folder (of course). How can I handle this problem.
Posted 16 July 2005 - 15:41
Posted 18 July 2005 - 14:50
Any other suggestions?
Posted 09 September 2005 - 17:13
I have added user data files (a user dictionary in my case) to the user's application data folder by putting it in AppDataFolder.
This seems to work and the files are copied into a new user's appdata (e.g. C:\Documents and Settings\SomeUser\Application Data\CompanyName\) when the program is first lauched by that user.
But... I am a using the Visual Studio Intaller and it gives me a warning about this. Specifially it says: "WARNING: File should not be installed into a User's Profile folder because it may not be available to all users."
Also, it appears to require that the msi package be available at the time the new user first runs the program.
So ... I guess that I am doing this incorrectly but I cannot see another way to do it.
It that the correct way to get user data into that folder?
Should such a file be placed somewhere else?
Is it normal to require that the msi package be available when each user first launches? That seems like it could cause problems. It also seems to need the package during unistall (although that may be a side effect of something else) which could really cause problems for customers who may move or delete the package.
Any suggestions or advice on this would be greatly appreciated.
Posted 10 September 2005 - 09:47
I base this opinion on the fact that userprofile files are:
...difficult to update
...difficult to uninstall
...very difficult to patch
...may cause unexpected self-repair operations
...very often can be installed as shared appdata rather than per user data
As to your questions: yes, the MSI must be either cached on the system or available on a network share for the file copy to run correctly per user using MSI self repair.
The UserData folder contains all the data that you want to add to the user profile. The App.exe file copies the files in UserData to each userprofile on launch, and then sets a flag in HKCU to indicate that the copy was already performed. You can patch these UserData files in your next setup since they are read-only reference files. You could then also update App.exe to copy updated files to the user profile if need be.
Posted 12 September 2005 - 15:29
The idea of copying to the user profile on each user's first launch sounds like a good way to do it.
I wonder though, how it should be removed on unsintall. Is the usual way to use a custom Action (is that even possible?)or is it acceptable to just leave data there. I my case, the user dictionaries contain a predefined list and so may never be changed. But if they user wants to add a word they will be changed.
Also, in the case of .hlp files, ideally I would like to place the .hlp, .cnt and a zero length .gid in the application's common user data so they can all be removed on uninstall but my understanding of the common user data is that only the owner of a file can write to it. So, I think that a user may not be able to generate the .gid file (depending on who launched the help search first) but it does not seem sensible to copy all the help files to each users data folder. Do have any thoughts about that?
Posted 13 September 2005 - 04:30
As to the help file: I would install it to %ProgramFiles%, the reason being that many application executables bind directly to the help file file name and F1 might not work unless the help file and the exe are in the same folder. I think Windows XP may have a feature to allow the creation of the .gid file even if the user does not have write access to the folder in question.
My rules of thumb for deployment are:
* If it can be set read-only and things still work it is not user data - install to program files
* Any executable goes to %ProgramFiles% (EXE, DLL, OCX, etc... NO exceptions). If there are executables in the userprofile the application design is wrong in my opinion, but many plugins require this
* If it is user data that should not be uninstalled, but does not need to be changed (templates etc..), install to shared app data
* If it is user data that needs to be changed by the user, install to %ProgramFiles%\Userdata and copy to user profile on launch (beware of roaming profiles vs local profiles in this scenario - the copy may need to happen several times if the user logs into multiple machines with local profiles)
Just my subjective opinions.
Posted 15 September 2005 - 05:18