SLPS Developer Discussion Developer level questions on Code Protection, Licensing, customisation APIs etc
InishTech Support Forums > SLPS Developer Discussion > Versioned vs. Un-versioned Permutation dlls and Microsoft.Licensing.LicAdmin.exe Login to add this as a favourite.
User avatar
Member
Member
Marx - 2/5/2010 2:22:43 PM
   
Versioned vs. Un-versioned Permutation dlls and Microsoft.Licensing.LicAdmin.exe

Hello,

Here,s the scenario:

Protect a DLL file while selecting "Versioned Distributables" in Code Protector. This results in the new protected DLL, Microsoft.Licensing.LicAdmin.exe and the three versioned distribultible files being moved to the protected folder.

Problem:

Try to run Microsoft.Licensing.LicAdmin.exe and an error occurs.  Select debug in the WER window. The error message is similar to "Cannot find Microsoft.Licensing.Runtime2.0.dll".

i.e. It seems the Microsoft.Licensing.LicAdmin.exe does not work with the versioned distributables - Or is my configuration off?

Thanks,

Marx


User avatar
InishTech Dev
InishTech Dev
RBartelink - 2/5/2010 3:22:02 PM
   
RE:Versioned vs. Un-versioned Permutation dlls and Microsoft.Licensing.LicAdmin.exe

Hi Marx,

http://www.inishtech.com/FAQ86 discusses the distinction between versioned and unversioned.

In general, a top-level EXE that one would ship to a customer would have unversioned DLLs.

In other scenarios such as ISVs who are using protected [DLL] components, you'd typically have the Code Protector installed and be able to run LicAdmin from the Program Files\Code Protector directory and use that to see the consolidated state of all licenses in there.

The other issue is that a given version of LicAdmin is tied to a specific version of the runtime (+utils) DLLs and hence in general would not be able to load an incompatible previous version of the DLL.

If you feel you have a use case where the problem cannot be worked around and can share that, making LicAdmin pick up a versioned permutation DLL we'd add this as a work item for a future release.

Another contributory factor in this not being a previously reported issue is that vendors choose to customise the way in which license activation issues etc. are surfaced to end users in a way that meshes well with their application as a whole and hence choose not to ship LicAdmin in the first place.

I hope this goes some way to explaining why this is not a commonly reported issue.


User avatar
Member
Member
Marx - 2/5/2010 5:37:17 PM
   
RE:Versioned vs. Un-versioned Permutation dlls and Microsoft.Licensing.LicAdmin.exe

I failed to mention that the LicAdmin tool worked if the unversioned files were copied into the protected directory.

The versioned files seem more appropriate for deploying a licensed DLL to the GAC on a web server.

I would prefer not to ship the LicAdmin tool but would also like to keep the instrumentation and protection post build.  Custom code means there is greater chance of an SLP related problem.

The overall problem applies to both EXEs and DLLs. Say a customer wants to purchase the full version of the application before the noncommercial license expires.  Also, I the vendor want to prevent the commercial build from working with the trial license.

I could:

  1. Throw an exception from the app (if LicenseLevel or feature are not a fit) and ask the customer to uninstall the trial license through LicAdmin. or 
  2. Write code in the app to display the license dialog (if LicenseLevel or feature are not a fit) prompting the user for the commercial license. Then check again. If the features or license are still missing the close the app. or
  3. Throw an exception like in 1. but create a shortcut in the All Programs menu to a custom exe that will activate the commercial license even when a trial license is installed.

What is your best practice for upgrading to a commercial license when a trial license is still valid?

Thanks,

Marx.


User avatar
InishTech Dev
InishTech Dev
RBartelink - 2/9/2010 1:20:04 PM
   
RE:Versioned vs. Un-versioned Permutation dlls and Microsoft.Licensing.LicAdmin.exe

Marx wrote: The versioned files seem more appropriate for deploying a licensed DLL to the GAC on a web server.

Correct. Are you doing that? Assuming you're not, does switching to non-versioned suit your usage?

Marx wrote: I would prefer not to ship the LicAdmin tool but would also like to keep the instrumentation and protection post build.  Custom code means there is greater chance of an SLP related problem.

Not having any custom licensing-related code in your main codebase is definitely a supported way of using SLPS.

Note however that it will always be necessary to perform some form of installation of SLPS to prime the registry as discussed in http://support.inishtech.com/kb7 The various solutions under XCopy deployment will allow you to select a mechanism thats best for you.

Even if you go with having some form of XCopy style deployment with no custom code, it is still good practice to have a VerifyInstalled piece at the start of your app that allows you to hook in a clean notification to your user if there is likely to be a problem with the licensing (e.g., if the license is expired you might want to explain what's hapopened and redirect to a renewal / upgrade from trial step). This can be anything - perhaps a loader shim for your app, something invoked from a batch file etc. Or you can simply leave it out, you can leave handling of this to later on in the execution of the app when the license is actually required and then do something that isnt going to confuse the customer if a license isnt present when it's required.

Marx wrote: The overall problem applies to both EXEs and DLLs. Say a customer wants to purchase the full version of the application before the noncommercial license expires.

Yes, in order to facilitate this, something would need to request and install the license - it won't be triggered automatically by the lack of a valid license. That something can either be LicAdmin or custom code.

Marx wrote: Also, I the vendor want to prevent the commercial build from working with the trial license.

Not sure what you're driving at here. In general, one has a single build and then have some protected methods licensed in the commercial SKU but not in a trial SKU.

Marx wrote: What is your best practice for upgrading to a commercial license when a trial license is still valid?

If you are interested in offering a fully-featured trial, you can set an expiration point on those features that you wish to deactivate at the end of the trial period. Any features that do not have an expiration point defined will continue to work, but features that require upgrading to the commercial license will trigger activation (either the standard dialog or you can customise it). If a user enters a key for a commercial license at this point, both licenses will be present and the licensing system will look for a supporting feature permission for each executuin of a licensed protected method.

If you are aiming not to do a fully-featured trial but instead have some features as 'teasers' for the commercial version, then you'd create a trial SKU with some features from the commercial SKU omitted. Execution of features that the trial license is not sufficient for will then trigger default activation (standard, custom or none).

Marx wrote:
1.Throw an exception from the app (if LicenseLevel or feature are not a fit) and ask the customer to uninstall the trial license through LicAdmin. or
2.Write code in the app to display the license dialog (if LicenseLevel or feature are not a fit) prompting the user for the commercial license. Then check again. If the features or license are still missing the close the app. or
3.Throw an exception like in 1. but create a shortcut in the All Programs menu to a custom exe that will activate the commercial license even when a trial license is installed.

Can you clarify which of the above options still apply in your scenario given the above details?
The default handling, together with configuring the features in the SKUs as detailed in the previous block will be sufficient for many cases and do not involve any custom code.

In general, there is no need to explicitly 'remove' a trial license - trial and commercial can sit side by side.

In the absence of a clear single scenario, let me expand on the types of possibilities there are around this area...

If you wish to proactively offer upgrades from trial to commercial (or e.g. renewals of recurring licenses etc.), you can write custom code which can determine whether an upgrade is appropriate based on (just some ideas, not intended to be exhaustive):
- whether a commercial license is not present
- whether a trial license is still in-date
- time to expiration points of licenses
- time to expiration points of licensed features
- whether the user is fitting a particular usage profile

Examples of when/how you might invoke this logic are (any combination of):
- In a helper licensing tool you supply in the start menu
- On app startup in your main app (or maybe shell out to the tool in the previous line?)
- Via a licensing menu option
- via hyperlinks on appropriate menus that people will encounter in their workflow which touch on the features you're hoping to offer

Then to actually manage the requesting of the license and installation/activation thereof, you can either:
- explicitly write code to do so, possibly including managing of payments, redirecting to a purchase flow on an external website
- (or, if you want to avoid writing code and are happy with the licensing looking and feeling like something external to your app) redistribute LicAdmin and let the users invoke via a Start menu shortcut


User avatar
Member
Member
Marx - 2/9/2010 2:54:53 PM
   
RE:Versioned vs. Un-versioned Permutation dlls and Microsoft.Licensing.LicAdmin.exe

Assuming you're not, does switching to non-versioned suit your usage?

Simple answer is No.

Note however that it will always be necessary to perform some form of installation of SLPS to prime the registry as discussed in http://support.inishtech.com/kb7

I'm aware of that as you may recall.

Not sure what you're driving at here. In general, one has a single build and then have some protected methods licensed in the commercial SKU but not in a trial SKU.

SLP is not the only protection. You can also set the exe to expire using tools like Dotfuscator.

If you are interested in offering a fully-featured trial, you can set an expiration point on those features that you wish to deactivate at the end of the trial period.

This is good to know.  From what you've indicated this would be the best practice if I was going with a single build.
Thanks for your help. Seems like some custom code will be necessary.

Marx


User avatar
InishTech Dev
InishTech Dev
RBartelink - 2/9/2010 4:38:50 PM
   
RE:Versioned vs. Un-versioned Permutation dlls and Microsoft.Licensing.LicAdmin.exe


>>Assuming you're not, does switching to non-versioned suit your usage?
>Simple answer is No.

OK (wasnt sure whether you were making a general point about how things should be or one related to your specific requirements). So your scenario is that you wish to use Versioned DLLs but still be able to have your customers use LicAdmin to maintain licenses. Can the DLLs be expected to be in the GAC or not? Either way, it looks like the current LicAdmin will not correctly support this scenario. In other words, we'd have to do code changes and a new drop of the SLPS runtime if that's what you need. However I'm still not sure as to your reasoning (see the rest of my responses for related questions)


>>Note however that it will always be necessary to perform some form of installation of SLPS to prime the registry as discussed in http://support.inishtech.com/kb7
>I'm aware of that as you may recall.

Sorry - this wasnt meant to come across as patronising (you've asked some great questions and I'm well aware of the fact that you appreciate this fact). I was merely making sure that the answer could be complete and bring in all the salient considerations.


>>>Also, I the vendor want to prevent the commercial build from working with the trial license.
>>Not sure what you're driving at here. In general, one has a single build and then have some protected methods licensed in the commercial SKU but not in a trial SKU.
>SLP is not the only protection. You can also set the exe to expire using tools like Dotfuscator.

I still dont understand what exactly what you mean in this point. If both trial and commercial versions are using SLPS (which is the general use case catered for), this would be the simplest approach. Are you saying that in your scenario you want to explicitly remove the trial license in order to inhibit execution of code that was reliant on it?

Is that due to the fact that your commercial license uses another protection mechanism?

Or is it that you are disabling the trial version by some other means and you're running into problems because the [SLPS-protected] commercial version is still picking up the trial license?

I fully respect that one might wish to do this in some scenarios but am interested in understanding the exact requirements so that SLPS can help as much as possible in realising that requirement and then getting out of the way and letting you and the customer do your work.

>>If you are interested in offering a fully-featured trial, you can set an expiration point on those features that you wish to deactivate at the end of the trial period.
>This is good to know.  From what you've indicated this would be the best practice if I was going with a single build. Seems like some custom code will be necessary.

I believe so, but am still not clear on your exact strategy. If you are looking to disable the trial license (and not replace it with a SLPS commercial license) then yes, you'd need to remove the license to cut off that route by using custom code to uninstall it (as asking the user to manually delete the license via LicAdmin wouldn't make sense for multiple reasons).

If you have the time to expand further on your scenario, please feel free to do so and we'll endeavour to make things clear if they are not already.

If you'd prefer to discuss the details privately, please feel free to send an email to support.


User avatar
InishTech Dev
InishTech Dev
josullivan - 9/18/2010 11:16:59 AM
   
RE:Versioned vs. Un-versioned Permutation dlls and Microsoft.Licensing.LicAdmin.exe

Hi,

Just as an addendum, wanted to mention that http://support.inishtech.com/FAQ86 covers the amended behaviour as of the most recent Code Protector / Runtime release.

The exec summary is that you should now no longer need to use the 'versioned' Runtime DLLs (i.e., the ones with the e.g., (1908) bit in the DLL names) and hence LicAdmin should Just Work in the context you have described.

--John
 


1

There are currently no users on-line.

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