[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).

[optionmaker]

Even MS will promote Office 365 instead of stand alone office suite. I think COM support should remain in 1.0

[Shane32]

Version 1.x will retain whatever COM support is currently available. Version 2.x will not include any specific code to support COM scenarios.

[codebude]

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 why it was implemented in the first place. QRCoder has a payload generator for SwissQRCodes. These are QR codes that are used in Switzerland to print invoice information on an invoice. A few years ago, a decision was made that this must be printed on every invoice in Switzerland. This affects everyone from large corporations to one-man mini-companies or associations. At that time, many small businesses created their invoices in Word or Excel. This was the target group that wanted COM integration.

In theory, they should all have completed their integration. However, if there is ever a change that requires an adjustment to the payload generator, COM support users may come back around the corner.

As I said, I understand and support your decision, but I wanted to give you some background on why this ended up in QRCoder in the first place.

[Shane32]

Thanks for the info and support! While QRCoder 1.x will always be around for that use case, we can also readd empty constructors, backport bug fixes, or whatever is needed on an as-requested basis. Or perhaps if someone working with COM in 2025, they can write their own COM-compliant wrapper to the latest .NET Standard 2.0-compliant libraries available.

[Shane32]

I just looked up what you're referring to -- the swiss QR code regulations on invoices. Seems that additional regulations are going into effect this November. Perhaps we should consider enough COM support to allow continued use for this unique case, even if it means a special class or NuGet package. Do you know what renderer the typical use case required - e.g. for Excel?

[Shane32]

We could publish a NativeAOT dll to wrap the exact functionality required with COM wrappers so it could be used in these scenarios without additional dependencies... (but it might be a lot of work).

Ref:

• Why does the COM registration generated by the AOT fail, and how do I generate it correctly? dotnet/runtime#110264
• https://chatgpt.com/s/t_68de1cf0b0848191bd40c16ffbea4210

[codebude]

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 are used, usually an older .NET Framework is available.

But I'm not 100% firm with all this COM stuff. After having a quick Google research it seems like the latest MS Office suite dropped/is dropping COM support at all. So the complete COM topic targets only old/outdated environments. Thus I assume it's safe to rely on System.Drawing. But these are all assumptions without any real evidence.