Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System.Drawing.Common is deprecated on non-Windows platforms #315

Open
safern opened this issue Aug 4, 2021 · 11 comments
Open

System.Drawing.Common is deprecated on non-Windows platforms #315

safern opened this issue Aug 4, 2021 · 11 comments

Comments

@safern
Copy link

safern commented Aug 4, 2021

Hello, I work on the .NET Libraries team, and I saw that this library has a lot of usage in the community and depends on System.Drawing.Common for xplat scenarios.

We just made the decision to make System.Drawing.Common a windows only library starting .NET6+ due to a lot of reasons after a long discussion. You can see more details here:
https://github.com/dotnet/designs/blob/a15a8c7a324c482c5e38b73e46c2afe56f6bd504/accepted/2021/system-drawing-win-only/system-drawing-win-only.md

Also: dotnet/docs#25257

We wanted to reach out so that you could react to this changes when .NET 6 is released. Also if you have any questions/concerns please do let us know at https://github.com/dotnet/runtime

What is the recommended action to still support winforms/wpf scenarios for example as I see your library does?

You can mark those APIs as windows only using the SupportedOSPlatform("windows") annotation, and then add new APIs that use another library like ImageSharp or SkiaSharp.

@mwettste
Copy link

Another benefit of removing this dependency would be that the library could also be used with Blazor WASM. I just tried to get a simple Wifi QR Code Generator working, but unfortunately this is not possible, since System.Drawing is not supported in Blazor WASM.

@alex-jitbit
Copy link

Please don't port to SkiaSharp because it has a C++ dependency that is not shipped on Linux by default.

If you want to stay compatible with Linux, use ImageSharp which is 100% managed code and has no dependencies

@codebude
Copy link
Owner

Hi Alex, I will try to port it to ImageSharp, but it may take some time.

@antonfirsov
Copy link

antonfirsov commented Nov 5, 2021

@codebude I just created an example for rendering QR codes in ImageSharp's examples repository, hope this will help you with the port:
SixLabors/Samples#17

Note that the sample renders the code by filling pixel rows directly instead of using Drawing methods to fill rectangles. This should be more performant, and avoids taking a dependency on ImageSharp.Drawing.

I recommend to wait a month or two for ImageSharp 2.0, since there will be a breaking change in the pixel processing API.

In the meanwhile, the example can also help users mitigating the obsoletion of System.Drawing in their own apps, since byte[,] pattern is compatible with AbstractQRCode.QrCodeData.ModuleMatrix if I'm not mistaken.

@NHodgesVFX
Copy link

NHodgesVFX commented Nov 5, 2021

It would be great to see this Library use image sharp that way all the different renderers work cross-platform.

Although, You can use the PngByteQRCode renderer across platforms, it even works with Blazor WASM. If you need base64 you can do "data:image/png;base64," + Convert.ToBase64String(png); So, you can use it in a <img>, which was my use case.

@codebude
Copy link
Owner

codebude commented Nov 5, 2021

Hi @NHodgesVFX you are right. There are a couple of renders which aren't in need of System.Drawing. PngByteQrCode is one of them.
As stated above, I'll try to port the library to ImageSharp, but as also mentioned, I'll wait for the 2.0 release.

My current plans are releasing QRCode 1.4.2 with a couple of bugfixes and new features and then start working on 1.4.3 with ImageSharp.

@st1pps
Copy link

st1pps commented Dec 9, 2021

I've downloaded QRCoder beginning of November, threw out the Windows specific stuff and replaced System.Drawing with ImageSharp to see if it was any hassle. Fortunately it went pretty smooth, and I got pretty much everything running and tested under OSX. If you want any assistance, I could clean up that code and contribute. Cant really use what I did earlier, as I simplified it to .NET 6 only projects, and you probably don't want to loose backwards compatibility.

@codebude
Copy link
Owner

Hi @st1pps ,

thanks for your offer. I plan to switch to ImageSharp soon, but I'm unsure if we should do it right now. In the discussion above it ws mentioned by @antonfirsov that it might be a good idea to wait for ImageSharp 2.0 because breaking changes are expected from 1.X to 2.X and thus it may make not much sense to implement against 1.X now. (Only to refactor everything again, when ImageSharp 2.0 is released.)

@st1pps
Copy link

st1pps commented Dec 12, 2021

@codebude sounds sensible. I'll use my fork for now and see if I can contribute later on then. Greeting from Solingen ;)

@wggley
Copy link

wggley commented Jan 4, 2022

+1 for Imagesharp implementation.

@jnyrup
Copy link
Contributor

jnyrup commented Feb 7, 2022

FYI, ImageSharp 2.0.0 has just been released.

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

No branches or pull requests

9 participants