Skip to content

26.7.2

Choose a tag to compare

View all tags
@github-actions github-actions released this 24 Jul 12:02
26.7.2
985298b

26.7.2 — Revert the GDI+ resolver added in 26.7.1 (regression)

What changed

  • Removed GdiPlusResolver and its GdiPlusResolver.Register() call from Program.cs. This reverts the change shipped in 26.7.1.
  • Bumped the MCP package version from 26.7.1 to 26.7.2, including .mcp/server.json (both version fields).

Why

26.7.1 registered a DllImportResolver on System.Drawing.Common to map gdiplus.dll to libgdiplus. That was wrong on two counts and made Linux strictly worse:

  1. Wrong assembly. SetDllImportResolver is per-declaring-assembly. The gdiplus.dll P/Invoke is declared in System.Private.Windows.Core (System.Drawing.Common 9.x's CsWin32 interop layer), not in System.Drawing.Common — so the resolver was never consulted for the failing load.

  2. It broke the type initializer. System.Drawing.Common registers its own resolver inside the System.Drawing.Gdip static constructor. Because 26.7.1 claimed that slot first, Gdip's cctor threw InvalidOperationException: A resolver is already set for the assembly, which escaped the type initializer and disabled System.Drawing entirely:

    TypeInitializationException: Windows.Win32.PInvoke
  → TypeInitializationException: System.Drawing.Gdip
    → InvalidOperationException: A resolver is already set for the assembly

Reverting restores the pre-26.7.1 behaviour on Linux (see the known limitation below). Windows was unaffected throughout — the resolver was a no-op there.

Known limitation — compare / analyze_changes on Linux and macOS

Verified by reproducing the failure in a linux/amd64 container against engine 26.5.0:

  • libgdiplus loads fine; the library was never missing. .NET probes only gdiplus.dll(.so) / libgdiplus.dll(.so) and never plain libgdiplus.so.
  • On net10.0 the engine resolves GroupDocs.Comparison.Net100, which depends on System.Drawing.Common 9.0.3. That package is Windows-only since .NET 7 — with the DllImport correctly resolved it simply throws PlatformNotSupportedException: System.Drawing.Common is not supported on non-Windows platforms.
  • Neither adding Aspose.Drawing nor retargeting to net8.0 (GroupDocs.Comparison.Net80 → System.Drawing.Common 8.0.0) avoids it; both fail the same way.

So comparing two different documents — which renders marked-up output — cannot work on non-Windows with engine 26.5.0. Comparing identical documents, and get_document_info, are unaffected. This is an upstream engine limitation, not something the MCP layer can work around; it needs GroupDocs.Comparison to migrate its render path off System.Drawing.Common (as GroupDocs.Metadata already has, via Aspose.Drawing).

The inert System.Drawing.EnableUnixSupport runtime flag is retained only as a marker; it has been a no-op since System.Drawing.Common 7.0.

Migration / impact

Drop-in replacement for 26.7.1, and the recommended upgrade from it. No tool-name, input-schema, or response-shape changes. Windows behaviour is unchanged; Linux/macOS return the original System.Drawing error instead of the resolver-conflict error.

Full Changelog: 26.7.1...26.7.2

Assets 3
Loading