Redistribution to Clients

From PDF XChange PDF SDK
Jump to: navigation, search
Line 26: Line 26:
 
:<tt>PDFXCoreAPI.x64.dll</tt>
 
:<tt>PDFXCoreAPI.x64.dll</tt>
 
:(for 64-bit application)
 
:(for 64-bit application)
 +
  
 
Next, the installer should prepare the SDK. There are several methods:
 
Next, the installer should prepare the SDK. There are several methods:

Revision as of 11:21, 8 June 2015


There are several ways to install required SDK on the user-user system and get it work there.

First of all, when your installer installing the PDF-XChange Editor SDK - it should copy to client's machine the two files (both in one folder):

PDFXEditCore.x86.dll
(for 32-bit application)

or

PDFXEditCore.x64.dll
(for 64-bit application)

and

Resources.dat

NOTE: if you need to use in runtime the different localizations for Editor's UI - please also copy the whole Languages folder within all containing files from location that is created by our official SDK-installer and place it into the same directory that already contains the other files of our SDK.


Otherwise, when your installer installing the PDF-XChange Core API SDK - it should copy to client's machine the one file:

PDFXCoreAPI.x86.dll
(for 32-bit application)

or

PDFXCoreAPI.x64.dll
(for 64-bit application)


Next, the installer should prepare the SDK. There are several methods:

COM-Server Method.

COM-server should be registered on the destination system. To do that, run the following command:

regsvr32 <SDKLibName>.x86.DLL
(for 32-bit apps)

or

regsvr32 <SDKLibName>.x64.DLL
(for 64-bit apps)

The installer should execute this command. Additional command line option /S can be passed to regsvr32 to remove the message box reporting the result of registration. With this method it does not matter where COM-server files are located relative to the files of your application, as the COM-server are registered globally in the system (using registry) and it become available for all applications in the system. This can cause a potential problem. The following sample shows that problem. Let we have the system where an application called AppA and that uses the SDK version 5.5.313. During the installation of this app, the SDK was globally registered as a COM-server. Than another application AppB, that also uses the SDK is installing on the system, but the installer of this app contains older build of the SDK. When this installer will register SDK’s COM-server, it will override existing COM-server registration and now all applications will use the last installed SDK. If AppA requires newer SDK, it may cause serious issues when it will try to use older version of the SDK.

Registration-Free(Click-Once) Method.

Application’s installer should save executable file of the application and SDK’s files in the same folder, and additional two XML files with special names should be placed in that folder:

<YourProgramName>.exe.manifest
<SDKLibName>.x86.X.manifest (or <SDKLibName>.x64.X.manifest)

Where, <YourProgramName> - name of the application’s executable file without extension.

Sample XML files for Click-Once can be found there: <link>

That method allows avoiding sharing SDK’s DLLs with other applications and conflicts with different versions. Each application that use this method will use own independent version of the SDK.

The more information about Click-Once technology can be found there.

NOTE: In your development environment you have to change settings of your project to use external manifest files instead of built-in.

Using the C-export Method.

This method differs in that it does not require any global registration of COM-server and no additional manifest files. However, this method requires to manually loading SDK’s DLL using Windows API function LoadLibrary. Than a special function should be retrieved and called from this DLL to create and receive a pointer to the main SDK’s object that will provide an access to the entire SDK functionality. For more information, please refer to sections How to Instantiate in the PXV_Inst and PXС_Inst ActiveX-objects’ descriptions.