Creating your Installer when using IronWrapping

When you compile a license that uses IronWrapping, the entire contents of the Host Installation Directory is copied to the Release directory created by the IronWrap linker. This directory will contain the wrapped host, the distributed license file and every file from the source directory (minus all embedded binaries and data files).  This allows you to easily use the Release directory as a source for your installer package creator.

For Hybrid method users: Note that even if you use the ClientProtector COM server in your application (that is IronWrapped) you do not have to deploy the dll or register it.  This is because the IronWrap core will virtualize all access to the dll after it has been wrapped.  This adds security, protecting your from the Trojan attack, and simplifies distribution.  So, while developing, you will be using the COM server in the normal way, without changing your code at all, when you compile into an IronWrapped application using the License Manager, the application will use the virtualized ClientProtector provided by the IronWrap core.

Creating your Installer when not using IronWrapping

There are a few important considerations when creating your installer without IronWrapping:

1. Your installer package must register the SSCProt.dll with the Windows system. See your installers documentation for instructions how to register COM server dlls. This is a built in function in virtually all professional installer packages. The registration information is embedded inside the dll, so if your installer package includes this option, indicate that the registration information should be "extracted from the dll".

2. The attributes your installer uses for the SSCProt.dll should indicate that:

   1. This is a shared file. (In case there are other applications which use it)

   2. It should only be overwritten if the installing dll is a newer version.

Installing the Main License File

Regardless of if you are using IronWrapping or no, be sure that your installer deploys the Main License File to appropriate directory. For simplicity we recommend that you deploy it to the same directory as the host application executable. (See the StartUp function in the ClientProtector Reference for information about relative vs. absolute paths of the Main License File.)

1. The attributes your installer uses for the Main License File (and any Steganographic Alias Files) should indicate that:

   1. The file should never be overwritten. (see below)

   2. The file should not be removed upon un-installation. (see below)

Main License File Attributes

Regarding item #4 above, it is very important that you consider how you will handle un-installation. If your un-installation process removes the Main License File, then the user re-installs your software (legitimately or otherwise), when it starts-up, the ClientProtector will probably be unable to complete the StartUp procedure since the Alias Files will already exist and will not corroborate with the Main License File. Depending on if you have Auto-Recover and/or Auto-Main-License-File-Replace on, the ClientProtector will return a FALSE value (FALSE_LFS_NOT_CORROBORRATE). This is why we recommend that the file never be removed.

If the file is never removed, and if you never overwrite it, then the above un-install / re-install scenario will have absolutely no effect on the state of the license. This is generally preferred.

If you can not do this then you must be prepared for the possibility that it will happen in your code and take the best action possible to correct it. The ClientProtector gives you several options for recovering from failure: automatically using Auto-Recover and/or Auto-Main-License-File-Replace (less secure), semi-automatically in your own code by using the ForceRecover() function, and by using an Activation Code which the user must get from you and manually enter (most secure). See the License Recovery section in the Feature Reference for more details.