4 ms·
> A lot of libraries expect and assume you are on Windows I'm curious about this. Can you give an example of a library that refused to work? I'm having trouble
by uticus 4y ago
> A lot of libraries expect and assume you are on Windows
I'm curious about this. Can you give an example of a library that refused to work? I'm having trouble imagining what would cause something to break on Linux - but not on Windows - in a typical .NET library or NuGet package.
- CodesInChaos 4y agoMS deprecated Linux support for System.Drawing in .net 6.0 and will remove it in 7.0. https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/system-drawing-common-windows-only https://docs.microsoft.com/en-us/dotnet/core/compatibility/c...
- Kuinox 4y agoSystem.Drawing never worked well on linux, and is mostly used in windows-only gui. To generate/process images, there are other, great, .NET library like SkiaSharp, or ImageSharp.
- CodesInChaos 4y agoI think there is still a lot of benefit in a first-party library which provides shared abstractions like `Color` and `Bitmap`, even without any fancy manipulation capabilities.
- davidhbolton 4y agoI came across this with System.Drawing on Ubuntu and successfully managed to replace it with SkiaSharp code instead. It was drawing a map for a game in memory then saving to a .jpg file. I use VS 2022 Community on Windows, tested it there then published to Linux and uploaded over SSH to a VPS. It worked very nicely.
- aaaaaaaaata 4y agoSo are these mostly documentation/outreach issues, then?
- Kuinox 4y agoThe documentation of System.Drawing point to these projects: > If you can't use System.Drawing with your application, recommended alternatives include ImageSharp, SkiaSharp, Windows Imaging Components, and Microsoft.Maui.Graphics Sadly .NET devs will jump on any first party software and won't look a lot in community alternatives.