Issue with viewing thumbnail in linux environment for GroupDocs.Conversion version: 23.1.0

GroupDocs.Conversion Product Family
1

GroupDocs.Conversion 23.1.0 fails on Linux/.NET 8 with Gdip type initializer exception

Environment

  • GroupDocs.Conversion version: 23.1.0

  • GroupDocs.Viewer version: 23.6.0

  • GroupDocs.Merger version: 22.12.0

  • Target framework: .NET 8

  • OS: Linux

  • Also referencing: SkiaSharp 2.88.6 directly in the host project

Problem

Calling Converter.Convert(...) with ImageConvertOptions to generate a document thumbnail throws:

GroupDocs.Conversion.Exceptions.GroupDocsConversionException
The type initializer for 'Gdip' threw an exception.
at d.()
at GroupDocs.Conversion.Converter.()
at GroupDocs.Conversion.Converter.Convert(SaveDocumentStream document, ConvertedDocumentStream documentCompleted, ConvertOptions convertOptions)

This only occurs on our Linux-hosted environment; the same code works fine on Windows.

What we’ve already established

  • System.Drawing.Common is fully blocked on non-Windows platforms as of .NET 7+ (the System.Drawing.EnableUnixSupport runtime switch was removed in .NET 7 and has no effect on .NET 8). We confirmed via runtimeconfig.json inspection that the switch produces no change in behavior.

  • We noticed GroupDocs.Conversion 23.1.0’s own NuGet dependency list includes SkiaSharp and SkiaSharp.NativeAssets.Linux.NoDependencies, suggesting Skia is used for at least some rendering — but the crash trace shows the failure originating inside GroupDocs.Conversion.Converter.Convert(...) itself, which strongly suggests some part of the ImageConvertOptions/thumbnail rendering path still depends on System.Drawing.Common/GDI+ internally.

  • We also separately confirmed (via dotnet restore) that System.Drawing.Common resolves to version 6.0.0 in our final dependency graph (pulled in by an unrelated package, not GroupDocs), which is the last version that still supports the EnableUnixSupport opt-in switch (pre-.NET-7 removal) — but we have not yet confirmed whether libgdiplus is installed on our Linux host, or whether that combination would actually resolve this.

Questions

  1. For GroupDocs.Conversion 23.1.0 specifically, is ImageConvertOptions/thumbnail generation expected to work on Linux/.NET 8 at all, or does it require System.Drawing.Common internally regardless of the SkiaSharp dependency?

  2. Is GroupDocs.Conversion.CrossPlatform (which we understand uses SkiaSharp + Aspose.Drawing instead of System.Drawing.Common) the recommended fix for this? If so, is it a true drop-in replacement (same namespaces/API) for GroupDocs.Conversion 23.1.0’s usage, or does upgrading to the CrossPlatform package require jumping to a specific minimum version (e.g. 24.3.0+) with other breaking changes we should be aware of?

  3. Does our existing GroupDocs.Total.NET license file cover the CrossPlatform package variant, or does it require separate licensing/activation?

  4. If we stay on the non-CrossPlatform GroupDocs.Conversion package, would pinning System.Drawing.Common to exactly 6.0.0 plus System.Drawing.EnableUnixSupport=true plus installing libgdiplus on the host actually resolve this for the ImageConvertOptions path specifically, or does 23.1.0’s internal usage require an even narrower/different fix?

Happy to share a minimal repro project if useful.

2

ello @SrinivasSama,

Thanks for the detailed write-up — it made this much quicker to look into. We reproduced the failure on .NET 8 on Linux with 23.1.0, so there’s no need for the repro project unless something below doesn’t match your setup.

  1. Your reading is right. In 23.1.0 the ImageConvertOptions rendering path goes through System.Drawing.Common, and no option or setting routes it elsewhere on that version. SkiaSharp is used, just not for this path. So on Linux, 23.1.0 needs GDI+ present and enabled.

  2. You’re right that CrossPlatform is the cross-platform build, but it’s no longer how you get it. It arrived in 24.3 as a separate package holding a .NET 6 assembly for Windows, Linux and macOS. From 25.1 that same .NET 6 cross-platform build became the regular GroupDocs.Conversion package, which is why CrossPlatform stops at 24.12.0 — a separate package was no longer needed.

    To answer your minimum-version question directly: 25.1.0, not 24.3.0. We’d suggest going to the current release rather than the minimum, though — see the end.

    It isn’t a drop-in from 23.1.0, so do plan for that. The stream-based Convert overload has changed twice since your version:

    23.1.0   Convert(SaveDocumentStream, ConvertedDocumentStream, ConvertOptions)
24.x     Convert(Func<Stream>, Action<string, FileType, Stream>, ConvertOptions)
25.x+    Convert(Func<SaveContext, Stream>, ConvertOptions, CancellationToken)

    The GroupDocs.Conversion.Contracts delegate types in your stack trace don’t exist in the later versions. Two things that’ll save you time on 25.x and above: pass the delegate type explicitly, because Func<SaveContext, Stream> and Func<SavePageContext, Stream> are ambiguous for an untyped lambda. And the library closes the stream you return, so write to your destination inside the provider rather than buffering into a MemoryStream and reading it back after Convert returns.

  3. Your existing GroupDocs.Total licence covers it. No separate licence file or activation step for any of these package variants.

  4. It does work, and we verified it end to end — 23.1.0 on .NET 8 on Linux, generating thumbnails from both PDF and DOCX sources. Two things have to be true at once:

    • libgdiplus installed on the host
    • System.Drawing.EnableUnixSupport set to true

    Neither works on its own, and we suspect that’s what happened in your testing. A missing libgdiplus produces the same Gdip type-initializer error as the switch being off, so enabling the switch on a host without the native library looks exactly like the switch doing nothing. You mentioned you hadn’t confirmed libgdiplus was installed, so that’s worth checking before ruling the switch out.

    On the .NET 7 point, the Unix implementation was dropped from System.Drawing.Common 7.0.0, not from the runtime. The package ships independently of the framework, so an app resolving 6.0.0 still honours the switch on .NET 8. You don’t need to pin it either — 6.0.0 is already what resolves in that graph.

    Fonts matter too. Install ttf-mscorefonts-installer or equivalent and run fc-cache -f, otherwise the PDF path fails with “No suitable system fonts found”, which looks like a rendering fault but isn’t.

What we’d recommend. Go to 26.7.0, the current release. We tested your scenario on it — PDF and DOCX to PNG thumbnails, .NET 8, Linux, with no libgdiplus on the host at all — and both convert. If your application also converts images into documents, let us know before upgrading and we’ll advise on that direction separately.