WPF funziona solo su Windows. Quando un'applicazione deve arrivare anche su macOS o Linux, Avalonia è la destinazione più naturale: XAML e concetti sono simili, ma non identici.

Le differenze principali

• File: le viste usano l'estensione .axaml e il namespace https://github.com/avaloniaui.
• Visibilità: al posto di Visibility si usa la proprietà booleana IsVisible.
• Trigger: non esistono; si usano stili con selettori, classi e pseudo-classi.
• Proprietà di dipendenza: diventano StyledProperty o DirectProperty.
• Riferimenti ad altri elementi: nei binding si scrive #nomeElemento.Proprieta.

Una proprietà personalizzata

// WPF
public static readonly DependencyProperty TitoloProperty =
    DependencyProperty.Register(nameof(Titolo), typeof(string), typeof(Scheda));

// Avalonia
public static readonly StyledProperty<string> TitoloProperty =
    AvaloniaProperty.Register<Scheda, string>(nameof(Titolo), "");

public string Titolo
{
    get => GetValue(TitoloProperty);
    set => SetValue(TitoloProperty, value);
}

Un trigger diventa uno stile

<!-- in WPF: DataTrigger su Stato = "Errore" -->
<Style Selector="Border.errore">
    <Setter Property="Background" Value="MistyRose" />
</Style>

<Border Classes.errore="{Binding HaErrori}" />

Una strategia di migrazione

1. Separa la logica: porta ViewModel e servizi in librerie .NET moderne senza dipendenze da WPF. Sono riutilizzabili al cento per cento.
2. Riscrivi le viste partendo dalle schermate più semplici, adattando stili e trigger.
3. Sostituisci i controlli di terze parti con equivalenti per Avalonia, come DataGrid o librerie di grafici compatibili.
4. Prova su ogni sistema: font, scalatura dello schermo e percorsi dei file cambiano da un sistema all'altro.

Per applicazioni molto grandi esiste anche Avalonia XPF, un prodotto commerciale che esegue applicazioni WPF esistenti su più piattaforme quasi senza modifiche: un'opzione da valutare quando riscrivere le viste non è sostenibile.