AXSG prefers deterministic generated code, but the runtime still has a defined role when generated output needs support services or a fallback path.
The normal execution path is:
Fallback is used when a scenario is intentionally handled at runtime rather than fully lowered into generated code. Examples include:
Fallback should never become the default design for normal compiler behavior. If a scenario can be emitted deterministically into generated code, AXSG should prefer that route and keep fallback as operational support rather than semantic authority.
For class-backed Avalonia XAML, AXSG generates InitializeComponent(bool loadXaml = true) into the generated partial type. That generated method is the normal class initialization path.
The AXSG runtime bootstrap and fallback services do not replace that method. In particular:
.UseAvaloniaSourceGeneratedXaml() does not make an old hand-written InitializeComponent() wrapper safeInitializeComponent() that still calls AvaloniaXamlLoader.Load(this) can bypass the generated AXSG method completelyIf you are migrating an existing Avalonia app, use the guarded fallback pattern documented here:
XamlToCSharpGenerator.RuntimeXamlToCSharpGenerator.Runtime.CoreXamlToCSharpGenerator.Runtime.Avalonia