Skip to content
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

Trimming-safe AvaloniaXamlLoader.Load(string) #18292

Open
maxkatz6 opened this issue Feb 23, 2025 · 1 comment
Open

Trimming-safe AvaloniaXamlLoader.Load(string) #18292

maxkatz6 opened this issue Feb 23, 2025 · 1 comment

Comments

@maxkatz6
Copy link
Member

Is your feature request related to a problem? Please describe.

Existing AvaloniaXamlLoader.Load(Uri) and StyleInclude/ResourceInclude in C# code have poor compatibility with AOT, as they require reflection access to find requested resource. These are also marked with RequiresUnreferencedCode for a while now.

When used from XAML, we already optimize StyleInclude/ResourceInclude with direct access instead of reflection. Making this issue less impactful. Yet it still exists #16700 (comment)

Describe the solution you'd like

The more or less .NET friendly solution would be having a method with const string input, intercepted by source generators:

public static object Load([ConstantExpected] string absoluteAvaresResource);

And use source generator to replace this call with a static reference. This article is really useful on that topic.

Interceptors are considered a stable .NET feature since 9.0.200 SDK.
Cons: interceptor solution won't be supported on older SDKs (had to keep reflection fallback there). And they have to enabled explicitly via msbuild property (can be part of our props and enabled by default?).

Describe alternatives you've considered

  1. Keep as is (see workarounds)
  2. Wait until Interop Type Mapping is formalized. Would it help? Can we create a custom "type universe" for XAML compiler types?

Additional context

Since XAML compiler already optimizes StyleInclude/ResourceInclude usage, it provides several possible workarounds:

  1. If you own the included XAML resource, you can use x:Class on it, with a blank C# class created. This way you can reference this resource by its C# type instead of StyleInclude/ResourceInclude. Making it completely compiler safe.
  2. If you don't that resource, you still can create another XAML file with x:Class that has the include.
  3. More your StyleInclude/ResourceIncludeto XAML only. If you don't need to include them right away, you can still define them in XAML for later use. This MyStyleInclude can be read and included manually from C# code when needed:
<Resources>
    <StyleInclude x:Key="MyStyleInclude" Source="avares://.....axaml" />
</Resources>
@saeed-neorelm
Copy link

this can be a big step forward for Avalonia's performance 🔥

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants