-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[GeneratedComInterface]
based Windows automation
#16543
Conversation
…bleRuntimeMarshalling and use [GeneratedComInterface] marshalling
…t of the public API
cc @hez2010 if you have time to take a look. |
You can test this PR using the following package version. |
Also invite @MouriNaruto for review |
src/Windows/Avalonia.Win32.Automation/Interop/Automation/IRawElementProviderFragment.cs
Outdated
Show resolved
Hide resolved
src/Windows/Avalonia.Win32.Automation/Interop/Automation/ISelectionProvider.cs
Outdated
Show resolved
Hide resolved
src/Windows/Avalonia.Win32.Automation/Interop/Automation/UiaCoreProviderApi.cs
Outdated
Show resolved
Hide resolved
src/Windows/Avalonia.Win32.Automation/Interop/Automation/UiaCoreTypesApi.cs
Outdated
Show resolved
Hide resolved
src/Windows/Avalonia.Win32.Automation/Marshalling/ComVariant.cs
Outdated
Show resolved
Hide resolved
src/Windows/Avalonia.Win32.Automation/AutomationNode.RangeValue.cs
Outdated
Show resolved
Hide resolved
# Conflicts: # src/Windows/Avalonia.Win32.Automation/AutomationNode.cs # src/Windows/Avalonia.Win32.Automation/InteropAutomationNode.cs
You can test this PR using the following package version. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
What is the current behavior?
Avalonia Windows accessibility/automation is not compatible with trimming or AOT compilation due to legacy COM interop usage.
What is the updated/expected behavior with this PR?
.NET 8 target uses source generated COM interop which is well compatible with AOT and trimming.
How was the solution implemented (if it's not obvious)?
#if
directives.GeneratedComInterface
doesn't support COM interface properties (these are not part of the COM standard) - had to replace with methods.GeneratedComInterface
required disabling runtime marshalling, but our Win32 backend is not ready for that yet (see Make Avalonia not rely on runtime marshaling #16273), I had to move accessibility/automation implementation into a separated assembly. This assembly only contains internal types (visible toAvalonia.Win32
) and nu-merged intoAvalonia.Win32
, without adding any new packages.Extra:
On legacy targets, dropped
ComVisible
and instead usedComImport
and fixed interface definitions (WPF had them defined wrong, relying on broken by design COM support in old .NET), completing this idea.Alternative solutions
GeneratedComInterface
approach, but wait until we update Win32 backend to not rely on runtime marshalling, and keep this logic in the Win32 package as it was. @kekekeks I am interested in implementing this idea and can pick it up. But on the other hand, this new assembly can always be removed without any breaking changes in the future.Open questions
job
just for .NET 6 target? Maybe even NET Framework?Breaking changes
Old
ComVisible
interfaces were public and accessible to users. Since it was only part of platform specific package, and not directly usable with other Avalonia APIs, it should be safe to hide them. But just to be safe, marking this PR aswont-backport
. If necessary (probably not), this PR can be backported while keeping old COM interfaces in Avalonia.Win32 unused.Fixed issues
Fixes #8006
Fixes #16697
Fixes #12909
Closes #13924