Made resources index binary

[MrJul]

What does the pull request do?

This PR changes the Avalonia resources index to a simple binary format that can be read/written using only BinaryReader/Writer, instead of relying on System.Xml.Linq for reading and DataContract for writing. Note that the previous index wasn't pure XML: it contained a binary version header.

Since all XAML files are compiled to IL, this was the last piece of code to reference System.Xml at runtime. After this PR, there's no more dependencies on it and it can be trimmed. A XAML-based framework that doesn't require System.Xml!

A self-contained hello world app published trimmed for win10-x64 results in 20 (!!) fewer published assemblies, and a 2.2 MB size reduction. (I wasn't expecting so much; it turns out that even trimmed, System.Xml has a lot of dependencies.)

Removed assemblies:

• Microsoft.Win32.Registry.dll
• System.Diagnostics.DiagnosticSource.dll
• System.IO.Compression.Brotli.dll
• System.Net.Http.dll
• System.Net.NameResolution.dll
• System.Net.NetworkInformation.dll
• System.Net.Primitives.dll
• System.Net.Quic.dll
• System.Net.Security.dll
• System.Net.Sockets.dll
• System.Private.Xml.dll
• System.Private.Xml.Linq.dll
• System.Runtime.Numerics.dll
• System.Runtime.Serialization.Primitives.dll
• System.Security.Claims.dll
• System.Security.Cryptography.dll
• System.Security.Principal.Windows.dll
• System.Text.RegularExpressions.dll
• System.Threading.Channels.dll
• System.Xml.Linq.dll

On my PC, this also save ≈10ms of JIT time at startup.

Breaking changes

This is a breaking change since the resources index format has changed. All Avalonia resources need to be recompiled.

Note to devs: if this PR merged, you might need to delete your obj folders manually to force the new format to be used due to cached resource files. See #9948 (even if that other PR is merged, any build made before it might contain stale resources). NuGet consumers shouldn't be affected by this cache issue since the package version will be different.

Misc notes

• Replaced AvaloniaResourcesIndexReaderWriter.Create with a slightly more generic WriteResources method, used to write a full resources file (size + index + resources), to avoid duplicated code in the build tasks.
• Added the existing Platform\Internal\Constants.cs file to the build tasks project and replaced the !AvaloniaResources by the existing constant.
• There's still one DataContract file generated by the build tasks and included in the resources: !AvaloniaResourceXamlInfo. However, it doesn't seem to be read anywhere at runtime so it doesn't really matter. Is this file a leftover from a previous implementation that can be removed?

[avaloniaui-team]

You can test this PR using the following package version. 11.0.999-cibuild0028484-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

[kekekeks]

I'd suggest to keep both format loaders for the next preview. Then we could remove the old loader completely for RC. That way people would have some time to update their libraries, so the next preview update won't be so frustrating.

!AvaloniaResourceXamlInfo used to store x:Class to .xaml file mapping back in the day when we still were parsing XAML at runtime. It can be safely removed now.

[MrJul]

I'd suggest to keep both format loaders for the next preview. Then we could remove the old loader completely for RC. That way people would have some time to update their libraries, so the next preview update won't be so frustrating.

I can certainly add the XML loader code path back temporarily. My reasoning to keep the exception instead is that there are other breaking changes (for example the recent removal of System.Reactive) since the last preview that already require most libraries to be recompiled to work. What do you think?

Thank you for the !AvaloniaResourceXamlInfo clarification, I'll open a PR later to remove it.

[maxkatz6]

@MrJul reactive package removal wouldn't require third parties to be recompiled. But interfaces removal will definitely require lots of them to recompile anyway.