Registration-Free Deployment with sub folder

[Dorwol]

Hello,

this is the file structure of my application:

<app-folder>\Appname.exe
<app-folder>\DepFiles\PDFXCview.exe
<app-folder>\DepFiles\PDFXCviewAx.dll
<app-folder>\DepFiles\resource.dat

If I edit the Manifest-file to set <file name="DepFiles\PDFXCviewAx.dll"> my application will start and I see also the PDF-viewer. But if I want to open any PDF, the application will crash with "Automation error". I think the problem is still, that the 3 Tracker-Viewer Files are not in the main folder of my application.

So my Question is: What do I have to change in the Manifest file, to tell it, the 3 Tracker-Viewer Files are in a subfoler (DepFiles)?

[Vasyl - PDF-XChange]

Hi Dorwol.

Sorry, but I have not found a way to do it. These files must be in one folder and I think - it's required for Registration-Free ActiveX technology...

Best
Regards.

[Dorwol]

> I have not found a way to do it. These files must be in one folder
OK. Bad luck. But Thank you for reply.

> I think - it's required for Registration-Free ActiveX technology...
No, it's not required for RegFree AX-Tech., because all other components I have in this sub folder "DepFiles" and my application works perfect, as long as I do not use your axviewer-component.

[m-files corporation]

Hi Vasyl & Dorwol,

I think I know why Dorwol's sub-folder approach is not working. The ActiveX control of PDF-XChange relies on two parts: the PDFXCviewAx.dll file and the PDFXCview.exe file. The way the use of registration-free COM is instructed to be used in PDF-XChange examples is fine for allowing the invokation of PDFXCviewAx.dll from e.g. a sub-folder. However, this DLL then internally launches PDFXCview.exe using CreateProcess, and does not specify a full path to it (or a working directory). This is something in which registration-free COM cannot help. In Dorwol's case, the attempt to launch PDFXCview.exe will fail because the current directory is Dorwol's EXE directory, which does not contain PDFXCview.exe.

Dorwol can probably work around the problem by setting the current directory of his process to the sub-folder when creating the ActiveX control. However, this is not the ideal solution, especially if the application is multithreaded (or if it is a COM DLL hosted by other processes as in my case).

The ideal solution would be for Tracker Software to make a small modification to how PDFXCview.exe is launched:

CURRENT WAY (based on disassembly):

PDFXCview.exe is launched with CreateProcess, with the lpCommandLine argument set to "PDFXCview.exe /Embedding". Also, the lpCurrentDirectory argument is NULL. I.e., neither a full path nor a working directory is specified, so CreateProcess will use the default mechanisms, including trying to find PDFXCview.exe in the current directory of the process (application EXE).

SUGGESTED WAY:

Change CreateProcess arguments to refer to PDFXCview.exe using a full path that refers to the same folder where the PDFXCviewAx.dll file is located. For extra safety for backwards compatibility, the following logic could be used in the implementation of PDFXCviewAx.dll:

1. Get the full path of PDFXCviewAx.dll by calling GetModulePath and passing it the module handle of PDFXCviewAx.dll (=> szFullPathDLL).

2. Use the directory portion of the path obtained in step 1 and compose a full path to PDFXCview.exe in the same folder (=> szFullPathEXE).

3. Check if the file with the ath szFullPathEXE exists. If yes, then use this full path in the CreateProcess call. If not, then use the old behavior and launch PDFXCview.exe without specifying any path (for backwards compatibility, although I don't know if this is necessary for any real situation).

Let me know if you need any additional information on this suggestion.

-Antti

[Stefan - PDF-XChange]

Many thanks for the comment Antti,

I will certainly pass this to Vasyl for consideration.

Best,
Stefan

[Vasyl - PDF-XChange]

Hi, All.

Let me know if you need any additional information on this suggestion.

You are right. It works, thanks for your suggestion.

Dorwol, please wait for next build with this small fix. Also you may try our technical build - look to private message I have sent to you...
Antti, you may look to your private message from me with link to technical build...

Best
regards.

[Dorwol]

@Vasyl
Thank you. Any yes, I can confirm - it works like a charm!

@Antti
A big special Thanks to you!

[Stefan - PDF-XChange]

A big thanks to Antti for the suggestion indeed!

And great to hear that the technical build is working for you Dorwol!

Cheers,
Stefan