SLPS Developer Discussion Developer level questions on Code Protection, Licensing, customisation APIs etc
InishTech Support Forums > SLPS Developer Discussion > PermutationInstallerBase Login to add this as a favourite.
User avatar
Marx - 1/19/2010 11:33:08 PM


I have a few questions about the installer.  Sorry if your documentation already covers this.

1) Two quote a response elsewhere in the forum "simply tell it to run the Installer during the "Commit" phase. Add "Primary Output from YourApp.exe" to the "Commit" steps,.."

On the other hand KB7 says "simply tell it to run the Installer during the "Install" phase. Add "Primary Output from YourApp.exe" to the "Install" step,.."

Which is correct?

2) Are the versioned dll names e.g. Microsoft.Licensing.Runtime2.0(####).dll recommended over the non-versioned components? When do you recommend one over the other?

3) What is the end result after the installer runs? The installer fails if the permutation, licensing and utils dlls are not referenced in the project. Does it just make sure the three dlls are present?

4) With regard to the knows issue requiring permissions for non-admin users to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SLP Services" and "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SLP Services\Log".  What is your recommended procedure for updating the registry at installation? Are there any code samples for creating these keys in the registry (if they need to be created or does PermutationInstallerBase do that?) and setting the permissions?

I'll appreciate your help.



User avatar
InishTech Dev
InishTech Dev
RBartelink - 1/20/2010 12:51:29 AM

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 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, 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.

User avatar
Marx - 1/20/2010 1:25:32 PM

Thanks for the quick response RBartelink.

Just to clarify with respect to 2):

Is it correct to say that the dll name e.g. Microsoft.Licensing.Utils2.0(####).dll can be changed for the same permutation (I notice mine changed after the v2 to v3 upgrade) but at the same time no two permutations will share the same dll name?

That's fantastic news regarding 4) i.e. the known issues are no longer a problem so long as PermutationInstallerBase installer is part of the setup.



User avatar
InishTech Dev
InishTech Dev
RBartelink - 1/21/2010 1:59:47 PM

The short code is a hash of the full long random permutation id (which is guaranteed unique). While the short code is not gauranteed to be unique, it's statistically very unlikely in any given execution context.

You should not see a short code (or DLL name for unversioned ones) change as part of a V2 to V3 upgrade. I havent looked at your account, but I assume the change can only be for one of two reasons:

* you created a new permutation in your account

* you got the permutation from another SLP Online Service account - perhaps one was trial and the other not?

Hope this helps.

PS moved your other post from SecureLM to

User avatar
InishTech Dev
InishTech Dev
josullivan - 9/18/2010 11:23:37 AM


Just as an addendum, wanted to mention that covers the amended behaviour as of the most recent Code Protector / Runtime release.

The exec summary is that you anyone that has opted to use the 'versioned' DLLs (i.e., the ones with the e.g., (1908) bit in the DLL names) should immediately start phasing that use out in favour of the normal 'unversioned' Runtime DLLs.




There are currently no users on-line.

  • Sticky
  • Locked sticky
  • Hot sticky
  • Hot locked sticky
  • Thread
  • Hot thread
  • Locked thread