Before redistributing PLUSNative with your application, it is important that you review the third-party licenses.
If you are linking with the PLUSNative static library, the library will be included in your executable and you should not distribute the library file. If you are linking with the PLUSNative shared dynamic-link library, you must distribute the library file with your application and install the library to the appropriate location.
It is possible to install the shared library in the application directory (which we strongly recommend), but this does require extra configuration. Installing the library to the application directory greatly simplifies deployment and also prevents other applications from installing a different version of the library that may not be compatible with your application. In order for your application to look for a shared library in the application directory, you must modify the executable and set it's RPATH. This can be done using the patchelf command. The following example demonstrates setting the RPATH for an executable named "program". This command would be issued in the terminal or executed from a bash script.
Alternatively, the PLUSNative shared library (libPLUSNative.so) may be installed to a location that is included in the system's default shared library search path, such as /usr/lib or /usr/local/lib. On 64-bit Linux distributions, the 32-bit and 64-bit libraries are generally installed to separate locations, which can vary on the distribution. This typically varies in one of two ways:
It is generally recommended that you distribute packages for the most popular Linux distributions. By targeting these, you can create packages which account for these differences.
The PLUSNative shared library (libPLUSNative.dylib) can be installed to the application directory (which we strongly recommend). Installing the library to the application directory greatly simplifies deployment and also prevents other applications from installing a different version of the library that may not be compatible with your application.
Since OS X does not have separate locations for 32-bit and 64-bit library files, if you choose to install the library to /usr/lib, for example, you must create universal binary as described in the development project references topic) and distribute it to this location.
The PLUSNative dynamic-link library (PLUSNative.dll) can be installed to the application directory (which we strongly recommend). Installing the library to the application directory greatly simplifies deployment and also prevents other applications from installing a different version of the library that may not be compatible with your application.
If you opt to install to the system directory, the location varies depending on whether installing on 32-bit or 64-bit Windows. On 32-bit Windows, the library should be installed to the system32 directory (usually C:\Windows\system32). On 64-bit Windows, the 64-bit library should be installed to the system32 directory (usually C:\Windows\system32), while the 32-bit library should be installed to the SysWOW64 directory (usually C:\Windows\SysWOW64). On 64-bit Windows, Windows silently redirects 32-bit applications to the SysWOW64 directory. In order for a 32-bit installer to correctly install 64-bit libraries to the system32 directory the installer must be properly configured to disable redirection.
When using the PLUSNative dynamic-link library (PLUSNative.dll) you should not distribute the PLUSNative import library (PLUSNative_dllimport.lib) with your application.
Protection PLUS 5 SDK license files are generally not distributed with an application. When using read-only license files, they must be issued by SOLO Server during activation. When using writable license files, such as for unmanaged evaluations/trials that do not require activation, the license files are generated the first time the application runs. Depending on where you choose to store your application's license files, you may need to set permissions on these locations during installation so that your application has write access and can save it's license files when it runs or is activated. Permissions can be set on the directory or file level. If you desire to set permissions on the file level, you can install a blank (empty) license file as a placeholder during installation.
The SK_PermissionsGrantControlToWorld function is provided to assist in setting such permissions, and can be used in a separate helper application you create and call from within your application's installer.
Microsoft Office applications (such as Word, Excel, Access, etc...) may run in a ClickToRun environment. This environment has known limitations that make it problematic for licensed Office add-ins and macros to use global locations. Consequently, licensed add-ins and macros that target these environments should only use user-specific locations for licenses and aliases. See this knowledge-base article for more details.
When using writable licenses, PLUSNative automatically attempts to set permissions on the license file and the aliases when they are saved. You can use this to your advantage by creating a separate helper application that creates and saves the initial the license file and aliases, or add a custom command-line switch to your application that allows it to do this silently. This would enable you to call the helper application or your main application (with the command-line switch) from your installer.
It is recommended to use SSL when communicating with SOLO Server using web service calls. In order for SSL to function, the client certificate (and any intermediate certificates) for your root certificate authority (CA) must be installed on the system. On OS X, the certificates in the Keychain will be used. On Windows, the certificates in the Certificate Store will be used. On these platforms, you can generally depend on the OS to manage these certificates and there are no extra distribution requirements.
On Linux, there are a number of common locations where certificates can be found, and PLUSNative will search these locations consecutively looking for a certificate bundle to use. The location and order PLUSNative will search is listed below:
The first certificate bundle found will be used. If the required client certificate is not found in the certificate bundle communication over SSL will fail, even if the certificate is present in one of the other certificate bundles located on the system.
PLUSNative will automatically attempt to fall-back to a plain-HTTP request (unless the SK_FLAGS_REQUIRE_SSL flag was specified in the API Context or function call). Although SSL is preferred, the web service requests are typically encrypted. If you are not encrypting the web service requests, however, this means all of the data will be transmitted as plain-text if communication over SSL fails.