Hi Marx.
These are all very good questions. Thanks for asking them on the forum so others can benefit from reading the answers too.
1) The Install phase is the only correct phase. This slipped through the cracks as most people apply the custom action to all 4 phases. Have edited post there to avoid this confusion. In general the KB articles should be considered authorative.
2) The versioned ones come into play when it's possible that two vendors (companies or e.g. divisions of a company) will both have components in the same process space but will not be keeping their SLPS versions in sync.
Using versioned is the "safest" solution but the fact that the DLL names keep changing can make it a pain to use. The MSBuild support which is in beta will alleviate this to a degree. In general, most people use unversioned.
A general rule of thumb would be that if you're distrubuting components as DLLs and you want to support a wide variety of deployment scenarios that only your customers control, using the versioned DLLs gives them more options.
To the best of my knowledge, versioned DLLs are not used a lot in practice.
3) The main things the installer is checking is:
- is the registry key present
- ensuring the permissions right on it (one needs to be admin to adjust them hence doing this in an install phase)
- other consistency checks such as warning about virtualisation [which potentially could cause a license to be redirected into a virtualised part of the registry and then mysteriously not be available to the app if at any point the app was to run non-virtualised].
The 3 DLLs are all touched as part of this (i.e., you reference the runtime one and it dynamically loads the permutation DLL and directly references the utils DLL).
Checking for the presence of the DLLs alone would not be enough justification for unducing the burden of having to have an install phase. The reasons it is required is that one need to be elevated to permission the registry keys so that subsequent runs will work predictably regardless of whether its elevated or not.
4) PermutationInstallerBase does all the creation and permissioning of the registry and is the recommended and supported way to do so. The reasons other code is on the net (not on support.inishtech.com) is:
a) there was a bug in v2.x which means the ConfigureLicenseStorePermissions API fails on OS/Langauge combos where there isnt an "administrators" group with admin permissions (e.g., German OSes etc.) as a literal string was used for the group name. This bug is not present in V3
b) there wasnt a standard Managed Installer class OOTB in V2
In general, if you see code samples or articles that haven't been migrated onto support.inishtech.com, it's because the approach is no longer recommended.
Note that the log key you refer to is not actually _created_ by the installer (though it'll obviously get the permissions from the parent reg key). OOTB it'll default to %temp%\slp.log if not present which most people seem to leave as it is.
Hopefully the above clarifies sufficiently. If not, please do not hesitate to post any follow-up questions.