Suggestion

[remcolam]

Wouldn't it make sense to create 3 sub packages, something like Net.Codecrete.QrCodeGenerator.WindowsDrawing Net.Codecrete.QrCodeGenerator.SkiaSharp Net.Codecrete.QrCodeGenerator.ImageSharp

they could already have references to the relevant nuget packages they require.

Or is this more of a temporary solution until ImageSharp is out of beta

[manuelbl]

Thanks for the suggestion. This is indeed a reasonable option, and I've done so in a similar project.

The only aspect I'm a unsure about is if most people use the library for plain QR codes (quadratic pixels, foreground and background color). Then these sub packages make sense. Or if they create fancy QR codes with modified pixel shapes, color gradients, images in the center etc. Then the packages are less useful as the code needs to be modified anyway.

I will certainly consider it.

[remcolam]

Me, I am using it very basic... I need to embed qr codes from a .net standard library. I had to also modify those extension classes, because .net standard 2.0 doesn't support the new using statements, I had to rewrite them into scoped usings. I tested it and it worked then on both windows & linux... (usking SkiaSharp... but man, the size of the artifacts in my build pipeline increased a lot with that... from 55Mb to 122Mb, more than doubled...

But now it works again (I was using another package, which stopped working after upgradng to .net 8, which I realise is related to the System.Common.Drawing not being crossplatform anymore)

[remcolam]

PS, to be clear, I added both SkiaSharp and SkiaSharp.NativeAssets.Linux, since I needed it to work on windows and linux