SLPS Developer Discussion Developer level questions on Code Protection, Licensing, customisation APIs etc
InishTech Support Forums > SLPS Developer Discussion > Low level details re installation and uninstallation of SLPS Login to add this as a favourite.
User avatar
Member
Member
jmealing - 4/29/2010 9:28:12 PM
   
Low level details re installation and uninstallation of SLPS

Been through the Forums and How To on installing SLPS and just came off a 2 week learning curve on building a VS 2008 Setup & Deploy project and I think that I have a pretty good handle on install projects.

Now trying to add InishTech protection, and am badly confused by one of the steps in the How To:

  1. Visual Studio Deployment Projects (.vdproj projects) have a Custom Action option - simply tell it to run the Installer during the "Install" phase. Add "Primary Output from YourApp.exe" to the "Install" step, and set the InstallerClass property to True.

I understand the Install phase of the project - used it already for some other things.

What are you trying to say? That there should be a special install executable written just to install SLPS - using what? What should it look like? Other material in the Code Protector discussion say that the actual installer MSI should NOT be sent to the customer.

Are you trying to say that my application (which is not yet installed) should be run? Huh?

I did create a minimal app that has the code in the example and it works: "Not installed" is displayed correctly.

Sorry to be so dense, and any help will be appreciated.

Opps! The code is in the SLPS developer Discussion. One line in the app does the job. Thanks to scottymo for putting it there.


User avatar
InishTech Dev
InishTech Dev
RBartelink - 4/30/2010 2:29:16 AM
   
RE:More on the installation of SLPS

Hi,

Sounds like you have it worked out, but will respond just to confirm some things in case you're still blocked on this - we appreciate it's frustrating to have one's time swallowed on implementing and testing installers.

There is no expectation of running your EXE until after the MSI installation has completed -- if the MSI has a "run the app now" option, that's fine but absolutely not necessary, but one should be invoking the Managed Installer (specifically the `Install` phase) which one embeds into one's EXE as described in KB7.

The invocation of the Managed installer is a standard .NET technique which you'll generally see covered in articles in the context of installing Windows Services. You can either invoke the native .NET utilities such as installutil.exe (this is pretty straightforward and if you're using a tool like InnoSetup which doesnt provide .NET-specific Custom Install Steps is the main route available) or use .NET Managed installer Custom Steps support (this works smoothly with Visual Studio Installer steps and InstallShield)

Regarding shipping MSIs - there may be specific mention of which aspects of the Code Protector SDK represent redistributable components and which do not in the documentation. The exec summary is that:

1) All binaries in the Release.Protected directory are redistributable.

2) Whether or not one ships LicAdmin is up to you

3) We advise using an MSI based installer and *only* performing the SLPS installation step during the Install phase (i.e., not the Commit phase) of a standard MSI install (the wording is trying to be precise as it's easy to confuse the 4 stages, and a previous version of the documentation did not make it sufficiently clear). This guarantees the step will run elevated and means one doesnt have to worry about running as administrator or any other such things after the installation hass completed

4) we recommend adding a VerifyInstalled step to your Main() as a safety check

Finally, without searching for @scottymo's post, IIRC that was a one-liner way of invoking the installation process. While this works, the process in KB7 intentionally chooses to use a standard Managed Installer class as this is the idiomatic way of approaching this in .NET and is the way most people exposed to writing installers (lucky sods that they are!) wil be used to. One critical thing to understand is that the one-liner to do the installation should only ever be invoked a single time during an "install" phase where execution privilege is elevated (as-admin). All subsequent user invocations of your app should not require admin privilege and it's highly recommended to also do the one-liner VerifyInstalled in your Main.

Another approach we've seen people being satisfied with is to add commandline options to one's app to allow one to perform the installation piece (i.e., one runs the app itself elevated with a -Install flag rather than implementing a System.Configuration.Install.Installer-derived class and invoking it through the Managed Installer mechanisms). It's hard to argue that this is simpler to implement though, which is why this approach and the one in the preceding paragraph are not covered in any depth in KB7)

I hope this extra detail helps more than it confuses. We'd appreciate your inputs either by email or via this forum regarding any statements in the article you feel are misleading or threw you off the scent - we appreciate that people implementing the installer hooks will have varying degrees of exposure to the finer points of installation, which far too often gets treated as a silod part of the development process (even though it's part of your software's critical first impression on users...!).

If you or anyone else have any further clarifying questions it'd be great to cover those too. Note that KB7 is intended to be a one-stop-shop for installation information.

Thanks,

--Ruben


User avatar
Member
Member
jmealing - 5/1/2010 5:36:21 PM
   
RE:More on the installation of SLPS

Ruben:

Thanks for the detail. I tried the   ManagedInstallerClass.InstallHelper approach, and it worked just fine, but the "/u" to uninstall SLPS has no effect. The log file entries do show that it was uninstalled, but the install verification says that it is installed, and the program runs without having to re-install SLPS. I did find one reference to Inishtech in the registry, removed it and re-booted, but still get that SLPS is installed.

My problem now is how to UNinstall SLPS so that I can do further testing on INstall scenarios?

Thanks in advance for any help you can give.

John


User avatar
InishTech Dev
InishTech Dev
RBartelink - 5/4/2010 8:58:32 AM
   
RE:More on the installation of SLPS

 Hi John,

The uninstall step is a placeholder. At present, no licenses are removed during the uninstallation procedure. This is largely due to the fact that it is difficult to come up with a universally acceptable default policy. For example, if one is only uninstalling in order to install a new version (remember that VS2005 .vdproj installers do this under the hood) you dont want to have to reactivate.

Having said that, there are a numbe rof approaches to resolving your case:

1) you can use the SLPS APIs to walk through the installed licenses and call UninstallLicense() on any licenses you feel are appropriate (obviously one needs to take care to filter by vendor and product appropriately). You can hook the code for this in by overriding Uninstall in the Installer class you've added (assuming you're following the standard KB7 guidelines). You'll be able to do things like convert it to a blob and store it in a file and then re-install the blob when you're ready. The snippets at http://codepaste.net/list/user/inishtech%20support should give you a head start 

2) You can do a low level wipe of the registry. Note this is not recommended as in general an activation is a significant logged/metered/billed event and 'throwing away'the license means a new actuivation needs to take place. Also, the registry location maintains all SLPS licenses, potentially including ones from other vendors. Having done the proviso bit, there are two means to do this:

a) the registry key is (for SLPS V2 and V3)

32 bit OS: HKLM\Software\Microsoft\SLP Services

64 bit OS: HKLM\Software\Wow6432Node\Microsoft\SLP Services (sic - 32 and 64 bit apps store in same reg key)

One can use e.g. Powershell to remove the key etc.

3) There are a set of undocumented Obliterate APIs which will let you do the equivalent of (2) in your code, taking care of 32/64 bit handling etc.. NB These remove all SLPS licenses from a machine so use in a test context only, and be careful. Use the Visual Studio Object Browser to get details.

I trust this is enough to get you started. Let us know if you have any further questions.


User avatar
Member
Member
jmealing - 5/4/2010 1:45:21 PM
   
RE:More on the installation of SLPS

Thanks for the details. Your comment about all SLP licenses was particularly valuable since I was about to strip that key out of the registry during in un-install. Guess that is not a good idea - unless I do a bunch of preparation work.

You mention "store it as a blob" - the code snippets look like it is the license entries being stored as a blob. How would that work if the user moves to another machine (I thought that the license activation was totally machine specific)?

Is there some information on manual activation, how to do it and how it works? Is that the off-line activation feature?

Assuming that I un-install the license, and the user reinstalls on a new machine, is there a new activation charge?


User avatar
InishTech Dev
InishTech Dev
RBartelink - 5/4/2010 3:13:10 PM
   
RE:More on the installation of SLPS

jmealing wrote: You mention "store it as a blob" - the code snippets look like it is the license entries being stored as a blob. How would that work if the user moves to another machine (I thought that the license activation was totally machine specific)?

I was suggesting this as a way to manage temporarily moving a license out of view for test purposes. The blob will be machine specific and hence useless on any other machine as you suggest. 

jmealing wrote: Is there some information on manual activation, how to do it and how it works? Is that the off-line activation feature? [/quote/]

Normal or online activation is the normal mechanism wherein:

0) The license is created on the licensing portal, yielding an activation key

1) the user enters an activation key (or it might be extracted out of the install package)

2) the client code generates an activation request blob which contains machine details plus the key

3) the blob is submitted to the activation web service which verifies the activation key and returns the associated license details, signed and ready to use on the client

4) the client installs the license blob in the license store

Offline/Manual activation is where step 3 cannot be performed directly as the machine on which the license is to be installed is not in a position to communicate with the license activation service (e.g., not connected to the internet, esoteric firewall issues, etc.). In this case, the LicAdmin app can generate a "Manual activation request"which is a text rendering of the license activation blob which can then be pasted into the Manual Activation page of the SLPS Online Service. This process (creating a Manual Activation request and submitting it can also be done programmatically).

The fundamental sequence and flow is the same in all cases.

The details (and a far clearer explanation) are in the SLP Getting Started Guide under the "Activate a License Offline" section.

jmealing wrote: Assuming that I un-install the license, and the user reinstalls on a new machine, is there a new activation charge?

Each activation is a separately chargeable transaction. Depending on whether your product is sold as a Multi-Activation license or Single, this may or may not directly translate to a charge for the license in each case.

If you are performing internal testing, activation charges are waived. To enable us to identify such test licenses, add a "FOR INTERNAL TESTING ONLY" string in the License Description field.


1

There are currently no users on-line.