Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make AxHost work without classic COM interop. #10927

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

weltkante
Copy link
Contributor

@weltkante weltkante commented Feb 21, 2024

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

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
Copy link
Contributor Author

@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
Copy link
Member

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

}
else
{
Marshal.ReleaseComObject(_instance);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@dotnet-policy-service dotnet-policy-service bot added the draft draft PR label Feb 22, 2024
@JeremyKuhne JeremyKuhne added this to the .NET 10.0 milestone Jul 11, 2024
@lonitra lonitra changed the base branch from main to feature/10.0 July 23, 2024 00:58
@lonitra lonitra changed the base branch from feature/10.0 to main August 15, 2024 01:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
draft draft PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support ComSourceGenerator-based ActiveX controls
2 participants