PDFNetDotNetCore in Azure Functions V2

Technical Support Apryse SDK
1

I am tying to deploy a function consuming PDF Net .NET Core. It runs fine on the local emulator. When I deploy to Azure I get the following:

System.DllNotFoundException: Unable to load DLL ‘PDFNetC’ or one of its dependencies: A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)
at pdftron.PDFNetPINVOKE.TRN_PDFNetInitialize(String lic_key)
at PDFNetTester.Core.Win.PDFDocumentBuilder.DoIt(Stream outputStream) in C:\Junk\PDFNetTester.Core\PDFNetTester.Core.Win\PDFDocumentBuilder.cs:line 21
at PDFNetTester.Core.Win.PDFBuilderFunction.Run(HttpRequest req, ILogger log) in C:\Junk\PDFNetTester.Core\PDFNetTester.Core.Win\PDFBuilderFunction.cs:line 30

The function is x86.
Target .NET Core 2.1
The correct PDFNetC.dll is deployed.
VS 2010 runtime .dlls on the path are:

D:\Windows\System32\msvcp100.dll

D:\Windows\System32\msvcr100.dll

D:\Windows\System32\msvcr100_clr0400.dll

D:\Windows\System32\msvcrt.dll

I am providing a license key.

Notice the init function failed, not file not found. Any Ideas?

2

It seems PDFNetC.dll is not in a folder location that the process is checking.

You will need to make sure the two DLL’s mentioned in the following guide are included.
https://www.pdftron.com/documentation/windows/guides/dotnetcore

Also, please note that our .Net Core SDK does not have any C++ runtime dependency.

Please let us know if this resolves your issue or if you have any questions.

3

I checked that already. It is there.
Output from Kudu Console is attached.

Azure functions run in a sandbox. Access to parts of Windows, like the GDI, are restricted. I am trying to so some basic operations that should not require the GDI. Right now it’s not loading (notice it does not say File Not Found).

The sandbox is described here:
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox

PDFNETCIsThere-Kudu.png

4

Assuming that wwwroot/bin is the correct folder, where your server process will look to resolve runtime dependencies, then I suspect the issue is that you are mixing up 32bit and 64bit.

You can check at runtime what your process is using this logic.

private static bool Is64BitProcess() { return IntPtr.Size == 8; }

The PDFNetC.dll needs to match the 32/64bitness of your process.

5

The calling code,PDFNetTester.Core.Win.dll is listed there, too. It’s in the stack trace, too.

I added the following to the function code:

log.LogInformation($“Environment.Is64BitProcess = {Environment.Is64BitProcess.ToString()}”);
log.LogInformation($“Is64BitProcess, old skool = {(IntPtr.Size == 8).ToString()}”);
log.LogInformation($“Environment.Is64BitOperatingSystem = {Environment.Is64BitOperatingSystem}”);

It produces the following in the portal:

2019-02-01 16:23:35.733 |
Environment.Is64BitProcess = False
| Information |

  • | - | - |
    2019-02-01 16:23:35.733 |
    Is64BitProcess, old skool = False
    | Information |
    2019-02-01 16:23:35.734 |
    Environment.Is64BitOperatingSystem = True
    | Information |

The error is DLL initialization failed, not Bad Image Format. I get that when I induce the error with the x64 PDFNetC.dll

System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at pdftron.PDFNetPINVOKE.TRN_PDFNetInitialize(String lic_key)
at PDFNetTester.Core.PDFDocumentBuilder.DoIt(Stream outputStream) in C:\Junk\PDFNetTester.Core\PDFNetTester.Core.Win\PDFDocumentBuilder.cs:line 21
at PDFNetTester.Core.Win.PDFBuilderFunction.Run(HttpRequest req, ILogger log) in C:\Junk\PDFNetTester.Core\PDFNetTester.Core.Win\PDFBuilderFunction.cs:line 33

I notice that in the 6.9.0 distribution packages Win x86, Win x64, Linux x86, Linux X64 the following:

  • The version of PDFNetDotNetCore.dll is 6.8.5.0, not 6.9.0. Does that matter?
  • The 4 PDFNetDotNetCore.dll’s are different, Are these platform and processor specific? They are the same size, but when compared using fc /b there are differences
  • The Samples, Getting Started document and libinfo.txt make no mention of .NET Core

In the linux packages, libPDFNetC.so is an empty file. I assume I have to rename “libPDFNetC.so.6.9.0” to “libPDFNetC.so” to get this to work on Linux

6

I submitted a paid support request:

The PDFNetC.dll is failing to initialize when deployed to Azure. The PDFNetC DllInit function is failing.

Azure functions run in a sandbox. Access to parts of the Windows API, like user32 and GDI, are restricted. I am trying to so some basic operations that should not require the GDI.

The sandbox is described here:

https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox

Is the init function doing anything that would get it in trouble with the sandbox?

I got the following answer:

Hello John,

Thank you for the clarifications. It appears that there is a static load of a GDI handle in our Windows SDK.

7

I have this same problem. I have submit a ticket to Microsoft on the topic, but was wondering if there is any plan or status of getting PDFTron for .NET Core to work in Azure functions. Even a long term road-map.

8

This is a huge problem for us. We had to switch to the App Service plan for PDFTron stuff to work instead of consumption plan. The difference in scaling is absurdly bad, as in not even comparable.

For now what we have works, but I would love to see one or the other change to accommodate this.

9

were you able to run pdftron on linux env ?