Linux runtime failure

[Ryan Robar]

On this page you state that Stimulsoft.Web is cross-platform. We are in the process of upgrading from 2020.5.1 to 2024.3.4 but post upgrade we started seeing failures from some of our unit tests that run on Linux. The test is causing the following error:

System.PlatformNotSupportedException: System.Drawing.Common is not supported on non-Windows platforms.

It seems from this that the product still has dependencies on System.Drawing which is only supported in Windows as of .NET 7. Is there a way to work around this? If not, do you have a timeline for when all System.Drawing dependencies will be removed? I found a blog post on your site discussing your Stimulsoft.Drawing library so I'm assuming this change is at least in progress, which is appreciated. Please advise on how we should proceed here. Thankfully this code seems to work fine in Windows and all production servers are running Windows, so this is currently only affecting our tests. We are planning to to become cross platform though, and this is the only major issue preventing that.

PS: If your team is having difficulties dropping these dependencies, you may want to check out IronDrawing. It claims to be a free, open-source replacement for System.Drawing.

Thanks,

Ryan

[Lech Kulikowski]

Hello,

Please check the following article:
https://www.stimulsoft.com/en/blog/arti ... ng-library

Thank you.

[Ryan Robar]

Hello,

I've already read that post. When I said this:

I found a blog post on your site discussing your Stimulsoft.Drawing library so I'm assuming this change is at least in progress, which is appreciated.

I was referring to that post. It doesn't address my question about your timeline for fully removing System.Drawing, and switching to the GDI+ engine only works in Windows so that isn't a valid workaround in a non-Windows environment. I would appreciate it if you could speak to one or both of those issues.

Thanks

[Lech Kulikowski]

Hello,

This new engine is constantly being improved and developed. From the 2022.3 release were a lot of fixes, improvements, and optimizations. You can use it as a cross-platform solution.

Thank you.

[Ryan Robar]

Hello,

I'm not questioning whether or not your team is working on fixing or improving your product. I'm just trying to get an idea of when these System.Drawing dependencies will be removed so that it can be fully used cross-platform. This test failure has raised concern among members of my team about continuing to use your product. As I stated in my original post we are planning to go cross-platform and this is currently our main obstacle to doing so.

Essentially what I need is some kind of timeframe I can use to reassure my employer that your product is something we can rely on long term and that we don't need to look for a replacement. I'm not asking for a specific date for when the dependencies will be removed, a general timeframe would suffice.

Thanks

[Lech Kulikowski]

Hello,

Everything works fine on linux, we transferred the functionality to SixLabors.
Only some features are not implemented, for example, printing on the server - but this is only through System.Drawing, otherwise there is no other way.

Maybe we don't quite understand the problem. What exactly you have an error, please describe the problem in more detail.

Thank you.

[Ryan Robar]

Hello,

I feel like there's a contradiction in your post. First you say everything works fine, then you say some features aren't implemented. I'm not sure how both of those can be true.

We generate PDF files from compiled report templates on the server (using the StiReport's ExportDocument method) and then either serve them to the user directly in their browser or put them into a database so that they can be viewed later. We do not use any of your client side browser tools. When we try to do this in Linux we get the System.Drawing error shown in my original post. If using the ExportDocument method counts as "printing on the server" then I would say that's exclusively how we use your product.

I hope this helps explain where this issue is coming from.

Thanks

[Lech Kulikowski]

Hello,

> I feel like there's a contradiction in your post. First you say everything works fine, then you say some features aren't implemented. I'm not sure how both of those can be true.

Maybe we have not described it accurately. Everything that concerns generation of reports and exports (with standard settings) should work.
Printing is a completely different functionality.

> We generate PDF files from compiled report templates on the server (using the StiReport's ExportDocument method) ..... When we try to do this in Linux we get the System.Drawing error shown in my original post. ...

Please specify which export settings you are using.
Also, what StiOptions settings you are using, some of these properties only work on Windows.

Thank you.

[Ryan Robar]

Hello,

Alright, we never print your reports directly, so that shouldn't be the issue. We always export to PDF using these settings:

Code: Select all

private static readonly StiPdfExportSettings _exportSettings = new()
{
    AllowEditable = StiPdfAllowEditable.Yes,
    PdfComplianceMode = StiPdfComplianceMode.A1,
    EmbeddedFonts = true,
    ImageQuality = 1f,
    ImageResolution = 600
};

The only StiOption I can see being set is StiOptions.Engine.Image.AbsolutePathOfImages being set to a specific folder. The failure seems to be happening before trying to render the report, so I'm not sure any of that will be helpful. Based on the exception it looks to be something to do with constructing a font or font family:

Code: Select all

System.TypeInitializationException: The type initializer for 'Gdip' threw an exception.
	 ---> System.PlatformNotSupportedException: System.Drawing.Common is not supported on non-Windows platforms. See https://aka.ms/systemdrawingnonwindows for more information.
	   at System.Drawing.SafeNativeMethods.Gdip.<>c.<.cctor>b__2_0(String _, Assembly _, Nullable`1 _)
	   at System.Runtime.InteropServices.NativeLibrary.LoadLibraryCallbackStub(String libraryName, Assembly assembly, Boolean hasDllImportSearchPathFlags, UInt32 dllImportSearchPathFlags)
	   at System.Drawing.SafeNativeMethods.Gdip.<GdiplusStartup>g____PInvoke|32_0(IntPtr* __token_native, StartupInputEx* __input_native, StartupOutput* __output_native)
	   at System.Drawing.SafeNativeMethods.Gdip.GdiplusStartup(IntPtr& token, StartupInputEx& input, StartupOutput& output)
	   at System.Drawing.SafeNativeMethods.Gdip..cctor()
	   --- End of inner exception stack trace ---
	   at System.Drawing.SafeNativeMethods.Gdip.GdipCreateFontFamilyFromName(String name, HandleRef fontCollection, IntPtr& FontFamily)
	   at System.Drawing.FontFamily.CreateFontFamily(String name, FontCollection fontCollection)
	   at System.Drawing.FontFamily..ctor(String name, Boolean createDefaultOnFail)
	   at System.Drawing.Font.Initialize(String familyName, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont)
	   at System.Drawing.Font..ctor(String familyName, Single emSize, FontStyle style)

I'm not sure why it would be doing that if all of the System.Drawing dependencies have been removed. Hopefully this helps narrow down the source of the problem.

[Lech Kulikowski]

Hello,

We don't see our libraries used in the stack. Most likely, your test just creates a standard font from System.Drawing.
But our libraries use other wrapper classes for graphical objects.

Thank you.