Printer driver distribution using merge modules

PDF-XChange Drivers API (only) V4/V5
This Forum is for the use of Software Developers requiring help and assistance for Tracker Software's PDF-XChange Printer Drivers SDK (only) - VERSION 4 & 5 - Please use the PDF-Tools SDK Forum for Library DLL assistance.

Moderators: TrackerSupp-Daniel, Tracker Support, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Tracker Supp-Stefan

Post Reply
numerobis
User
Posts: 7
Joined: Wed Aug 24, 2016 3:22 pm

Printer driver distribution using merge modules

Post by numerobis »

Hello!

First of all, I hope I'm posting in the correct forum, as I'm using PDF-XChange Drivers API SDK V6. I assume though, that there is no difference compared to V4/V5.

In the Drivers API 2012 (I haven't found one for V6) you state: "We provide a comprehensive installation executable for developer's to distribute with their application and this is the ONLY method authorized for distribution...".

I have noticed though, that you also offer merge modules to download on the "PDF-XChange Drivers API" download page. In a post from 2014 (https://forum.pdf-xchange.com/ ... WiX#p84591) I saw that somebody was using these merge modules to integrate the installation of the printer driver into their own MSI.
Based on that, I've tried to integrate the merge module into our WiX project (see snippet below), which successfully integrated the driver into our installer. Unfortunately, after execution of the said installer, a directory with the files contained within the merge module was created (C:\PDF-XChange 6\) along with a set of registry keys, but our application failed when attempting to generate a virtual printer.

Code: Select all

<DirectoryRef Id="TARGETDIR">
   <Merge Id="PDFXChange60PrinterDriver" SourceFile="C:\path\to\module\Driver6_MSM_x86.msm" DiskId="1" Language="0"/>
</DirectoryRef>
<Feature Id="VCRedist" Title="PDF-XChange 6.0 Printer Driver" AllowAdvertise="yes" Display="expand" Level="1">
      <MergeRef Id="PDFXChange60PrinterDriver"/>
</Feature>
I ran the test application attached on a clean install of Windows 10 (VirtualBox). Below is the output from the test program attached along with some remarks.

1. No driver installation (neiter using PDFX6SA_sm.exe nor the merge module):

Code: Select all

2017.05.05 13:10:21.261253: Initializing printer...
#### Error: Retrieving the COM class factory for component with CLSID {636AC372-D9F0-4548-8B67-E53795556624} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.Activator.CreateInstance(Type type)
   at PDF_XChange_Driver_Test.FrmMain.initPrinter(String outputDateiname) in c:\users\numerobis\documents\visual studio 2015\Projects\PDF XChange Driver Test\PDF XChange Driver Test\FrmMain.cs:line 63
   at PDF_XChange_Driver_Test.FrmMain.btnTest_Click(Object sender, EventArgs e) in c:\users\numerobis\documents\visual studio 2015\Projects\PDF XChange Driver Test\PDF XChange Driver Test\FrmMain.cs:line 123
Remarks: As expected... ;)


2. Driver installation using merge module (Driver6_MSM_x86.msm):

Code: Select all

2017.05.05 08:10:54.779307: Initializing printer...
#### Error: Error HRESULT E_FAIL has been returned from a call to a COM component.
   at PXCComLib6.IPXCControlEx.get_Printer(String pServerName, String pPrinterName, String pRegKey, String pDevCode)
   at PDF_XChange_Driver_Test.FrmMain.initPrinter(String outputDateiname) in c:\users\numerobis\documents\visual studio 2015\Projects\PDF XChange Driver Test\PDF XChange Driver Test\FrmMain.cs:line 64
   at PDF_XChange_Driver_Test.FrmMain.btnTest_Click(Object sender, EventArgs e) in c:\users\numerobis\documents\visual studio 2015\Projects\PDF XChange Driver Test\PDF XChange Driver Test\FrmMain.cs:line 128
Remarks:
- Tried it without and with restart, both yielding the same result.
- During un-installation the installer claimed that "pdfSaver for PDF-XChange Printer V6" is still running and asked what do to with it (wait or close it automatically).
- No printer shows up in the "Devices and Printers". (As expected .. don't care about that).


3. Driver installation using PDFX6SA_sm.exe:

Code: Select all

2017.05.05 14:10:54.070314: Initializing printer...(PDF-XChange Standard V6 Numerobis-Temp) Done!
2017.05.05 14:10:55.079652: Test: Printing document...
2017.05.05 14:10:56.350867: PrintPage: Printing a page...
2017.05.05 14:10:56.476096: PrintPage: page printed!
2017.05.05 14:10:56.928431: Test: document printed!
2017.05.05 14:10:56.942158: Document [PDFXChange Test Document] being spooled by application: [PDF XChange Driver Test.exe]
2017.05.05 14:10:57.380590: Document created and saved as: C:\Users\numerobis\Desktop\bin\x86\Release\Output.pdf
2017.05.05 14:10:57.380590: Succesfully finished!
Remarks:
- Works even without a restart.
- Printer shows up in the "Devices and Printers".

So my questions are: Is the merge module meant for a different purpose, and if so for which? If not, then what are we doing wrong?

Best regards!
Attachments
PDF XChange Driver Test.zip
(21.21 KiB) Downloaded 177 times
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17820
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: Printer driver distribution using merge modules

Post by Tracker Supp-Stefan »

Hello numerobis,

We have passed this to a colleague working on the installation packages, and he has confirmed that he will take a look and check why this might be happening.

Regards,
Stefan
numerobis
User
Posts: 7
Joined: Wed Aug 24, 2016 3:22 pm

Re: Printer driver distribution using merge modules

Post by numerobis »

Thanks, I appreciate it!
User avatar
Ivan - Tracker Software
Site Admin
Posts: 3549
Joined: Thu Jul 08, 2004 10:36 pm
Location: Vancouver Island - Canada
Contact:

Re: Printer driver distribution using merge modules

Post by Ivan - Tracker Software »

Do you try to install on 32- or 64-bit Windows?

Please note you have to install 64-bit MSM (Driver6_MSM_x64.msm) on 64-bit Windows and 32-bit MSM (Driver6_MSM_x86.msm) on 32-bit Windows respectively.
In a case of EXE installer (PDFX6SA_sm.exe), it handles it automatically.
Tracker Software (Project Director)

When attaching files to any message - please ensure they are archived and posted as a .ZIP, .RAR or .7z format - or they will not be posted - thanks.
numerobis
User
Posts: 7
Joined: Wed Aug 24, 2016 3:22 pm

Re: Printer driver distribution using merge modules

Post by numerobis »

Hello!

Ivan, you are right about the platform conflict between 32/64-bit Windows. I've been testing it on a 64-bit Windows, but using the x86 merge module, which throws the "HRESULT E_FAIL.." error mentioned above. Merging the x64 merge module, my application runs without errors. So now I tried to integrate the x64 merge module into a x86 WiX project, which fails with the following error:

Code: Select all

error LGHT0345: 'C:\Users\numerobis\Documents\Visual Studio 2015\Projects\Numerobis\\SetupNumerobis\Components\PDF-XChange\Driver6_MSM_x64.msm' is a 64-bit merge module but the product consuming it is 32-bit. 32-bit products can consume only 32-bit merge modules.
So from testing I receive the following "compatibility" chart:

Code: Select all

-------------------------------+-----+-----+-----
Windows:                    32 |  64 |  64 |  64
Our software:              x86 | x86 | x86 | x64
PDF-XChange Merge Module:  x86 | x86 | x64 | x64
-------------------------------+-----+-----+-----
Works:                     Yes | No1 | No2 | Yes
*No1: Error HRESULT E_FAIL.. (runtime)
*No2: Error LGHT0345 (compile time)

At the moment it seems that using the merge module we can only create an x86 application for a 32-bit Windows, and an x64 application for a 64-bit Windows, but not an x86 application for 64-bit Windows. Do you know any possibility to achieve the x86 application for 64-bit Windows with one of your merge modules, or is our only possibility to employ the EXE installer? (please read on before you answer...)

Note: everything from this point on has only been tested on a clean installation of a 32-bit Windows 7. I restarted it after every installation process.

I've been playing around with different installation scenarios and noticed a little problem. Say we have two software products that both require the printer driver. Software "A:EI" installs the PDF-XChange printer driver using the EXE installer, software "B:MM" installs it using the merge module.
Initial environment: Software A:EI and B:MM are both installed (installation sequence is not vital, tried both: A first, B second, and vice versa).
Event 1: B:MM gets uninstalled (keeping A:EI).
Event 2: A:EI gets uninstalled (keeping B:MM).

Running my test application in the initial environment yields no errors. Running it after either event 1 or 2 results in the following error being thrown:

Code: Select all

#### Error: Retrieving the COM class factory for component with CLSID {636AC372-D9F0-4548-8B67-E53795556624} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
Some observations:
  • The EXE installer doesn't recognize an installation through the merge module nor the presence of itself being installed already. In both cases it simply reinstalls the printer driver.
  • There is a difference where the printer driver files are being installed. The merge module installs them into the folder "C:\PDF-XChange 6\", while the EXE installer installs them in "C:\Program Files\Tracker Software\PDF-XChange 6\". Both have a slightly different folder structure and set of files.
  • As far as I understand the windows installer, it has a reference count mechanism to check which shared components are being used by which installed programs. I haven't tested it yet, but I assume this works with the merge module: n different applications installing the printer driver through the merge module results in one installation of the printer driver. It only gets uninstalled once the last application referencing it gets uninstalled, independent of the uninstallation sequence. The stand-alone EXE installer doesn't seem to be synchronized with the merge module (different files and file locations, but same registry keys), thus not noticing that other applications are still depending on it.
These problems are vital for us, as our clients run other software products apart from ours that depend on the PDF-XChange printer driver. For the time being, I have decided to use the EXE installer, and run a check upon startup of our software whether or not the printer driver hasn't been uninstalled by any other product. This approach also eliminates the 32-/64-bit Windows question from above. I'd be happy if you could either confirm or refute my comments/observations and advise about a solution to the problems described above. In the PDF-XChange documentation I've read that you recommend the EXE installer as the best practice of deploying the printer driver. Yet this doesn't work well in an environment with multiple independent applications depending on it. The "printer driver presence check" isn't a nice solution either.

Thank you for your time and hope we can find a good solution! :)
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17820
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: Printer driver distribution using merge modules

Post by Tracker Supp-Stefan »

Hello numerobis,

I've just spoken with Ivan, and these are the comments we have:

We tried using the MSI installers to make 32-bit MSI with two merge modules, but, as far as we saw it will not work.
Unfortunately it seems like you will have to create three MSIs to cover all possible cases:

- A pure 32-bit for 32-bit Windows
And two 64-bit MSIs for 64-bit Windows:
- One with your app in 64-bit mode and
- A second one for 32-bit version of your app.

We are also going to tey and see if we can work with our EXE installer to implement some kind of installation counter. But this will take into account only your own counters, not MSI's ones.

Regards,
Stefan
Post Reply