Skip to content

fix: default-enable System.Drawing.EnableUnixSupport for .NET (Core) consumers - #842

Closed
cassianomansano wants to merge 1 commit into
FastReports:masterfrom
cassianomansano:patch/enable-unix-support-by-default
Closed

cassianomansano wants to merge 1 commit into
FastReports:masterfrom
cassianomansano:patch/enable-unix-support-by-default

Conversation

@cassianomansano

Copy link
Copy Markdown

Problem

The engine is built on System.Drawing.Common/GDI+ (see _FR_GraphicsEngine = GDIPlus in Pack/FastReport.OpenSource/build/FastReport.OpenSource.props). Since .NET 6, that package throws PlatformNotSupportedException on any non-Windows host unless the app sets the System.Drawing.EnableUnixSupport AppContext switch itself. Nothing in this repo sets or documents that switch, so every consumer on Linux hits the exception with zero indication why — this is a real, structural risk for the "cross-platform .NET 6" claim in the README, not just a theoretical one.

Fix

Patch the MSBuild props file this repo already ships inside the FastReport.OpenSource NuGet package (Pack/FastReport.OpenSource/build/FastReport.OpenSource.props) to add:

<ItemGroup Condition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'">
  <RuntimeHostConfigurationOption Include="System.Drawing.EnableUnixSupport" Value="true" Trim="false" />
</ItemGroup>

This flows transitively into any .NETCoreApp consumer's runtimeconfig.json with zero action on their part. No-op on Windows (GDI+ is native there already).

This does not fully solve cross-platform support — Linux hosts still need libgdiplus installed natively for GDI+ calls to actually succeed once the exception is removed. It removes the silent, undocumented trap; it doesn't make GDI+ itself portable.

Validated locally before opening this PR

Packed the patched FastReport.OpenSource to a local NuGet feed, referenced it from a throwaway console app via nuget.config, and diffed the generated runtimeconfig.json against a second app referencing the official 2026.2.8 package from nuget.org:

official package (nuget.org)  → configProperties has no "System.Drawing.EnableUnixSupport" key
patched package (this PR)     → configProperties["System.Drawing.EnableUnixSupport"] = true

dotnet build of the full solution still succeeds with this change (Windows runner, same validation as #841).

Test plan

  • CI (once ci: add GitHub Actions build+test workflow #841 lands) builds this branch clean
  • Maintainers confirm this is the right layer to set the switch (vs. e.g. setting it in FastReport.Compat/FastReport.OpenSource.csproj directly) — open to moving it if there's a preferred spot

…T (Core) consumers

Not proposed upstream (yet) - this is a local-fork patch, kept independent
of the upstream review/merge cycle per our own CI PR backlog finding
(oldest open PR there is from 2024).

FastReport's engine is built on System.Drawing.Common/GDI+ (see the
_FR_GraphicsEngine=GDIPlus property right above this change). Since
.NET 6, that package throws PlatformNotSupportedException on any
non-Windows host unless an app-level AppContext switch is set - every
consumer of the official package hits that exception on Linux with zero
indication why, since nothing in this repo sets or documents the switch.

This patches the NuGet build-props shipped inside the FastReport.OpenSource
package (Pack/FastReport.OpenSource/build/FastReport.OpenSource.props) to
set RuntimeHostConfigurationOption System.Drawing.EnableUnixSupport=true
for any .NETCoreApp consumer, transitively, with no action required on the
consumer's part. No-op on Windows.

Does NOT fix the deeper issue: Linux hosts still need libgdiplus installed
natively for GDI+ calls to actually succeed once the exception is gone.

Validated locally end-to-end (packed to a local feed, consumed from a
throwaway console app, compared runtimeconfig.json against the official
2026.2.8 package from nuget.org):

  official package  -> configProperties has no System.Drawing.EnableUnixSupport key
  patched package    -> configProperties["System.Drawing.EnableUnixSupport"] = true
@cassianomansano

Copy link
Copy Markdown
Author

Fechando pelo mesmo motivo do #841 — spike técnico, não PR real.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant