[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
| /// <summary> | ||
| /// Release resources owned by this <see cref="ComVariant"/> instance. | ||
| /// </summary> | ||
| public unsafe void Dispose() |
There was a problem hiding this comment.
Won't VariantClear be sufficient?
There was a problem hiding this comment.
I guess it would need a this pointer which might be a problem for structs.
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. |
| Marshal.Copy(data, pointers, 0, array.Length); | ||
| for (int i = 0; i < pointers.Length; i++) | ||
| { | ||
| if (ComWrappers.TryGetObject(pointers[i], out var instance)) |
There was a problem hiding this comment.
TryGetObject will only unwrap an existing managed object, so it won't work for COM objects we didn't create. We should probably use ComInterfaceMarshaller.ConvertToManaged() here instead.
There was a problem hiding this comment.
I'd be a bit concerned about RCW ownership and potential finalization in that case.
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
Closes #13924