Raffael Herrmann

> I don't think it's necessary. Having all questions posted publicly is likely preferred for an open-source project. Perhaps we just open an issue for v2 and keep it open...

> Regarding the core abstraction for Renderers, [this commit](https://github.com/codebude/QRCoder/commit/3c91f571d86cfdde8ac7d6ea3c33dc9b38b56f74#diff-38ddae11d72c3dd3cfe4d0e55e904c46d53172611bea4e88956a0724ccd38f71) removed the genericity of `AbstractQrCode` (renderers) to support COM. > > In my opinion, something like the original abstraction would be...

> I suggest removing COM support > > Originally posted by @Shane32 [here](https://github.com/codebude/QRCoder/issues/512#issuecomment-2109159412).

> Is COM support a MUST in v2.0? If so, can it be supported in some other way without limiting the design? > @csturm83 > I suggest removing COM support...

Hi @Shane32 I support your decision. COM support feels like dinosaur technology and certainly hinders the further development of QRCoder. Nevertheless, I would like to explain the background as to...

> Do you know what renderer the typical use case required - e.g. for Excel? Most users back then used the System.Drawing based QRCode renderer. In environments where COM Add-ins...

First of all, thank you for your ideas. I find both concepts exciting and welcome the change in the API towards a simpler and more logical design. > **Some suggested...

> Could you please expound on what you consider _best practices_ vs. _'nice solution'_ vs. _simplicity_? > > I've generally understood simplicity to be a best practice ([KISS principle](https://en.wikipedia.org/wiki/KISS_principle)) 😃....

> For QRCoder 2.x, I would target no less than .NET Standard 2.0. This is in line with Microsoft's example (most of their libraries are still .NET Standard 2.0 compatible)...

> I suggest upgrading to the latest C# language features via latest. This means that we need to be careful to not to use features like init-only properties which will...