-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
[GeneratedComInterface] based Windows automation
#16543
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
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
Show resolved
Hide resolved
src/Windows/Avalonia.Win32.Automation/Interop/Automation/UiaCoreTypesApi.cs
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)?
#ifdirectives.GeneratedComInterfacedoesn't support COM interface properties (these are not part of the COM standard) - had to replace with methods.GeneratedComInterfacerequired 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
ComVisibleand instead usedComImportand fixed interface definitions (WPF had them defined wrong, relying on broken by design COM support in old .NET), completing this idea.Alternative solutions
GeneratedComInterfaceapproach, 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
jobjust for .NET 6 target? Maybe even NET Framework?Breaking changes
Old
ComVisibleinterfaces 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