实现IValueProvider导致WindowsStore应用UI自动化抛出UITestControlNotAvailableException

Hey there, I’ve run into almost identical issues while building UI automation for Windows Store apps, so let me break down what’s going on here and how to fix it.

What’s Causing This? #

Your problem boils down to this: as soon as you implement IValueProvider, the UI Automation framework tries to validate all the provider interfaces your control exposes when accessing properties like testControl.Name. The inner exception about an event failing to invoke subscribers is the key clue here—your IValueProvider implementation has a flaw in how it handles events or thread safety, which is causing the framework to throw when it tries to interact with your control.

Common culprits include:

• Trying to access UI elements off the main UI thread without dispatching calls
• Failing to check for null subscribers before firing the ValueChanged event
• Attempting to access a control that’s already been unloaded or disposed

Step-by-Step Fixes #

1. Enforce Thread Safety for All IValueProvider Operations #

Windows Store app UI automation requires all interactions with UI elements to happen on the main UI thread. Wrap every property access or method call in your IValueProvider with the dispatcher:

public string Value
{
    get
    {
        return Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => 
        {
            return MyBoundTextBox.Text;
        }).AsTask().Result;
    }
    set
    {
        Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => 
        {
            MyBoundTextBox.Text = value;
            // Safely trigger the ValueChanged event
            OnValueChanged(oldValue, value);
        }).AsTask().Wait();
    }
}

2. Safely Trigger the ValueChanged Event #

Never fire an event without checking if there are subscribers first—this is almost certainly what’s causing that "event unable to invoke" inner exception. Here’s the safe way to do it:

private void OnValueChanged(string oldValue, string newValue)
{
    // Capture the handler first to avoid race conditions
    var handler = ValueChanged;
    if (handler != null)
    {
        var args = new AutomationPropertyChangedEventArgs(
            ValuePatternIdentifiers.ValueProperty, 
            oldValue, 
            newValue);
        handler(this, args);
    }
}

Or if you’re using C# 6+, you can simplify this with the null-conditional operator:

ValueChanged?.Invoke(this, new AutomationPropertyChangedEventArgs(
    ValuePatternIdentifiers.ValueProperty, oldValue, newValue));

3. Validate Control State Before Accessing Resources #

Make sure your IValueProvider doesn’t try to interact with a control that’s no longer available. Add checks for the control’s existence and loaded state:

public string Value
{
    get
    {
        if (MyBoundTextBox == null || !MyBoundTextBox.IsLoaded)
        {
            throw new ElementNotAvailableException();
        }
        // Proceed with getting the value
        return Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => 
        {
            return MyBoundTextBox.Text;
        }).AsTask().Result;
    }
}

4. Debug the Framework’s Call Flow #

To pinpoint exactly where things are breaking, set a breakpoint on UITestControl.get_Name() in your test code, then step into the framework calls. You’ll eventually hit your IValueProvider implementation—this will show you which line is throwing the exception. You can also enable UI Automation debug logging (via Visual Studio’s test settings) to get a detailed log of how the framework is interacting with your control.

Wrap-Up #

This issue is all about making sure your IValueProvider implementation follows the UI Automation framework’s rules, especially around thread safety and event handling. Fix those two areas, and you’ll be able to keep your IValueProvider functionality without hitting that UITestControlNotAvailableException.

内容的提问来源于stack exchange，提问作者Florian