Fix ELEMDESC native interop definition

[weltkante]

This is a follow-up issue to PR #818 where it was noted (link to comment) that the definition of ELEMDESC that WinForms uses seems to be wrong.

Currently the definition is embedding the TYPEDESC by reference (it was a class before, so the interop rules should already have been embedding it as a pointer before PR #818)

public unsafe struct tagELEMDESC {
    public NativeMethods.tagTYPEDESC* tdesc;
    public NativeMethods.tagPARAMDESC paramdesc;
}

while the definition of ELEMDESC and TYPEDESC on msdn is

typedef struct tagELEMDESC {
  TYPEDESC tdesc;
  PARAMDESC paramdesc;
} ELEMDESC, *LPELEMDESC;

typedef struct tagTYPEDESC {
  union {
    struct tagTYPEDESC  *lptdesc;
    struct tagARRAYDESC *lpadesc;
    HREFTYPE            hreftype;
  } DUMMYUNIONNAME;
  VARTYPE vt;
} TYPEDESC;

Notes taken from the previous discussion in the PR

• @sharwell wants to have tests to make sure nothing breaks, because fixing this likely requires also correcting all usage of ELEMDESC in WinForms
• @zsd4yr suggests taking a look into the old source control system to see if there's any history to the definition explaining the way it is
• @JeremyKuhne suggests using the version in System.Runtime.InteropServices.ComTypes - note that this still requires reviewing and adjusting callers in WinForms which previously used the broken version

[zsd4yr]

Who is taking point on this?

[sharwell]

I was not able to construct a case where any of this code gets used. Is any of this COM stuff supported in .NET Core?

[weltkante]

Looking through the Com2Interop namespace it looks like the only nontrivial user is AxHost, so it's probably all about hosting unmanaged ActiveX controls inside WinForms. Maybe its about the design time experience of ActiveX controls? I could find a reference to VS so there is/was some hidden connection here. Since the VS designer is still Desktop Framework you may not be able to test this code path in .NET Core yet, but moving forward I think VS will need a separate WinForms Core designer, at least once new features or .NET Core only 3rd party controls start to appear the Desktop Designer will no longer work.

Hosting 3rd party unmanaged ActiveX controls inside WinForms is something we have occasionally used, so I don't think it should be dropped entirely. However if my assumption is right and the Com2Interop namespace is only used at design time then VS is probably the only consumer and I'm all for moving it out of WinForms and into the project system. Unless you want to support 3rd party WinForms designers to host unmanaged ActiveX controls.