Hi,
I’m encountering a runtime exception when attempting to convert documents using GroupDocs.Conversion.CrossPlatform on an Azure Linux App Service (.NET 8).
Despite using the CrossPlatform package, conversions fail with the following error:
System.Drawing.Common is not supported on this platform.
GroupDocs.Conversion.Exceptions.GroupDocsConversionException: System.Drawing.Common is not supported on this platform.
---> System.PlatformNotSupportedException: System.Drawing.Common is not supported on this platform.
at System.Drawing.Drawing2D.Matrix..ctor(...)
...
at Aspose.Html.HTMLDocument.RenderTo(IDevice device)
...
at GroupDocs.Conversion.Converter.Convert(...)
From the stack trace, it appears the conversion pipeline (via Aspose.Html) is invoking System.Drawing.Common. On Linux App Service, this results in PlatformNotSupportedException, and Azure App Service does not allow installing system dependencies like libgdiplus.
Environment
- Azure App Service (Linux)
- .NET 8
- GroupDocs.Conversion.CrossPlatform
- No ability to install OS-level packages (standard App Service limitations)
Questions
- Is
System.Drawing.Common expected to be used internally by the CrossPlatform library for certain conversions?
- Are there supported configurations or rendering backends that avoid
System.Drawing entirely on Linux?
- Is there official guidance for running GroupDocs.Conversion.CrossPlatform on Azure Linux App Service without Docker?
- If not, which conversion scenarios are guaranteed to work headlessly (without System.Drawing)?
Any clarification or recommended deployment approach would be greatly appreciated.
Thank you.
@systemsv
You’re encountering a System.PlatformNotSupportedException for System.Drawing.Common while running GroupDocs.Conversion.CrossPlatform on an Azure Linux App Service.
To investigate this further, could you provide:
- The exact source and target formats you are converting when the exception occurs (e.g., HTML → PDF, DOCX → PNG).
- The full version number of GroupDocs.Conversion.CrossPlatform (and any Aspose.Html package) referenced in your project file.
- The code snippet you use to create and configure the
Converter, including any custom ConversionOptions or rendering settings.
With this information we can reproduce the scenario and determine the appropriate configuration or workaround. Please share the details here, and we’ll continue the investigation in this thread.
Source and target formats:
HTML → PDF
GroupDocs.Conversion.CrossPlatform Version:
24.12.0
Code snippet:
var converter =
new Converter(
() => new MemoryStream(Encoding.UTF8.GetBytes("<html><body>Test html</body></html>")),
loadOptions: (LoadContext _) => new WebLoadOptions(),
() => new ConverterSettings());
var convertOptions = new GroupDocs.Conversion.Options.Convert.PdfConvertOptions();
Action<ConvertedContext> onCompleted = context =>
{
context.ConvertedStream.CopyTo(convertedStream);
convertedStream.Position = 0;
};
converter.Convert(
convertOptions: convertOptions,
documentCompleted: onCompleted,
cancellationToken: default
);
Hello @systemsv ,
Thank you for your interest in our product and for the detailed description of your use case. Could you please confirm whether the following libraries are installed on your Linux system: libgdiplus and fontconfig?
For our library to function correctly on Linux systems, there are certain mandatory dependencies, which are described in our documentation. Before forwarding your use case to our development team for investigation, we would like to ensure that all required instructions have been followed.
We would like to run this app as an Azure Linux App Service which doesn’t allow the installation of libraries not already part of the default. libgdiplus is not a default installed library.
Is there any reason why System.Drawing.Common is still being referenced by GroupDocs.Conversion.CrossPlatform when Microsoft recommends using another solution for drawing such as Aspose.Drawing and SkiaSharp?
Is this planned for any future release, and if so, is there a timeline on that?
@systemsv ,
Yes, our team is moving in the direction of phasing out the use of System.Drawing, and in some cases conversions of certain formats are already handled using Aspose.Drawing.
Unfortunately, we are not able to provide any specific timelines for fully resolving this situation at the moment. This is because some of our third-party dependencies still rely on System.Drawing (in particular, the library responsible for HTML to PDF conversion), and it is difficult to estimate the overall effort required and share a reliable timeframe.
As a possible workaround, if feasible on your side, we would recommend testing our standard (non-cross-platform) library. This version uses a newer library for HTML to PDF conversion, and it may help you avoid this issue.
Additionally, could you please share more details about your conversion use case? HTML to PDF, is this the primary conversion scenario you rely on, or do you also work with other formats? If so, which ones? Based on your response, we will be able to proceed with further investigation and may be able to provide an estimated timeline.