QRCoder
QRCoder copied to clipboard
codebude
System.Drawing.Common is deprecated on non-Windows platforms
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: https://github.com/dotnet/docs/issues/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.
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.
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 I just created an example for rendering QR codes in ImageSharp's examples repository, hope this will help you with the port: https://github.com/SixLabors/Samples/pull/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.
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.
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.
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.
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.)
@codebude sounds sensible. I'll use my fork for now and see if I can contribute later on then. Greeting from Solingen ;)
