FlaUI: a .NET wrapper for Microsoft UI Automation on Windows

The problem FlaUI solves, and who it is for

Microsoft ships UI Automation as part of Windows. It is the accessibility and test automation layer that exposes windows, buttons, text fields and lists as a tree of elements with properties and patterns. Calling it directly from .NET is possible but unpleasant, and the two available flavours behave differently. UIA2 is the managed library for the native UI Automation API. UIA3 is the COM library. According to the README, UIA2 is managed only and does not support newer features such as touch, and it works poorly with WPF and worse with Windows Store apps. UIA3 works well for WPF and Store apps but can have bugs with WinForms applications that do not exist in UIA2.

FlaUI exists so you do not have to pick one and rewrite later, and so you do not have to write the wrapper yourself. The README describes it as a .NET library for automated UI testing of Windows applications (Win32, WinForms, WPF, Store Apps), based on the native UI Automation libraries from Microsoft, and therefore kind of a wrapper around them. It also states that FlaUI wraps almost everything from those libraries but still exposes the native objects for cases the wrapper does not cover.

The intended reader is a developer or QA engineer who writes C# and needs to drive a desktop application from a test. The README is explicit that some ideas come from UIAComWrapper and TestStack.White, but that FlaUI was rewritten from scratch to have a clean codebase. That rewrite is the selling point: TestStack.White has separate UIA2 and UIA3 versions, and the README argues its old codebase makes UIA3 hard to get working, with UIAComWrapper adding one more source of errors.

How FlaUI sits between your test and the Windows UI tree

The data flow has three layers. At the bottom is the native UI Automation provider inside the application under test. Above it sits either UIA2 or UIA3, chosen by you. Above that sits FlaUI, which normalises both into a common API and adds convenience such as element search and application lifecycle helpers.

The README describes the entry point as usually an application or the desktop, from which you get an automation element such as the main window. From there you search sub-elements and interact with them. There is a helper class to launch, attach or close applications. Because the application object is not tied to any UIA library, you create the automation you want and use it to obtain your first element.

Two details in that design matter. First, the automation object is disposable, which the README's example shows with a using block. Second, element searches are expressed as conditions rather than strings. The README's calculator example uses window.FindFirstDescendant(cf => cf.ByText("1")) and then calls AsButton() on the result, with a null-conditional operator before Invoke(). That pattern tells you a search returns a generic element that you cast to a typed control before acting on it.

The wrapper is not total. The README states that FlaUI provides the native objects in case someone has a special need which is not covered yet, so you can drop to the underlying UIA2 or UIA3 interface when a pattern or property has no FlaUI equivalent.

Installing FlaUI from NuGet and driving Notepad

The README's installation section says you need to reference the appropriate assemblies, and that you should decide whether you want UIA2 or UIA3 and install the corresponding library from NuGet. It also notes you can download the source and compile it yourself. The three packages named in the README's badge table are FlaUI.Core, FlaUI.UIA3 and FlaUI.UIA2, so UIA3 is a separate package from the core library.

The README's first code example launches Notepad, creates a UIA3Automation instance, gets the main window and prints its title:

using FlaUI.UIA3;

var app = FlaUI.Core.Application.Launch("notepad.exe");
using (var automation = new UIA3Automation())
{
    var window = app.GetMainWindow(automation);
    Console.WriteLine(window.Title);
}

What you should see is the title of the Notepad main window written to the console. The README shows an ellipsis after that line, indicating it is the starting point rather than a complete test.

The second README example finds a button by its text and invokes it. Note the comment attached to it: it works only pre-Windows 8 with the legacy calculator, because the modern calculator exposes a different element tree.

using FlaUI.Core.AutomationElements;
using FlaUI.UIA3;

// Note: Works only pre-Windows 8 with the legacy calculator
var app = FlaUI.Core.Application.Launch("calc.exe");
using (var automation = new UIA3Automation())
{
    var window = app.GetMainWindow(automation);
    var button1 = window.FindFirstDescendant(cf => cf.ByText("1"))?.AsButton();
    button1?.Invoke();
}

To swap to UIA2, replace UIA3Automation with UIA2Automation and reference the FlaUI.UIA2 package instead. The README presents this as the reason the library exists, so the swap should be a change of automation class rather than a rewrite of your element searches.

The UIA2 and UIA3 split is a real limitation, not a footnote

The most important thing about FlaUI is also the least convenient: it does not hide the difference between the two automation libraries. The README states plainly that UIA3 can have some bugs with WinForms applications which are not existent in UIA2. It does not enumerate those bugs in the README; it points to a FAQ page in the project wiki. That means the failure mode you are most likely to hit is not a FlaUI bug at all, but a mismatch between the automation library you chose and the framework your application is built with.

The practical consequence is that you should decide early. If your application under test is WPF or a Store app, UIA3 is the natural choice according to the README. If it is WinForms, UIA2 may be the safer one. If you maintain tests for several applications built on different frameworks, you may end up with both packages in the same solution and different automation objects per test fixture. FlaUI supports that because the application helper is independent of the automation library, but it is extra configuration you will own.

There is a second boundary. FlaUI targets Windows applications. The README's list is Win32, WinForms, WPF and Store Apps. Nothing in the README suggests it automates browsers, macOS or Linux, and it is not a cross-platform tool. If your product ships a web front end, a Windows-only library is the wrong layer to test it in.

FlaUI compared with TestStack.White and WinAppDriver

TestStack.White is the closest free alternative and the one the README discusses at length. The difference is architectural. White has two versions, one for UIA2 and one for UIA3, and the README argues its old codebase makes UIA3 hard to bring to work. It also uses UIAComWrapper, which the README says wraps the UIA3 COM interop with the same naming as the managed UIA2, adding one more source of errors. FlaUI instead exposes a single interface for UIA2 and UIA3 where the developer chooses which version to use, and keeps the native objects reachable. If you are starting fresh in C#, the README's own comparison favours FlaUI on codebase age and on the number of layers between your test and the UI tree.

WinAppDriver is a different shape of tool. It is a WebDriver-based server for Windows desktop applications, so your tests speak the WebDriver protocol over HTTP rather than calling .NET objects in process. That is an advantage if your test stack is already WebDriver-based and you want one runner for web and desktop, and a disadvantage if you want to inspect a property that the WebDriver mapping does not expose. FlaUI gives you the object model directly, which is more control and more responsibility.

Neither comparison is settled by the README, which does not benchmark either tool. What the README does establish is the design goal: a clean, modern codebase for collaboration, with both UIA versions available behind one interface.

Maintenance, licence and upgrade cost

FlaUI is licensed under the MIT licence, and the LICENSE.txt file sits at the repository root. MIT is permissive: it allows use, modification and redistribution, including in closed-source products, provided the copyright notice and licence text are kept. That is a general description of the licence, not legal advice, and if you ship FlaUI inside a commercial product you should confirm the notice requirements with your own counsel.

The release history shows a slow cadence. v3.2.0 was released on 2020-07-17, v4.0.0 on 2022-09-25, and v5.0.0 on 2025-02-25. The gap between v4 and v5 is roughly two and a half years, so a major version bump is not something you plan a sprint around. The last push to the default branch was on 2026-08-13, which is recent enough that the repository is not dormant, but the release tags are what most consumers will actually pin. The CHANGELOG.md file at the root is where the project records what changed between those tags, and it is the first place to look before moving a test suite from one major version to the next.

Because the library wraps Microsoft's UI Automation rather than reimplementing it, part of your upgrade risk is Windows-side rather than FlaUI-side. The README's calculator example is a small illustration: the sample works only pre-Windows 8 with the legacy calculator, so an application changing its UI toolkit can invalidate element searches even when the FlaUI version is unchanged.

Editorial conclusion

Adopt FlaUI if you are writing C# tests against Windows desktop applications and you want direct access to the native UI Automation objects rather than a wrapper of a wrapper. Do not adopt it if your target is a browser or a mobile app, or if your team has no C# and wants a keyword-driven tool. Before committing, verify which automation library your application needs by launching it and reading the main window title with both UIA2Automation and UIA3Automation, because the README states UIA3 can have bugs with WinForms that UIA2 does not have, and that difference will shape the rest of your test suite.

Frequently asked questions

Official sources

1. FlaUI/FlaUI on GitHub
2. Issues
3. License: MIT
4. README
5. Releases