Review COM interface declarations for conflicting ComImport/ComVisible attributes

[weltkante]

During review of PR #1868 I noticed IOleInPlaceActiveObject was declared with both [ComImport] and [ComVisible(true)]. This is wrong, ComVisible(true) is for interfaces owned by the assembly, ComImport is for external interfaces.

In desktop framework this probably has little consequence since the assemblies come preinstalled, but now that its possible to deploy WinForms with an application it may more likely be processed by tools like regasm or TLB generators, which attempt to register COM interop owned by the assembly.

When ComVisible(true) is present this will cause registry corruption by overwriting the true owners registry entries (usually owned by Windows OS) and replacing them by .NET based values. For interfaces I believe this mostly replaces the ProxyStubClsid32 pointing to another implementation than the original entries used to have.

There should be a review for conflicting ComImport/ComVisible(true) entries, or better, just review ComVisible(true) in general and make sure it is only placed on classes/interfaces owned by WinForms.

[weltkante]

a quick search for ComVisible(true) yields 238 matches in 182 files, not all of them technically wrong (for example it is placed on control classes which are certainly implemented and owned by WinForms)

However considering that the codebase comes from Desktop Framework I wonder if there should be any ComVisible(true) attributes left in place at all, even for classes and interfaces actually owned by WinForms. The ComVisible WinForms GUIDs registered globally always used to be Desktop Framework, I wonder how many of the ComVisible classes/interfaces owned by WinForms actually need to be ComVisible in .NET Core for supported interop scenarios. Maybe most (or all) of them can be removed?