Making an application write to HKCU or HKLM depending on the ALLUSERS value (per user or per machine install) sounds good in theory, but in practice I have never used this approach. Note that what I write below is rather subjective based on concrete experience.
The general idea of a per user install is for people to be able to have their application and license only available to themselves, but also to support different language installations, and versions and stuff like that. Very few applications venture into this realm of usability without making it an integrated application feature, rather than an installation version or choice. It is seldom an absolute requirement that no other users on the same PC should be able to use the application, and if it is - then licensing is often centrally managed via client-server technologies and not just a serial key in the registry.
In my view applications on Windows are generally installed and available to everyone on the PC, and my preference is to lock the install to be per-machine. There are too many problems, idiosyncrasies and test cases for a per user install to be desirable. The per user installation logic and the way it redirects some installation folders and still allows multiple installs - some per machine - is also poorly designed - at best. If not purely illogical. Terminal server installations may be different, but that is a different topic entirely.
I write only minimal values to HKLM, and ensure that it can be treated read-only after installation. I typically write data entered into the setup GUI such as license keys, language setting and similar to HKLM. When the application launches it checks if there is data in HKLM and applies these to HKCU to set up a proper runtime environment. And critically: should data from HKLM be unavailable, the application should actually apply "internal defaults" from the application's startup routine in my opinion - this is to ensure the application can start even with no registry data available - this also helps during application debugging. The only case I can recall where the application should fail to launch is if there is insufficient permissions to write to HKCU or the userprofile folders.
So in some sort of a summary I would:
* Lock the install to install per machine / avoid per user installs - this avoids all sorts of problems, particularly with patching and advanced installation features. The setup must run elevated.
* Ensure the application is capable of starting from "internal defaults" set in the EXE file's startup routine and populate HKCU largely from defaults, and also to be able to copy any values written to HKLM during install. Launch can still fail if there are files missing that are required for launch.
* Minimalize all registry data in HKLM. Treat it as read-only data capable of being copied to HKCU
* Write a version value in HKLM with your setup and have the application compare to an equivalent in HKCU. If the value in HKLM is higher than HKCU, the application re-applies or updates values accordingly in HKCU. This is necessary to ensure you can enforce new default values for old keys in new versions of the application, or delete obsolete keys or buggy values. These values must be fixed for all users. Using the version value logic your application's startup logic can perform different logic for different application versions. This avoids all need to mess around with HKCU data manually with scripts and hotfixes if there are errors to take care of.
HKLM\Software\Company\App\Version\InstallationVersion = 1.2.0
HKCU\Software\Company\App\Version\InstallationVersion = 1.1.0
This was a lot of information based on real-world setup experience written in a hurry. Please add any questions - I might have forgotten something important.
Edited by Glytzhkof, 14 February 2014 - 21:08.