[WIP/QRCoder2] How do deal with COM-support?

[codebude]

Note: This issue is part of the planning of version 2 of the QRCoder. The meta-issue can be found here. These comments have been copied into this issue here, with the comments marked as such. If comments on the topic of this issue already exist in the meta thread, they have been copied here, naming the authors.

Topic

QRCoder currently has support for COM interop or better said, it implements supporting classes that enable it to be used as a COM object. Do we want to keep this for version 2 of QRCoder? What are the advantages and disadvantages?

[codebude]

Regarding the core abstraction for Renderers, this commit removed the genericity of AbstractQrCode (renderers) to support COM.

In my opinion, something like the original abstraction would be preferable. Is COM support a MUST in v2.0? If so, can it be supported in some other way without limiting the design?

^{Originally posted by @csturm83 here.}

[codebude]

I suggest removing COM support

^{Originally posted by @Shane32 here.}

[codebude]

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
_@Shane32

If it were only up to me, we could happily remove COM support. However, I fear that the feature will be used more than expected. As part of the SwissQRCode, I have received a number of requests asking if I could help integrate the generator into Excel or Access via COM. (Due to lack of time and confidence in my COM skills, I have never done this for 3rd parties - but I suspect that some others have.) I would hate to offend these users.

If there is a way (additional wrapper library, etc.) to make the QRCoder usable in COM environments and at the same time get rid of the current implementation, then we can throw away the current support. (Otherwise we propably would have to continue to support the 1 version at least in terms of payload generator updates).

[Shane32]

I'm not sure what's needed for COM support, but perhaps we can move it into a separate NuGet package, perhaps built out a little more if applicable and including a practical sample application like a VBScript, Excel, ASP Classic, or C++ sample.

[csturm83]

I agree with @Shane32. COM support doesn't seem like a common modern mainstream scenario. I would keep it separate (if necessary) and document/codify the requirements and protect it with tests (if possible).