ikvm
ikvm copied to clipboard
ikvmnet
Migrate away from System.Drawing.Common
Hi everyone,
Actually I have converted one of my .jar library into .NET Core library using IKVM ikvmc command, it is working fine in my .NET 6 WebApi project when I deploy the code in windows server. When I am trying to deploy it Linux box, this throwing error saying "System.Drawing.Common is not supported in this platform".
When I looked at the dependency assemblies, I found "System.Drawing.Common" version >= 6.0.0.0 is in IKVM package.
Since "System.Drawing.Common" stopped supporting to non windows platform after version 5.0.0.0, I don't have any option here.
Even if I put the "System.Drawing.Common" version 4.7.0, it doesn't accept, throws error saying "Could not load file or assembly 'System.Drawing.Common, Version=6.0.0.0".
Even though IKVM say it supports to Linux, I am not able to do it. May be I am missing something here.
Have anyone used IKVM in non windows OS? Please let me know what I am missing here.
Thank you
IKVM still depends on System.Drawing.Common for a few features, such as imagio plugins and a few font related things. A few of the AWT classes which are included depend on it as well, though AWT as a whole is mostly non-functional across all platforms.
Just depends on what you're doing in your library. You can't use those features on non-Windows.
You are also probably making this more difficult on yourself by trying to manually run ikvmc. Use IkvmReference as described in the README.
Thank you for your immediate response.
I am using IKVM to use Apache Fop in .NET which is a java library used to generate PDF documents.
If it still depends on System.Drawing.Common, then I assume I can't use it for non-Windows. Since the library which I am using is handling with font and image to product documents.
If I use IkvmReference, Will it help for my problem? or the result will be same as using ikvmc.
Thanks for your time.
I do not know. I don't know exactly what FOP does internally, but I bet it depends on the document.
It's someone we'd need at least stack trace for, to prioritize fixing.
As to IkvmReference: maybe. I was a little concerned when you mentioned version 4.7, as nothing should be passing that to ikvmc.
While I am using ikvmc, I am not passing any assembly dependency like System.Drawing.Common 4.7. this is installing in my application when I install IKVM from nuget only.
The output .NET dll from ikvmc is working fine in the same application when I deploy it in on-premise windows server. Now moving my application to AWS container, but it uses linux. then it is not working and getting the error "System.Drawing.Common is not supported in this platform"
Maybe you can try setting "System.Drawing.EnableUnixSupport": true, as per: https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/system-drawing-common-windows-only
Couldn't find an issue specifically tracking the System.Drawing.Common dependency, so renaming this one.
That would be orthogonal to the goal of getting native AWT support working.
For me it looks like pdfbox is trying to leverage some Java bitmap API which maps to it. I am using Apache Tika which uses pdfbox internally it seems, so when I read in a PDF... there you go.
EnableUnixSupport is working as a stopgap measure for me, though of course at the end of this year .NET 6, and thus the flag, go out of support by Microsoft.
Very weird to find System.Drawing.Common in use in a cross platform library. I guess it was integrated back when IKVM was .NET Framework? Or when System.Drawing.Common was cross platform?
I've looked at various graphics libraries before for Unity stuff. SkiaSharp, ImageSharp, and Magick.NET all seem like good candidates if you're looking for a replacement. I prefer ImageSharp myself. No native library and the license should be favorable for a FOSS project like this (I think it allows usage as a dependency so IKVM users don't have to worry about the restrictions its license has on commercial use without a paid license).
If that license doesn't agree with you the MIT licensed SkiaSharp + its native libraries for various platforms would be my next recommendation.
We are all waiting patiently in the next couple of weeks for this to merge: https://github.com/ikvmnet/ikvm/blob/awt/src/IKVM.ConsoleApp/Program.cs
@wasabii, @The-MAZZTer
What are your thoughts on using Microsoft.Maui.Graphics? It is one of the recommended alternatives suggested by Microsoft.
I have been following the progress ImageSharp for several years and that also seems like a good option, but IMO I think we should consider official Microsoft supported packages first. I just don't know whether MAUI meets our requirements.
What are your thoughts on using Microsoft.Maui.Graphics?
On Linux, it's planned to go over https://github.com/GtkSharp/GtkSharp/ But there is no timeplan yet for productive version of maui-linux. A dev branch is here: https://github.com/jsuarezruiz/maui-linux/tree/main and the issue list is here: https://github.com/users/jsuarezruiz/projects/5
The plan is to enable native AWT support, and use the OpenJDK functionality that exists as is.
It would be a large and unneccessary effort to incorporate any existing .NET libraries.
Although we are dealing with NET, let us see how well the performance of the approach @wasabii will deliver, before evaluating if it is possible to replace the rendering part of AWT with something that is more native to .NET.
The plan is to enable native AWT support, and use the OpenJDK functionality that exists as is.
It would be a large and unneccessary effort to incorporate any existing .NET libraries.
I agree, that sounds like the best plan.
I have no preference as to the actual library used... I'm not actually doing anything with graphics through IKVM! pdfbox library seems to do something which currently is routed to System.Drawing.Common when I feed a PDF to it through Apache Tika for text extraction. Who knows what it is doing... but it's nothing I care about.