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
--Ruben