Just so it is clear: the problem is not the actual installation of userprofile files. This is pretty straight forward:
- Install files to the userprofile folder hierarchy
- Use a HKCU registry keypath for the component (this ensures that each user has a unique keypath set to the file - which is a requirement for Windows Installer).
- Make sure the files are installed when you invoke the application shortcut OR invoked manually via an MSI api call from the application on startup.
However, it is after you deploy your files to the userprofile folders that the real fun begins. There are a lot of open questions. I will discuss userprofile deployment with myself below - this could be entertaining . The point is to make it easy for whoever has a better answer to point out where I am wrong:
Q1: When you install files to the user profile, each user must have access to the original installation image in order to copy all user-specific files to their profile directory. How do you make sure that the original installation image is available when these users invoke the product's shortcut (and self-repair begins)? If the image is not available the user will be asked to browse for the installation image in order to copy necessary files to the userprofile and if they don't have it, the whole install will fail
A1: To make deployment of user specific files work properly, you either have to cache the entire installer on the system, or have the user install from an adimistrative installation image on the network (shared network location). Alternatively you could install all userprofile files to the %PROGRAMFILES% hierarchy and then use the DuplicateFile table to deploy files to the user profile (this might also be the way to go to be able to patch user specific files).
Q2: Once files are deployed per user, how do you patch / update these files for all users?
A2: I see no easy way to have a patch apply to all userprofile files for all users. Two possible solutions would be to deploy these files with a separate "user specific" setup invoked by the application itself on startup (then you could install this MSI package to the %PROGRAMFILES% folder and deliver an updated package for this whole installer and install it again to patch userprofile files), or you could install all user-specific files to %PROGRAMFILES% and then rely on the DuplicateFile action to properly copy the file to the userprofile path.
Q3: How do I uninstall user-specific files from each user profile?
A3: It seems that the best practice here will be to leave all files installed to the userprofile as "permanent components". And then have a custom action in the uninstaller where the user is given the choice of deleting all userprofile files as a unit (the question then becomes how to invoke this custom action for all users - Maybe a custom EXE invoked by runonce would be better). An alternative is to parse all userprofile folders for the folder hierarchy in question and just delete all occurrences (a horrible solution if you ask me).
Q4: How does the file replace rules work for files installed as part of dynamic components? (Installshield specific) A component is said to always be installed / uninstalled as a unit. Does this mean it is impossible to install an update for a single file in a dynamically aquired component?
A4: It is unclear how Installshield's dynamical components affect patching and upgrades. Maybe the file hash table enables the upgrade install to only install files with "recognized" checksums and leave all other (user changed) files? My guess however, is that all dynamically deployed files always will be reinstalled.
Q5: If I would like to install only missing files, but not replace any existing files in the user profile, how can this be specified?
A5: This is related to question 4. I know that you can use the MSI API call MsiReinstallFeature and specify that it should only install missing files. Since this would have to be invoked per-user, the call must probably be done from the main application executable on startup. It is also unclear if this will actually version check each file in the dynamic component, or if it is only checking the keyfile for the component (if any).
Q6: I have a lot of "library" files with my application. These are files delivered by us that the user can change. Is there a way to prevent mixing our "vanilla files" from user changed files? The overall goal is to deploy these files to allow user customization and still make it possible to patch and update the main files.
A6: I have been thinking about deploying the application files we deliver to LocalAppDataFolder, and then have the application copy any changed files to the corresponding AppDataFolder. This way the files we install will not roam with the user (LocalAppDataFolder), and can in principle be patched (since no user specific changes should be made in this folder). The files in the AppDataFolder would roam with the user and hence provide a "transparent experience" for users who can use the same product on different computers and still have access to their customized files. The bad news is that this is all pretty complex to do, and requires changes in both installer and application. Conceptually it is not really clean either.
Comments?
Edited by Glytzhkof, 04 July 2003 - 00:48.