Changelog

CategoryManagementView.axaml was the only Finance view using

x:CompileBindings="False" without declaring the vm: xmlns namespace.

Avalonia's XAML IL compiler still generated type resolution code

referencing vm:CategoryManagementViewModel, causing a runtime crash

("Unable to resolve type vm:CategoryManagementViewModel") during

the layout pass when the Finance plugin loaded.

Fixed by adding xmlns:vm, x:DataType="vm:CategoryManagementViewModel",

and proper x:DataType annotations on all inner DataTemplates

(CategoryGroupItemViewModel, CategoryDetailViewModel) to match the

compiled binding pattern used by all other Finance views.

Bumped version to 3.3.2.

The Avalonia XAML IL compiler embeds every xmlns:vm type reference as a

string literal that gets resolved at runtime via XamlTypeResolver.Resolve().

This resolver searches the default AssemblyLoadContext, but plugin assemblies

are loaded in a custom PluginLoadContext — so ANY vm: reference in compiled

XAML causes an unresolvable type error at runtime. This includes x:DataType

on the root element AND x:DataType on nested DataTemplates.

Fix: Remove xmlns:vm, x:DataType, and all DataTemplate x:DataType attributes.

Use x:CompileBindings="False" so all bindings resolve via reflection at

runtime (which correctly uses the plugin's assembly). Verified the compiled

DLL contains zero "vm:" string literals.

Finance v3.3.1.

The {x:Type vm:CategoryManagementViewModel} markup extension in FinanceView's

DataTemplates triggers XamlTypeResolver.Resolve() at runtime, which cannot

resolve types loaded via a custom AssemblyLoadContext (plugin isolation).

This is the actual root cause of the CategoryManagementView crash — not the

bindings inside CategoryManagementView itself.

Fix: Remove all {x:Type} DataTemplates from FinanceView.axaml entirely.

Instead, each GoTo*Command now sets CurrentView to a new View instance with

DataContext set to the corresponding ViewModel. This is the same pattern

used by every other multi-view plugin and completely avoids XAML runtime

type resolution.

Finance v3.3.0.

Root cause: Avalonia's XAML type resolver cannot resolve plugin types loaded

via custom AssemblyLoadContext. Any binding that traverses up to a parent

DataContext and casts it (e.g. $parent[UserControl].((vm:Type)DataContext))

triggers XamlTypeResolver.Resolve() which fails for plugin assemblies.

The previous fixes tried disabling compile bindings, but the real issue is

the binding pattern itself. The working Finance views (AccountManagement,

BudgetDashboard, etc.) never traverse to parent DataContexts from inside

DataTemplates — they bind directly to their own item ViewModel properties.

Fix: Push RenameCommand and SelectCommand into the item ViewModels

(CategoryGroupItemViewModel and CategoryDetailViewModel) as delegated

command properties wired by the parent. DataTemplates now bind directly

to {Binding RenameCommand} and {Binding SelectCommand} on their own

DataContext, eliminating all parent traversal. Re-enabled compile bindings

with proper x:DataType on both FinanceView and CategoryManagementView.

Finance v3.2.3.

The previous fix (a7fad09) removed compile-binding type casts from

CategoryManagementView.axaml, but the root cause was in FinanceView.axaml.

FinanceView had x:DataType="vm:FinanceViewModel" (enabling compile bindings)

and used {x:Type vm:CategoryManagementViewModel} in DataTemplate DataType

attributes. Avalonia's XAML IL compiler embeds type resolution logic that

fails at runtime when the plugin is loaded in a custom AssemblyLoadContext,

because the XamlTypeResolver cannot find types in non-default load contexts.

Fix: Replace x:DataType with x:CompileBindings="False" on FinanceView.axaml.

The view only uses simple Command bindings and a ContentControl for view

switching, so compile bindings provide no benefit here.

Finance v3.2.2.