Redistribution to Clients

General Info > Redistribution to Clients

Redistributing and installing the required components onto a target users system is a relatively straight forward process and we provide several ways to do so - dependent on the functionality that has been used within your application, below you will find detailed instructions on doing so - please do not simply redistribute our 'developers SDK' in its entirety - this will simply clutter your users system, bloat your own installer and most likely confuse your clients as to what applications are available for their use.

Option 1.

If you have used the UI based functionality contained in the PDF-XChange Editor SDK - your installer must include the following two files (note the 32/64 bit dependency of specific DLL's and locate both into one common folder on the users system

Installation of the PDFXEditCorexxx.dll incorporates all PDF-XChange Core API SDK functionality and negates the need to install the PDFXCoreAPIxxx.dll file subsequently detailed.

PDFXEditCore.x86.dll

(for 32-bit applications)

or

PDFXEditCore.x64.dll

(for 64-bit applications)

and

Resources.dat - this file is not 32/64 bit dependent and always the same.

NOTE: If wish to include different language localizations for the Editor's UI - please also include the entire Languages folder we provide and relevant language files as installed by your initial SDK development system installed from us. These files should be located in the same directory as the files detailed above.

Do you have any improvements to our Localization files or perhaps a new one you would like us to include? If so we would be pleased to add them to our official releases in coming updates, see here for more info.

Option 2.

If your application makes use only of 'non UI' based functionality as available in the PDF-XChange Core API SDK you need copy only a single file to your clients target system - again please note the specific version will be 32/64 bit dependent...

PDFXCoreAPI.x86.dll

(for 32-bit applications)

or

PDFXCoreAPI.x64.dll

(for 64-bit applications)

Your installer must then prepare your clients system for use of the installed components, the installer should prepare the SDK for use - there are several methods of doing so and you should choose that which is most appropriate for your needs and clients most likely circumstances;

COM-Server Method.

COM-server to be registered on the target system. To do so, run the following command:

regsvr32 <SDKLibName>.x86.DLL

(for 32-bit apps)

or

regsvr32 <SDKLibName>.x64.DLL

(for 64-bit apps)

Additional command line options /S may be passed to regsvr32 to suppress registration confirmation status message box .

Using this method ensures that irrespective of the COM server files location relative to your application files the SDK functionality will work correctly, as the COM-server are registered globally within the target system as relationships are managed by the system registry.

IMPORTANT: One potential problem this can cause however is where a user has multiple applications using our Editor SDK functionality (perhaps from you or from one or more 3rd party developers) but each relies on differing releases/builds of our SDK (for example one developer used Version 5.5.313 when creating his application - but you have used a subsequent, later release) here an issue may arise should each developer's installer use the COM global registration method. Whichever installer ran last will be the COM server available to all applications. Should new functionality be available in a later release and one applications is dependent on this functionality - but subsequently another installer is used to install an older version - the new functionality is no longer available and one application or more will cease to function correctly...

Good installation management will therefore be essential and you may prefer to resist using the global registration method on users system for this reason.

Registration-Free(Click-Once) Method.

Your application installer should locate all application executable files and the require PDF-XChange Editor SDK files in a single common folder along with 2 additional XML files with prescribed file names as follows:

<YourProgramName>.exe.manifest

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

Where, <YourProgramName> - is the name of the application’s executable file without a file extension. Sample XML files:

<YourProgramName>.exe.manifest source:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly manifestVersion="1.0" 
	xmlns="urn:schemas-microsoft-com:asm.v1"
	xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
	xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >

	<assemblyIdentity version="1.0.0.0" name="<YourProgramName>" />

	<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
		<security>
			<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
				<requestedExecutionLevel level="asInvoker" uiAccess="false" />
			</requestedPrivileges>
		</security>
	</trustInfo>

	<!-- Registration-Free Redistribution part -->
	<dependency>
		<dependentAssembly>
			<assemblyIdentity type="win32" name="PDFXEditCore.x86.X" version="1.0.0.0" />
		</dependentAssembly>
	</dependency>

	<!-- Optional: enable themes for Windows common controls and dialogs (Windows XP and later) -->
	<dependency>
		<dependentAssembly>
			<assemblyIdentity
				type="win32"
				name="Microsoft.Windows.Common-Controls"
				version="6.0.0.0"
				processorArchitecture="*"
				publicKeyToken="6595b64144ccf1df"
				language="*" />
		</dependentAssembly>
	</dependency>

	<!-- Optional: enable DPI-Aware mode to prevent automatical DPI-scaling to avoid 'blurring' of UI -->
	<asmv3:application>
		<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
			<dpiAware>true</dpiAware>
		</asmv3:windowsSettings>
	</asmv3:application>

</assembly>

PDFXEditCore.x86.X.manifest source:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

	<assemblyIdentity
		type="win32"
		name="PDFXEditCore.x86.X"
		version="1.0.0.0" />

	<file name = "PDFXEditCore.x86.dll">
		<typelib 
			tlbid="{0AAFF38C-CB91-4424-A8B9-F8B504ACBE0C}"
			version="1.0"
			helpdir=""/>
         
		<comClass
			clsid="{973BF60B-4CC6-4be0-B408-3D80E07FC2E6}"
			threadingModel="Apartment" />
        
		<comClass
			clsid="{A1149909-4EDC-4421-B9E5-E93C25A000A1}"
			threadingModel="Apartment" />
	</file>

	<comInterfaceExternalProxyStub 
		name="IPXV_Inst" 
		iid="{D726366D-34D6-49fc-A341-7B84C54CCA3E}"
		proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
		baseInterface="{00000000-0000-0000-C000-000000000046}"
		tlbid="{0AAFF38C-CB91-4424-A8B9-F8B504ACBE0C}" />
    
	<comInterfaceExternalProxyStub 
		name="IPXV_Control" 
		iid="{71300D43-687F-436A-A699-2B37448D0803}"
		proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
		baseInterface="{00000000-0000-0000-C000-000000000046}"
		tlbid="{0AAFF38C-CB91-4424-A8B9-F8B504ACBE0C}" />
    
</assembly>

That method ensures that sharing our SDK’s DLLs with other applications is avoided as are version conflicts described previously. Each application uses its own unique version of our SDK DLL's etc.

More detailed information regarding Registration-Free technology can be found here.

IMPORTANT: In your development environment you will also need to change the settings of your project to use external manifest files as opposed to those built-in by default.

Using the C-export Method.

This method differs in that it does not require any global COM-server registration or additional manifest files. Instead, this method requires manually loading the SDK’s DLL by use of the Windows API function LoadLibrary. Then 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 access to the entire SDK functionality. For more information, please refer to the topics; How to Instantiate PXV_Inst and PXС_Inst ActiveX-objects’ description.