Make AxHost work without classic COM interop.

[weltkante]

Fixes #10583

Proposed changes

• Adjust COM interop in WinForms to have AxHost usable together with classic COM interop disabled (<BuiltInComInteropSupport>false</BuiltInComInteropSupport>), which is a requirement for AOT.

Customer Impact

• Allows using ActiveX controls in AOT builds.

Regression?

• No

Risk

• I may have gotten some of the interop wrong, the PR requires review
• I have no unit test coverage. Test coverage can be added but requires ATL ActiveX control with unit test #10754 to have a simple control. Since it has to be handwritten and cannot be generated yet it can't be one of the more complex Windows-provided ActiveX controls.

Before

• Application fails with exceptions if an ActiveX control is used while having configured <BuiltInComInteropSupport>false</BuiltInComInteropSupport> in the project file.

After

• Application can support a simple ActiveX while having configured <BuiltInComInteropSupport>false</BuiltInComInteropSupport> in the project file.

Test methodology

• so far only manual testing in the scratch project, not part of the PR since it depends on the ActiveX control of ATL ActiveX control with unit test #10754 which is part of a separate PR

Test environment(s)

• 9.0.0-preview.2.24116.2
• <BuiltInComInteropSupport>false</BuiltInComInteropSupport> in the project file
• I've also used [assembly: DisableRuntimeMarshalling] in my test, in case its relevant

Microsoft Reviewers: Open in CodeFlow

[weltkante]

@JeremyKuhne if this overlaps with whatever else you guys have in the pipeline for COM interop in .NET 9 feel free to delay it, but it would be nice to get this fix into the release, if possible. Considering that we'll probably want unit test coverage that means we (probably) want to get the other PR in first.

If you need the scratch project thats based on both this PR and the other PR I can look into putting up a third branch that includes both PRs but for now I haven't bothered pushing it, would be more easy once the other PR is merged eventually.

Note that testing with <BuiltInComInteropSupport>false</BuiltInComInteropSupport> might require a new test project being set up in the repo though, though I guess in the long run you want to have test coverage for that anyways, so probably not an issue.

[JeremyKuhne]

@weltkante We definitely plan to get this done for .NET 9.

[weltkante]

This throws if ComHelpers.BuiltInComSupported is false but I believe it was a no-op for ComObject anyways, at least used to be. I'm not clear if it is possible to do manual disposal of a ComObject based RCW so maybe this just needs to be a no-op for this case.