Repository navigation
QRCode namespace doesn't exist in .NET 6+ #489
Description
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);
Reacted by Ezequiel Moroni, Ryan Miranda, Pillepalle, Kevin and Jeremy Bokobza
Activity
ScottDurkin commentedon Mar 28, 2024
Note, the above code does not work in either .NET Core 6 OR 7.
cimpok commentedon Mar 30, 2024
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 commentedon Apr 2, 2024
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 commentedon Apr 5, 2024
Thank you for your response! I'll take a look!
codebude commentedon Apr 8, 2024
@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 commentedon Apr 8, 2024
No worries, we can wait. There's no need to rush.
Thank you my friend! 👊💪
Shane32 commentedon Apr 13, 2024
@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:
net6.0-windowsor newer (not justnet6.0)PngByteQRCodethat does not rely on System.Drawing.CommonIn addition, there are a few PRs that already exist that attempt to address to this problem:
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 targetnet8.0-windowsspecifically. As a side effect, developers for Linux would have an extra dependency that is unnecessary.cc: @codebude
codeputer commentedon Apr 13, 2024
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 commentedon Apr 18, 2024
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
Bitmapclass while one based on SkiaSharp would useSKBitmap. The SVG renderer returns astringand the PDF renderer returns abyte[]. Some renderers allow different encodings (e.g. PNG or JPEG), and some could allow multiple .NET return types (such asMemoryStreamorbyte[]). 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 commentedon Apr 23, 2024
Has the problem been solved?
nicetomytyuk commentedon Apr 23, 2024
I'm trying to use Base64QRCode in .NET 8 and having the same issue, how could that be resolved?
codebude commentedon Apr 23, 2024
@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.
@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
@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.)
hosamyousof commentedon Oct 24, 2024
Any plan to make QRCoder supported in .net8?
Mid-D-Man commentedon Jan 19, 2025
Has the support for .net8 been added?
Shane32 commentedon Jan 20, 2025
Nothing has changed, if that's what you're asking. .NET 8 support is available for specific renderers as listed here under the .NET 6 columns.
Shane32 commentedon Oct 2, 2025
@gfoidl I've linked a number of issues caused by the System.Drawing.Common reference not being included with .NET 6. We could add the dependency to
net6.0so that targetingnet6.0-windowsis not required. Users would get build warnings and possibly runtime errors, but would not have missing method issues. I probably would have done this when .NET 6 was released, however it's been this way for a while, and at this point I'm not sure there's a substantial benefit -- especially as it will add a dependency for Linux users (even if unused), and it's going to change in v2 anyway. Thoughts? At this point, I'm favoring leaving it as-is. If we leave it as-is, I can close the issue, or leave it open and/or pinned for visibility.gfoidl commentedon Oct 2, 2025
The core implementation should not depend on any specific output renderer. Rather it should be / remain as generic as possible, and operate only on bytes.
Thinking loud: maybe for v2 we can move towards a builder pattern, where the output from the core library is piped through renderers. Some common renderes (like png-bytes, svg, pdf) are shipped with QRCoder, whilst others are easy to plug in (like GDI bitmaps for System.Drawing.Common).
I'm also favoring leaving the code as is.
The issue is pinned, but shoud be renamed to include .NET 6+ in the title.
We could provide some guidance on how to make it work on Windows, via getting the png bytes, then creating the images yourself. That can also include a simple copy & paste extension method. I wouldn't create a separate package for this, as with v2 that's obsolete anyway.
And for v2 when it's about to get a png image (stream or file) as output, we should rely on something that is platform-independet. Whether Skia or Cairo is a differnt question (where I'd lean towards Cairo1 as with the same "drawing" it can be outputted as svg, pdf, png, (e)ps). So some common logic would need to be implemented only once. And in a dicstinct package, to keep the core implemenation clean.
Footnotes
there are some old cairo wrappers for .NET available, I'm creating a new one which will be released soon, just as info, not as commercial -- otherwise looking at cairo might seem outfashioned. ↩
[-]QRCode namespace doesn't exist in .NET 8[/-][+]QRCode namespace doesn't exist in .NET 6+[/+]Shane32 commentedon Oct 10, 2025
With version 1.7.0, the QRCode class has been restored for all target frameworks. However, it will not function on Linux/macOS due to Microsoft dropping support for Windows.Drawing.Common on those platforms.
Solutions include:
<TargetFramework>net8.0-windows</TargetFramework>[SupportedOSPlatform("windows")]attribute#if WINDOWSorif (OperatingSystem.IsWindows())PngByteQRCode,SvgQRCode, orBitmapByteQRCodeSee also Microsoft's documentation on this: