SLPS Developer Discussion Developer level questions on Code Protection, Licensing, customisation APIs etc
InishTech Support Forums > SLPS Developer Discussion > Build process Login to add this as a favourite.
User avatar
jrgrizz57 - 2/15/2011 2:02:51 PM
Build process

I'm struggling with getting a reliable process worked out for making changes to a licensed app. I had everything working then made some application changes and now can't get the app to recognize the license. I'm confident that my problem lies in not understanding what SLPS resources need to be updated and when. By "resources" I'm talking about things like permutations, .SLMCfg files, etc.

I am declaratively marking my protected method as described in KB13. I have integrated protection into Visual Studio as described in KB12, and am using the xcopy publish method from KB7.

What SLPS resources need to be regenerated when application code is changed? Do I need to get a new permutation? A new .SLMCfg file? 

User avatar
InishTech Dev
InishTech Dev
RBartelink - 2/15/2011 4:22:58 PM
RE:Build process

 First, some slightly-related FAQs:-

The key things that need to be in sync are:

1) the versions of the 3x Microsoft.Licensing DLLs you reference in your project

2) the code protector permutation indicated inthe .SLMCfg file (the permutation Id selected in Code Protector)

3) The Code Protectdor SDK download

1 is normally obtained by using 3 to extract from 2

2 and 3 are downloaded beside each other in the SLP Online Service

Code Protector will error if the permutation (2) is out of sync with the protector(3).

At present, you wont find out if an extracted runtime is out of sync with the permutation (2) installed in code protector until runtime. This can take two forms:

a) if you've e.g. referenced 3.0.1913 and protected with 3.1.1915, calls to the runtime will fail to resolve (the type resolution includes the asssembly version)

b) if you've updated your permutation but have an extracted set of DLLs from a previous update, the randomized permutations will be out of sync.

Now, to actually answer your question...

As long as all Code Protector, the Permutation installed into Code Protector and your extracted DLLs are in sync, doing a Rebuild All or equivalent fresh build of your system should result in everything being in sync. Doing a rebuild all should not normally be necesssary - each protect will yield the same outcome.

The .SLMCfg file just retains your product info and method selections - if you're using declarative attribute-driven protection I wouldnt expect to need to change it except if you're moving to a different product/version profile (a very rare thing which would normally involve verifying that the features involved remain appropriate)

I know this is a touch tl;dr. If oyu have specific follow-up questions, I'll be happy to try to give succinct answers to those, sorry!


User avatar
jrgrizz57 - 2/15/2011 4:37:14 PM
RE:Build process

So, if 2 & 3 are downloaded & installed and are used to extract the dlls I should never have to do those steps again, correct? I can extract the dlls and use them in any application using the same permutation?

What condition(s) would require a new permutation to be generated? Would changing a product in the SLP online service to add new features require a new permutation?

When using declarative marking of protected methods, would I ever need to make changes to the SLMCfg file?

User avatar
InishTech Dev
InishTech Dev
RBartelink - 2/16/2011 12:54:26 AM
RE:Build process

jrgrizz57 wrote: So, if 2 & 3 are downloaded & installed and are used to extract the dlls I should never have to do those steps again, correct? I can extract the dlls and use them in any application using the same permutation?


Yes, one download and install can be shared across products. Depending on your org structure, you'll probaly keep them separate if there are separate orgs involved. But the permutation is definitely vendor-specific, not product. Depending on your subscription level, you'll have a different max number of permutations you can concurrently maintain on the service.

Often people like to keep a permutation per product. This allows one to have a clear permutation id mapping and means that if one perm gets compromised, it only affects one product.

Depending on what you want to do, you can roll (regen) your permutation as often as you like - some might do it per release.

Bottom line here is each generated revision (starts from 1 and goes up by one every time you update your perm on the server) on the server needs to have the DLLs extracted each time client side and stuck into your libs directory if you have customisations, but a new code protector download is only needed if the actual version number (i.e., the 3.1.1915.38 bit) changes.

jrgrizz57 wrote: What condition(s) would require a new permutation to be generated? 

As covered above, it's up to you to decide whether to vary by product, by release, by age or any combinarion - each update will randomise differently.

The key thing that's going to make you want to update your permutation from a 'require' perspective is if you wish to avail of a runtime update - that would require an update.

The key thing that would make you want to avoid an update is if a new runtime has been released and you werent prepared to take a new runtime assembly version - but note that every time you download a .SLMPermutation you should be extracting and overwriting the DLLs you keep in oyur libs directory/repository.

While there's nothing intrinsically complex about understanding all this stuff, it can take a while to sink in.

We're definitely looking at adding verification (code protector and/or the Slps.Protect.Targets managing updating permutations and automatically extracting them) and additional automation (code protector having facilities to trigger updates and automatically download the SLMPermutations) over time, though no dates or ship vehicles have been identified. In other words, the reason we dont have a big article with the amount of words in these posts here is that it shouldnt involve that amount of talk - we want the tooling to be much more straightforward than it is.


jrgrizz57 wrote: Would changing a product in the SLP online service to add new features require a new permutation?

No, as long as:

a) the Code Protector version matches the runtime version (e.g. both 3.1.1915)

b) the SLMPermutation in the Code Protector matches the DLLs you're using (i.e., both from the same .SLMPermtuation Revision download and extract)

c) the feature name in the product definition exactly matches (case sensitive) the feature name in the .SLMCfg or the FeatureAttribute (i.e., both "FeatureA")

one can define the features in the code or on the server independently of each-other. The main reason to keep them in sync (aside from maintaining your sanity is that Code Protector only offers the set it has obtained from the server product definititions in its dropdowns so things like the feature names having to 100% match, inc case are preserved).

jrgrizz57 wrote: When using declarative marking of protected methods, would I ever need to make changes to the SLMCfg file?

In short, NO - not in any common scenarios. The only reasons you'd ever need to change the SLMCfg file are:

a) rare: moving to a different permutation id (rare - far more frequent to move to a new revision of the same permutation, and that doesnt require a SLMCfg change)

b) rare: moving to a new product name/version pair - again this is rare as the feature names are per product and you'd have to be sure that the names are similar across the product+version groupings

c) practically never: moving to a new SLP Services vendor account - this should never happen - the permuted assemblies and the licenses are linked by a public/private key at the vendor level

d) probably most common in the medium term: switching to a different SLP Runtime Variant - while there's presently a single variant called v2.0.50727 which supports 2.0, 3.5 and 4.0 editions of the CLR, over time we're likely to offer richer ones tailored to specific environments in a more granular way - e.g., one might be changing the v2.0.50727 to a v4.0.30313 if that was the only way to avail of a specific facility, or to a v2.0.50727+Distributor if you wanted your builds to start emitting the SLP Distributor component too

e) changing or overriding low level options - typically this can be done bby passing overrides in at the MSBuild level - there's a mechanism for feeding arbitrary overrides to items in the .SLMCfg into ProtectCmd via commandline options (this is used internally by Slps.Protect.targets but also represents an extensibility point that's a relatively idiomatic MSBuild style hook point)

If you have any further specific questions, I'll be happy to answer those too.

Finally, sorry for not stating all of this more briefly and succinctly - if I had more, I'd write a shorter letter :D



There are currently no users on-line.

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