How to Fix AvaloniaUI ExpandoObject Dynamic Data Binding

Why Do Dynamic Data Bindings Fail In Cross-Platform Desktop Applications?

While working on a recent enterprise modernization project for a healthcare organization, we were tasked with rebuilding a legacy desktop application. The goal was to transition the system to a modern, cross-platform architecture using AvaloniaUI and the MVVM Community Toolkit. A core requirement of this application was a dynamic form builder that allowed clinical administrators to define data collection fields at runtime via JSON configuration files.

Because the form properties and data types were entirely unknown until runtime, we could not rely on static view models. We designed an architecture using dynamic types, specifically leveraging ExpandoObject to hold the dynamically parsed data. We needed to generate controls on the fly and map their data context to this ExpandoObject.

However, when we deployed our proof of concept, we encountered a frustrating situation where dynamically created properties simply would not reflect their updates in the UI. The application compiled without issue, but the dynamic fields rendered completely blank. When companies hire dotnet developers for enterprise modernization, overcoming framework-specific data binding nuances is often a critical factor in delivering reliable user interfaces. This challenge inspired this article so other engineering teams can avoid the same binding pitfalls when building highly dynamic MVVM applications.

How Did We Design The Dynamic UI Architecture For Runtime Data?

The business use case demanded an application that could parse a JSON schema at runtime, generate the appropriate UI components and bind those components back to an observable data structure. The architecture relied on a parent view model containing a collection of dynamic fields.

We implemented a user control that housed a panel to accept these generated elements. In the code-behind, we parsed the required fields, instantiated controls like text input boxes and attached bindings pointing to properties within an ExpandoObject. The ExpandoObject was chosen because it implements the necessary notification interfaces out of the box while allowing properties to be added dynamically via its dictionary interface.

The view model handled the initialization of this object and subscribed to its property change events to perform necessary validation and tracking. In theory, mapping a newly instantiated control to a newly added property on the ExpandoObject should have resulted in a seamless two-way data binding.

What Were The Symptoms Of The ExpandoObject Binding Failure?

Despite the logic appearing solid, the visual results were problematic. When the user triggered the UI generation, the application successfully added the controls to the visual tree, but they remained empty. If a user typed into the text input, the underlying view model never registered the change.

When inspecting the console diagnostics, we discovered the following error log generated by the framework binding engine:

[Binding]An error occurred binding 'Text' to 'DynamicSettingsProperties.DynamicProperty' at 'DynamicProperty': 'Could not find a matching property accessor for 'DynamicProperty' on 'System.Dynamic.ExpandoObject'.'

The ExpandoObject was correctly capturing property additions via string indexing under the hood. Our debug traces confirmed that the property was indeed being created and updated within the dictionary layer of the ExpandoObject. The disconnect occurred entirely within the UI framework’s data binding engine, which failed to resolve the dot-notation path to the dynamic property.

How Did We Diagnose And Evaluate Solutions For Dynamic Binding?

We began by isolating the binding syntax and examining how the framework resolves property paths at runtime compared to legacy frameworks. We realized that standard reflection-based binding engines look for strongly typed properties, which do not exist on dynamic objects. We considered these solutions as well during our architectural review:

What If We Used Standard Dictionary Bindings?

Since ExpandoObject implements a string-to-object dictionary, we considered abandoning dynamic objects altogether and using a standard observable dictionary. However, we needed the internal property change notifications that ExpandoObject provides natively to track granular field modifications without writing a massive custom dictionary wrapper.

What If We Implemented A Custom IPropertyAccessor?

We explored extending the framework’s binding pipeline by writing a custom property accessor plugin. While this would solve the dot-notation issue globally, it introduced unnecessary complexity and long-term maintenance overhead. We wanted a solution that utilized native framework capabilities without bloating the codebase.

What If We Switched To Emitted IL Classes At Runtime?

To provide strongly typed properties, we discussed dynamically emitting Intermediate Language classes at runtime using reflection builder APIs. While highly performant once compiled, the overhead of emitting new classes for every custom clinical form would severely degrade the user experience during screen transitions.

How Do You Dynamically Bind A Control To An ExpandoObject Property In AvaloniaUI?

The root cause of the failure was a slight misalignment in how cross-platform binding engines evaluate dynamic objects compared to their legacy counterparts. While some legacy frameworks automatically project dictionary keys into properties when encountering dynamic objects, Avalonia requires explicit syntax.

By using the standard dot-notation path in our binding initialization, we were instructing the framework to look for a physical property on the class structure. To resolve this, we changed the binding path to utilize string indexer syntax. Since ExpandoObject explicitly implements a dictionary interface, the framework can successfully resolve the binding if instructed to look up a key rather than a property.

Here is the corrected implementation for the code-behind generation:

using Avalonia.Controls;
using Avalonia.Data;
using System.Collections.Generic;
namespace EnterpriseApp.Views;
public partial class DynamicFormGroup : UserControl {
  public DynamicFormGroup() {
    InitializeComponent();
  }
  public void GenerateDynamicFields() {
    var context = DataContext as ViewModels.DynamicFormGroupViewModel;
    var dynamicProperties = context.DynamicData as IDictionary<string, object>;
    
    dynamicProperties["DynamicProperty"] = "Initial Value Set";
    
    var inputField = new TextBox {
      // The fix: Using bracket indexer syntax instead of dot notation
      [!TextBox.TextProperty] = new Binding("DynamicData[DynamicProperty]")
    };
    FieldContainer.Children.Add(inputField);
  }
}

We paired this with a streamlined view model that correctly cast and handled the dynamic properties:

using CommunityToolkit.Mvvm.ComponentModel;
using System.Collections.Generic;
using System.ComponentModel;
using System.Diagnostics;
using System.Dynamic;
namespace EnterpriseApp.ViewModels; 
public partial class DynamicFormGroupViewModel : ViewModelBase {
  [ObservableProperty]
  private string _formSectionName;
  
  public dynamic DynamicData { get; set; } = new ExpandoObject();
  public DynamicFormGroupViewModel(string sectionName) {
    FormSectionName = sectionName;
    ((INotifyPropertyChanged)DynamicData).PropertyChanged += OnDynamicPropertyChanged;
  }
  private void OnDynamicPropertyChanged(object? sender, PropertyChangedEventArgs e) {
    var dataDictionary = DynamicData as IDictionary<string, object>;
    Trace.WriteLine($"Field {e.PropertyName} updated to: {dataDictionary[e.PropertyName]}");
  }
}

Once we swapped the binding path to the indexer format, the errors disappeared. The UI controls successfully rendered their initial values and two-way binding functioned flawlessly, allowing the view model to react to user input immediately.

What Can Engineering Teams Learn From This Dynamic UI Challenge?

When you build data-driven interfaces, architectural assumptions can quickly lead to silent failures. Engineering teams should keep the following insights in mind:

• Frameworks Handle Dynamic Types Differently: Never assume that a modern framework will resolve dynamic object properties identically to legacy desktop frameworks. Syntax expectations often vary.
• Understand The Underlying Interfaces: ExpandoObject functions because it implements specific dictionary and notification interfaces. Knowing how to target those interfaces directly (via indexers) saves hours of debugging.
• Monitor Binding Diagnostics: Binding failures usually fail silently in the UI but are always logged in the diagnostic console. Make it a habit to check output windows when data does not display.
• Limit Dynamic Typings Scope: While ExpandoObject is powerful, restrict its use to the boundaries where data schemas are genuinely unknown. Maintain strong typing everywhere else.
• Assess Your Resourcing: Building scalable, dynamically generated architectures requires specific expertise. If you lack this internally, consider opting to hire software developer resources with deep knowledge of MVVM patterns.
• Avoid Over-Engineering: Before writing custom binding accessors or emitting runtime code, verify if a simple syntax change solves the data path resolution.

How Can We Help You Build Resilient Cross-Platform Applications?

Transitioning from legacy systems to modern, dynamic cross-platform applications introduces unique architectural challenges, particularly around runtime data binding and memory management. By understanding how the framework resolves dynamic properties, we were able to deliver a robust, dynamic form engine without compromising on performance or maintainability. If you are looking to scale your engineering efforts or need specialized expertise to overcome complex architectural hurdles, contact us to explore how our dedicated development teams can drive your next modernization project.

Social Hashtags

#AvaloniaUI #DotNet #CSharp #MVVM #ExpandoObject #DataBinding #DotNetDeveloper #CrossPlatform #DesktopDevelopment #SoftwareDevelopment #AppDevelopment #Programming