XLSX-to-PDF conversion fails on Azure Functions with GroupDocs.Conversion 26.10.0 — libSkiaSharp cannot be loaded

GroupDocs.Conversion Product Family
1

Hello GroupDocs Support,

We are experiencing an XLSX-to-PDF conversion failure using GroupDocs.Conversion for .NET 26.10.0 in an Azure Function App.

The conversion succeeds when running the function locally, but fails after deployment to Azure. The environment in which it fails has the following details:

Application: Azure Functions v4, .NET isolated worker
Target framework: .NET 10
Azure hosting OS: Windows
GroupDocs.Conversion: 26.10.0
SkiaSharp and SkiaSharp.NativeAssets.Win32 versions: 4.152.1

Steps to reproduce:

Deploy the Azure Function App.
Trigger conversion of an XLSX document to PDF.
Conversion fails during the underlying Aspose.Cells workbook save operation.

The following exception is thrown:

GroupDocs.Conversion.Exceptions.MissingDependencyException:
Cannot convert. A required component is not available in the
application's output. Install the native library it needs on the machine.

 ---> System.TypeInitializationException:
The type initializer for 'SkiaSharp.SkiaApi' threw an exception.

 ---> System.DllNotFoundException:
Unable to load DLL 'libSkiaSharp' or one of its dependencies:
The specified module could not be found. (0x8007007E)

   at SkiaSharp.SkiaApi.sk_version_get_milestone()
   at SkiaSharp.SkiaSharpVersion.get_Native()
   at SkiaSharp.SkiaSharpVersion.CheckNativeLibraryCompatible(...)
   at SkiaSharp.SkiaApi..cctor()
   at Aspose.Cells.Workbook.Save(Stream stream, SaveOptions saveOptions)v

We recently upgraded from GroupDocs.Conversion 26.7.0 to 26.10.0. Comparing the resolved dependencies shows that SkiaSharp changed from 3.119.2 to 4.152.1. Excel conversion was working before this upgrade (although 26.7.0 had an error with a missing dependency on Aspose.Drawing, which is fixed in 26.10.0).

Are you able to help with this and answer the following questions:

Do you know if this a known issue with GroupDocs.Conversion 26.10.0 or its SkiaSharp 4.152.1 dependency in Windows Azure Functions?
Are there additional native prerequisites required by this version that might be present locally but absent from Azure’s managed Windows environment?
Is an explicit win-x64 or win-x86 publish required?
Is there a supported workaround or updated GroupDocs release that addresses this failure?

Please let us know which additional diagnostics would help identify the cause, or if you need any other additional information.

Kind regards,

Malcolm

2

Hello @engagelicencing,

Thank you for the detailed report and for comparing the resolved dependencies, that saved us some time. We have logged this in our tracking system under the ID CONVERSIONNET-8739.

We’ve tested this on our side with GroupDocs.Conversion 26.10.0 in an Azure Functions v4 .NET 10 isolated worker on Windows hosting. The XLSX to PDF conversion completed fine on both 64-bit and 32-bit workers with SkiaSharp 4.152.1. So to your first questions: we don’t see a general problem with 26.10.0 or SkiaSharp 4.152.1 on Windows Azure Functions. The native libSkiaSharp.dll in 4.152.1 depends only on standard Windows system libraries, and it ships in the runtimes/win-x86, runtimes/win-x64 and runtimes/win-arm64 folders of the package. An explicit win-x64 or win-x86 publish is not required.

What we did reproduce is the same class of error (“file not found” for a library that is actually in the package) when the app runs from a deployment package and the instance runs out of local temporary storage. In that mode Windows copies each DLL to the instance’s local disk before loading it. If that space is used up, the load fails as if the file weren’t there. Which library fails depends on how much space is left, which would also explain why 26.7.0 reported Aspose.Drawing and 26.10.0 reports libSkiaSharp.

To confirm whether this is what happens on your side, could you please share the following:

  • The hosting plan of the Function App (Consumption, Flex Consumption, Premium or an App Service plan, and the SKU).
  • The value of the WEBSITE_RUN_FROM_PACKAGE app setting, and how the app is deployed (Visual Studio, func CLI, zip deploy from CI).
  • The content of LogFiles/eventlog.xml from the Kudu console (Advanced Tools > Debug console), taken right after a failed conversion. We’re mainly interested in entries from ZipFS.

Once we have these, we’ll know if it’s the storage limit or something else, and we’ll follow up here.