Redistribution to Clients

From Tracker Software PDF SDK
Revision as of 14:16, 5 June 2015 by Pifagor (Talk | contribs) (Created page with "__NOTOC__ Category:Editor {{#customTitle:Redistribution to Clients}} {{#parentPage:Main_Page}} {{ToWrite}} {{ToReview}} There are several ways to install required SDK on...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

First of all, your installer should save the SDK DLL file (PDFXCoreAPI.x86.dll or PDFXCoreAPI.x64.dll for the PDF-XChange Core API SDK; PDFXEditCore.x86.dll or PDFXEditCore.x64.dll for the PDF-XChange Editor SDK). Also for the PDF-XChange Editor SDK the file Resources.dat must be saved into the same folder.

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


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 application 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.

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 PXC_Inst objects’ descriptions.