Doesn't work on .NET 6 and Linux #141
Comments
|
We should migrate this to one of the alternative solutions in the link you provided. |
|
same problem, this library does what I need but my project is net6 and doesn't work :( |
|
They look like they do offer this mitigation for the short term but getting it moved off libgdiplus is the longer term answer.
|
|
@barnhill if I were to try to put a PR together for the migration off of libgdiplus, what would that look like in terms of turnaround and approval? |
|
I'll try to take a look asap |
|
Try to keep the changes to just necessities |
|
@barnhill - do you have a preference on SkiaSharp or ImageSharp? |
|
I'd have to do some research. Got experience with either? |
|
I did some very minor work moving our .net 6 web api off of |
|
BTW, I noticed a memory leak in this package where you're using |
|
@udlose any updates or any task items I can help with? I'm looking for Barcode support on linux with dotnet 6 as well. |
|
Image sharp is all managed code vs skiasharp uses a bit of c++. |
|
I would vote for ImageSharp then. FWIW. |
|
@drusellers I haven't had time to start on the migration. Was also waiting to hear if @barnhill had a preference. Feel free to start if you'd like. I'm not sure when I'll have bandwidth for that effort as it is non-trivial. |
|
Probably the main question that should be answered is what version of ImageSharp to target. The latest only supports .NET 6. It looks like earlier versions support lower-level versions. I'm a big fan of keeping things at the latest level. |
|
@drusellers if this is a blocking issue for you and you're unable to start the migration for Barcodelib, you can implement the workaround noted here: System.Drawing.Common only supported on Windows - Recommended Action We had to do this since we were under a time constraint. Note that the above workaround will be removed for .NET 7 (coming around November 2022). |
|
What about this https://ironsoftware.com/open-source/csharp/drawing/docs/ ? |
|
I have a branch working on this but using another cross platform drawing api |
|
@barnhill anything we can do to help? We've got a project where we need barcodes on Linux and .NET 7. It's a paid project, I could make a small donation or contribute code. |
|
Code contributions are welcome. I have a branch to convert to a new lib for drawing as the current usage of System.Drawing.Common is preventing cross platform usage. |
|
Which library would you like to use? I've used the ironsoftware library for another project without any issues, but I'm open to alternatives. A bit further up I can see that you mentioned that skiasharp uses some C++ while imagesharp doesn't. Would imagesharp be your favourite? |
|
Bear in mind that ImageSharp is no longer covered under simple Apache license. However there is exemption for open source project like BarcodeLib one (see discussion in nissl-lab/npoi#933 and nissl-lab/npoi#933 and also SixLabors/ImageSharp#2151). IronSoftware use this exemption to keep same interface but allowing to use different graphics "backend". License wise SkiaSharp is better choice but introduces non-managed dependencies and all the problems of this (distros, arch, etc). I did not check in detail how complicated it is. Very interesting is https://maui.graphics/. Seems to be supported by Microsoft and part of their Maui initiative so give some positive light of future profaneness. |
|
@MichalSznajder I never worked with maui.graphics, but when I check the documentation (https://learn.microsoft.com/en-us/dotnet/maui/user-interface/graphics/images?view=net-maui-7.0) I see this:
|
|
I can only give this dotnet/Microsoft.Maui.Graphics#422. Maui is also new for me. However it seems that under Linux it anyways uses Skia to do actaul drawing. And according to https://learn.microsoft.com/en-us/dotnet/maui/supported-platforms?view=net-maui-7.0 Linux is not officially supported in MAUI. What a mess. What do you use in your branch? |
|
Another library has similar problem like us: ststeiger/PdfSharpCore#285. They use ImageSharp and are not sure about its dual licensing model. QRCoder is another popular one with a problem (codebude/QRCoder#361 (comment) and codebude/QRCoder#315) MAUI is on SkiaSharp IMHO. |
|
The ImageSharp license makes it look like it shouldn’t be an issue if it is consumed indirectly. I.e., if your project depends on barcodelib and barcodelib depends on ImageSharp, then it is allowed even for paid projects—if I am reading it right. However, it is not a standard license, and that makes it scary. So it’d be preferable to avoid it to protect consumer of this library from legal issues. It looks like, no matter what we do, we are going to end up with an API-breaking change if we want to keep things clean and simple. Continuing to support using To get things going, could barcodelib take a different approach and itself provide a minimal interface which the consumer can implement that looks very much like the few calls barcodelib would make using the existing System.Graphics.Drawing library? This way, the responsibility of choosing a library, dealing with its licensing, etc., is very obviously up to the library consumer. The library could even provide a built-in implementation which outputs a raw monochrome bitmap without any font support (which would be given some annoying name like The biggest issue I see with this approach is that having library consumers implement an interface only works well if that interface never changes in future versions of the library. So adding a new feature which required a new drawing operation would need special consideration. Is anyone interested in a proof of concept of this approach? |
|
@binki I don't have any objections, but I'm also fine with a less flexible solution. Your concept sounds elegant but I guess most people would just go with the default drawing library, whatever that is. At least if there's no issue with the license. |
|
SkiaSharp uses the MIT license which is much more friendly for open source projects to consume. There is now a pull request out for this transition to utilize it and a refactor that was required to accommodate this. There are still 2 features that arent completed so that PR is ultimately incomplete as of yet. The two outstanding features are UPC-E barcodes are broken for some unknown reason, and labels are incomplete. UPDATE: UPCE and EAN8 are generating invalid codes but they were prior to this PR so will consider it a separate issue. Here is the pull request: #152 |
|
The more eyes we get on the Pull Request that is out there the sooner we can get this merged for the masses. |
|
PR has been tested more tonight and still needs eyes on it. If anyone sees anything concerning please let me know. I did fix the labels recently in that PR and added strong assembly signing. We are moving into the final days before this merges and releases. It will have some breaking changes to the API but should be manageable. Thank you all for your patience. |
|
Has there been progress made since the last post regarding usage with .NET 6+ under Linux (here: Blazor WASM in a Docker container running on Linux)? |
|
3.0.1 just released and should support linux and .NET6 ... care to give it a try? Its been uploaded to Nuget but awaiting approval by MS so should be out very soon. |
|
Closing this as addressed since the v3 release |
This Nuget package has a dependency on
System.Drawing.Common. TheSystem.Drawing.CommonNuget used to be supported via libgdiplus however, as of .NET 6, Microsoft made the decision to make a breaking change and deprecate libgdiplus. Thus, this package no longer works on .NET 6 running on Linux.See here System.Drawing.Common only supported on Windows
The text was updated successfully, but these errors were encountered: