Windows Installer 3.1 -Need to install for every user

Question

there

I have a installer done by Windows installer project. The issue is: when I finished the installation by a windows user, the target application works well under this user. But When I login by another user, it prompt to install the application again.

My expectation is: I don't want it prompt to install again and could use directly.

I try to editing the registry part of the installer project, move the key from "HKEY_CURRENT_USER" to "HKEY_USERS", it does not work, in the destination computer's registry, the key still be in "HKEY_Current_user", I doubt the root cause regardless with registry. And I don't know why the modification of registry does not work.

Answer 1

Thanks all for your kindly help, I just get some idea from https://blogs.flexera.com/installtalk/2011/02/you-again-understanding-windows-installer-msi-self-repair/

" cause is that the application was launched by an advertised shortcut ", so I change "Always to create shortcut" to false in properties of the installer project. The problem resolved.

Answer 2

Although the issue might be a "repair", in some cases it does not mean that the install is broken, and that's because this behavior is used to supply files and registry items to users that have not yet used the app.

One obvious cause is installing a file to a user profile location, such as MSI's standard folder property names like AppDataFolder (the full path to the Roaming folder for the current user), or PersonalFolder, or some others. In these cases there is a file in AppDataFolder for the installing user but NOT for another user who logs on later. Presumably the app requires the file for all users of the app, so Windows Installer "repairs" the app by installing the file, requiring the original MSI. The same idea applies to HKCU registry entries which will be missing for a different user, but two remarks about your registry comment:

1. HKEY_CURRENT_USER is possibly the same as HKEY_USERS, since HKCU is simply the HKEY_USERS registry hive for the current logged on user. Changing from one to the other won't necessarily fix anything

2. It is not likely that the cause of the repair is a missing registry entry because registry entries are repaired from the locally cached MSI file, but missing files require the original MSI file. However, you said that you got the dialog about configuring the product but you did not say if it required the original MSI. If the original MSI is not available (or you hide it), and if the dialog requires a file it will ask for the MSI. If the MSI is hidden, and the dialog flashes up briefly then it's a missing HKCU registry entry.

Answer 3

Self-repair, the scourge of society: There is so much to self-repair, I have written about it many times, but in essence it is about a component key path being missing (or broken), and Windows Installer trying to correct the situation by installing the missing component. If your component has a HKCU key path, then it will be installed for every user on application launch (via an advertised shortcut) - since every user's HKCU is different the resource must exist for each user. When Windows Installer runs to put this user-specific resource in place we refer to this as self-repair. Self-repair is also a generic mechanism to check that an application is properly installed in general (it is not just for user specific resources). Here is a very short, but more elaborate explanation of self-repair.

Find the culprit: It sounds like you know what component is triggering the self-repair. If you don't you can locate it using this procedure.

Resolving the problem: It is difficult to provide a generic fix for all situations. Very often you can remove the whole resource, for example if it is a HKCU registry key, you just remove it from the setup and your application can add it as a default value on first launch. This is not always possible - some applications cause all kinds of drama if default registry keys are missing (which shows a badly designed application - any application should write all user configuration defaults on launch), and in those cases I use either self-repair (effectively so it only runs once), or Active Setup - which is a Microsoft feature allowing "something runnable" to run once. See link for more technical details.

User-specific data and settings: Here is a piece on the distribution of user-profile files and registry settings - and how it has always been problematic. And some suggestions on how to deal with it. Not great, but should be worth a read: Create folder and file on Current user profile, from Admin Profile

Maybe provide some more technical details on what the resource really is, what the path in the registry is, what type of application it is, etc...

---

On the origin of self-repair: For your reference, here are some links with more information about self-repair than any sane person can digest :-):

1. Self-repair - explained.
2. Self-repair - finding real-world solutions.
3. Self-repair - how to avoid it in your own package.

Some further links:

• How do I distribute HKEY_CURRENT_USER (HKCU) keys to any user using self-repair?