TrimMode=link, while not supported, still builds successfully, but crashes inconsistently

[Lauriethefish]

Describe the bug

When publishing an Avalonia application on Windows (tested Windows 10) with 'link' set, the application will build successfully with approximately the same count of warnings as TrimMode=copyused

However, COM interop is not supported with TrimMode=link, and therefore this will cause the application to crash, but only if UI automation gets invoked. (see 1) This means that for a majority of users, the app will work as expected, but for a small minority, e.g. those who use magnifier regularly or have screenreaders installed (even if they don't actually use them), the app will crash due to an access violation shortly after starting up.

This is a nightmare to diagnose and debug for developers - the access violation doesn't make it clear what causes the problem. Even after gathering crash dumps to view in windbg, which show the crash when calling UiaReturnRawElementProvider, it is not evident what's causing this problem.

1. The lack of support for TrimMode=link does not seem to be officially documented anywhere, only in various (now closed) issues.

To Reproduce

(To carry out on a machine running Windows)

1. Create a new Avalonia project
   $ dotnet new avalonia.mvvm -o ExampleApp
2. Build with TrimMode=link
   $ cd ExampleApp
$ dotnet publish -c Release -p:PublishTrimmed=true -p:TrimMode=link
   ... build succeeds, with little additional warning compared to the correct TrimMode. The warning that COM support is not trim compatible appears in both cases.
3. Open magnifier.
4. Invoke the published application
   $ cd bin\Release\net8.0\win-x64\publish
$ .\ExampleApp

The outline of a window will appear and then it will immediately disappear as the app crashes.

Expected behavior

If TrimMode=link is enabled, some part of the build process should inform the developer of the peril they will face in a more obvious way, ideally failing the build.

Avalonia version

11.1.0

OS

Windows

Additional context

An example of this issue in my project here

While I probably could've figured it out sooner, it took me several months to pin down (obviously not nonstop work but many hours spent overall). As soon as I knew it was trimming related it was of course an easy fix.

Obviously this issue didn't occur on Avalonia 0.10.x, since there was no UI automation support.

[maxkatz6]

TrimMode=link, while not supported

Trimming is supported for a long time now.

COM interop is not supported with TrimMode=link, and therefore this will cause the application to crash

That's true, COM interop is not supported with trimming, and we only use it for Automation related APIs.
But it shouldn't crash, it should fallback and ignore automation requests.
See:

Avalonia/src/Windows/Avalonia.Win32/Interop/Automation/UiaCoreTypesApi.cs

Lines 59 to 67 in 0d32343

	#if NET6_0_OR_GREATER
	if (!System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported)
	{
	return false;
	}
	#endif
	var comConfig = AppContext.GetData("System.Runtime.InteropServices.BuiltInComInterop.IsSupported") as string;
	return comConfig == null || bool.Parse(comConfig);

[maxkatz6]

I wouldn't expect RuntimeFeature.IsDynamicCodeSupported to return false when app is trimmed. This condition is more for AOT compilation.

But System.Runtime.InteropServices.BuiltInComInterop.IsSupported flag should be set to false with trimming.

[maxkatz6]

I wonder if this property overrides trimming capabilities, which shouldn't really make sense.

[Lauriethefish]

I did see some other issues mentioning that the automation support should be automatically disabled. Unfortunately it seems this isn't the case.

Good to know that this is the planned solution

[Lauriethefish]

Trimming is supported for a long time now.

Is there documentation for exactly which options are/aren't supported? Hunting around on issues/discussions led me to that false conclusion.

[maxkatz6]

@Lauriethefish yes, https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/incompatibilities

[Lauriethefish]

Yes, I know there is documentation on what .NET supports with/without trimming. I'm talking about Avalonia documentation on what is/isn't supported by Avalonia.

[Lauriethefish]

But System.Runtime.InteropServices.BuiltInComInterop.IsSupported flag should be set to false with trimming.

Again, this needs to be documented as part of Avalonia.
The issue also occurs with TrimMode link and the ComInterop property unset (or at least it did in QuestPatcher for a number of months, perhaps this has been fixed in a newer release of Avalonia since I can no longer reproduce it.)

And to add, even if the property is set incorrectly, an error should be generated by some Avalonia build task, not a warning.

[maxkatz6]

Again, this needs to be documented as part of Avalonia.

It's not part of Avalonia, this configuration flag is part of .NET and is documented by .NET.

Only thing that Avalonia should do - is to migrate out from using COM Interop, which is planned for 11.2 release.