QRCode namespace doesn't exist in .NET 6+

[ScottDurkin]

Type of issue

[X ] Bug
[ ] Question (e.g. about handling/usage)
[ ] Request for new feature/improvement

Expected Behavior

Should be able to create new QRCode Object by passing in QRCodeData.

Current Behavior

QRCode namespace doesn't exist.

Steps to Reproduce (for bugs)

Upgrade to .NET Core 8

Your Environment

Visual Studio 2022 latest version with .NET Core 8.

Code sample that works in .NET Core 5

 QRCodeGenerator qrGenerator = new QRCodeGenerator();
 QRCodeData qrCodeData = qrGenerator.CreateQrCode(PublicProfileURL, QRCodeGenerator.ECCLevel.Q);
 QRCode qrCode = new QRCode(qrCodeData);
 Bitmap qrCodeImage = qrCode.GetGraphic(20);

[ScottDurkin]

Note, the above code does not work in either .NET Core 6 OR 7.

[cimpok]

Hi @ScottDurkin ,
I am having the same issue since a long time, for me as a workaround it worked downgrading the package to 1.4.1

[cezar-pimentel]

Yeah, for me too. I believe the problem was created with the 1.4.3 changes.
They'll need to add net7 and net8 as target frameworks as well.
@codebude, would you like me to create a PR to address this issue?

[ScottDurkin]

Hi @ScottDurkin ,

I am having the same issue since a long time, for me as a workaround it worked downgrading the package to 1.4.1

Thank you for your response! I'll take a look!

[codebude]

@cezar-pimentel Thanks for your offer. I would love to see such PR. But currently I'm going through all the older PRs and see if I can merge them. I fear if you start your PR now, the master will change a couple of times, while you're working on the PR. Maybe it's better to wait until the majority of the older PRs is merged.

[cezar-pimentel]

@cezar-pimentel Thanks for your offer. I would love to see such PR. But currently I'm going through all the older PRs and see if I can merge them. I fear if you start your PR now, the master will change a couple of times, while you're working on the PR. Maybe it's better to wait until the majority of the older PRs is merged.

No worries, we can wait. There's no need to rush.

Thank you my friend! 👊💪

[Shane32]

@cezar-pimentel @ScottDurkin FYI, your issues are related to the fact that portions of QRCoder have been removed that rely on System.Drawing.Common when targeting .NET 6+ on Linux, as System.Drawing.Common is not supported in that scenario (and indeed would just throw NotSupportedException).

You have a couple options for 1.4.3:

1. Target net6.0-windows or newer (not just net6.0)
2. Use one of the other classes such as PngByteQRCode that does not rely on System.Drawing.Common

In addition, there are a few PRs that already exist that attempt to address to this problem:

• Adds Support for ImageSharp and SkiaSharp using two independent projects for maximum compatibility #407
• Add ImageSharp renderers for .net 6.0, 5.0 and standart 2.0 #460
• Use SkiaSharp to support SvgQRCode in .NET6 #462

Another solution would be to take a dependency on System.Drawing.Common for all platforms (which would include net8.0), and simply mark relevant methods with [SupportedOSPlatform]. This would reduce the confusion for developers on .NET 6+ who are targeting Windows; they would not have to target net8.0-windows specifically. As a side effect, developers for Linux would have an extra dependency that is unnecessary.

cc: @codebude

[codeputer]

@cezar-pimentel @ScottDurkin FYI, your issues are related to the fact that portions of QRCoder have been removed that rely on System.Drawing.Common when targeting .NET 6+ on Linux, as System.Drawing.Common is not supported in that scenario (and indeed would just throw NotSupportedException).

You have a couple options for 1.4.3:

1. Target net6.0-windows or newer (not just net6.0)
2. Use one of the other classes such as PngByteQRCode that does not rely on System.Drawing.Common

In addition, there are a few PRs that already exist that attempt to address to this problem:

• Adds Support for ImageSharp and SkiaSharp using two independent projects for maximum compatibility #407
• Add ImageSharp renderers for .net 6.0, 5.0 and standart 2.0 #460
• Use SkiaSharp to support SvgQRCode in .NET6 #462

Another solution would be to take a dependency on System.Drawing.Common for all platforms (which would include net8.0), and simply mark relevant methods with [SupportedOSPlatform]. This would reduce the confusion for developers on .NET 6+ who are targeting Windows; they would not have to target net8.0-windows specifically. As a side effect, developers for Linux would have an extra dependency that is unnecessary.

cc: @codebude

I like the Supported Platform OS , but I would recommend the method signature stays consistent between them. Right now the number of parameters for each renderer is not the same, and a feature in one (like an overlay Icon), is not in the other.

[Shane32]

Having the method signature identical for each renderer may not be feasible, as the parameter types will be different per renderer. For example, a renderer based on System.Drawing.Common will use the Bitmap class while one based on SkiaSharp would use SKBitmap. The SVG renderer returns a string and the PDF renderer returns a byte[]. Some renderers allow different encodings (e.g. PNG or JPEG), and some could allow multiple .NET return types (such as MemoryStream or byte[]). Besides that, the renderers do not all support the same feature set. While you could argue that the overlay icon for ASCII could be implemented as a string which overwrites the center of the QR code, the chance that someone really wants this functionality in an ASCII output is minimal.

[Seanxwy]

Has the problem been solved?

[nicetomytyuk]

I'm trying to use Base64QRCode in .NET 8 and having the same issue, how could that be resolved?

[codebude]

I like the Supported Platform OS , but I would recommend the method signature stays consistent between them. Right now the number of parameters for each renderer is not the same, and a feature in one (like an overlay Icon), is not in the other.

@codeputer never say never, but I'm pretty sure it can't be implemented that way. The whole philosophy behind the modular renderers is to get the best out of each target format/renderer. This is where the different method signatures come from. If the GetGraphic method of every renderer had the same signature, we would have to remove many great features. Example: Many renderers can be passed an image that is drawn as a logo on the QR code. However, the purely text-based ASCIIQrCode simply cannot draw images and will therefore never accept an image in the GetGraphic method. If we were to harmonize the method signatures, we would have to delete the logo functionality in all other renders. I don't think that makes sense.

Has the problem been solved?

@Seanxwy Yes and no. The comment by Shane32 explains very well why the QRCode renderer is not available in .NET8. (TL;DR; It is based on System.Drawing.Common, which is no longer supported by Microsoft). However, as Shane explained, you can use other renderers or target Windows only (net8.0-windows) as the target platform. In the medium term, there will be a QRCoder 2.0 version, which will then include other renderers that (hopefully) emulate the functionality of the QRCode renderer under net7.0+. But then with an alternative graphics library (such as e.g. SkiaSharp). To be honest, QRCoder 2.0 is certainly not something that will see the light of day in the next few weeks. Unfortunately, I simply don't have enough free time to invest in the QRCoder. :-(
Please also check the compatibility matrix in our wiki, to see which renderer works with which target platform: https://github.com/codebude/QRCoder/wiki/Advanced-usage---QR-Code-renderers#2-overview-of-the-different-renderers

I'm trying to use Base64QRCode in .NET 8 and having the same issue, how could that be resolved?

@nicetomytyuk this will be resolved with PR #495 which will be merged this week. The code changes will be part of QRCoder 1.5.0 that I plan to release soon. (Next couple of days.)