StockSharp DesktopDriver

StockSharp DesktopDriver

Drive desktop applications built on Avalonia, WPF or MAUI from tests, from a command line, or from an AI agent over MCP.

DesktopDriver reads the interface, not the screen. A table answers with its columns and rows, a tree with its items, a workspace with its panels - in words that do not change with a theme, a font or a language. Input goes through the toolkit's own pipeline, and only into a run that cannot reach anything real. Pictures are there for a person to look at; tests check what the controls say.

How it works

1. An application that can be driven references the bootstrap of its toolkit. Started the ordinary way it opens nothing. Started with --ui-automation, it opens a local named-pipe endpoint restricted to the current OS user, and writes where the endpoint is to the file named by --ui-automation-endpoint=<path>.
2. A runner - a test, the command line, the MCP server - starts the application that way (or attaches to one somebody else started), checks the product, instance and protocol in the session handshake and asks: which windows are open, what is in this one, what does this table show. It can then click, type, press keys and scroll, and wait for the answer to change.
3. Adapters turn controls into what the protocol knows: grids, trees, lists, pickers, workspaces, charts, documents, diagrams. An application registers adapters for its own controls through the same interface the standard ones use.

NuGet packages

Install the CLI or MCP server with the .NET 10 SDK:

dotnet tool install StockSharp.DesktopDriver.Cli --tool-path tools
dotnet tool install StockSharp.DesktopDriver.Mcp --tool-path tools

The commands are tools/desktop-driver and tools/desktop-driver-mcp. To add automation to an application, reference the bootstrap package for its toolkit. To drive it from code, use the client, runner and testing packages.

For MCP Registry publication and Claude Desktop extensions, see MCP distribution.

Make an application drivable

Avalonia, once the main window exists (the sample does the same with the grid module alone):

public override void OnFrameworkInitializationCompleted()
{
	if (ApplicationLifetime is IClassicDesktopStyleApplicationLifetime desktop)
	{
		desktop.MainWindow = new MainWindow();

		if (UiAutomationLaunch.TryRead(desktop.Args) is { } launch)
		{
			_automation = AvaloniaAutomationBootstrap.Start(
				UiAutomationStartup.For("my.app", version, fixtureId: null, hasLiveOutsideWorld: false, isTestProfile: false),
				launch.EndpointFile,
				[binder => new DataGridAutomationModule(binder), binder => new DockAutomationModule(binder)]);
		}
	}

	base.OnFrameworkInitializationCompleted();
}

Dispose the returned runtime when the application exits. WpfAutomationBootstrap and MauiAutomationBootstrap take the same arguments.

The sample applications show startup and shutdown for all three toolkits. The WPF and MAUI Windows samples also have tests that start their executables, connect over the local pipe, read their controls, send input and retrieve screenshots.

UiAutomationStartup.For decides whether input is allowed. An application that talks to nothing outside its own process is always safe to click through. One that connects to something real - a broker, a store, a service - is safe only when it was started on a test profile that replaces it; otherwise the endpoint still reads, but every input is refused.

Many applications ship two builds: an ordinary one with no driver in it, and one made to be driven. The driver is only referenced by the second, so the first has nothing listening by construction.

Drive it

From a test:

await using var app = await DrivenApplication.StartAsync(executable, extraArguments: null, TimeSpan.FromSeconds(60), cancellationToken);
await using var client = await app.ConnectAsync("my.app", cancellationToken);

var windows = await client.GetSurfacesAsync(cancellationToken);

From a command line, against an application somebody started with --ui-automation:

tools/desktop-driver find --endpoint endpoint.json --kind grid
tools/desktop-driver grid-rows --endpoint endpoint.json --node window:MainWindow/Instruments --limit 5

desktop-driver with no arguments prints every operation.

From an agent: register the MCP server, see DesktopDriver.Mcp.

Its MCP name is StockSharp.DesktopDriver, and its display title is StockSharp DesktopDriver.

Documents

• How the driver is built
• The protocol
• What answers for which control, and how to add an adapter
• The command line
• The MCP server
• Builds, test suites and releases
• Sample applications and Windows integration tests

Build and test

dotnet build DesktopDriver.slnx
dotnet test DesktopDriver.Runtime.Tests --filter "FullyQualifiedName~Revision"

The MAUI projects need the MAUI Windows workload. MCP application tests, WPF screenshot tests and DesktopDriver.Windows.Tests need an interactive Windows desktop session. Run the filtered suites with hang and session timeouts using ./.github/scripts/Test.ps1 -Suite Headless or -Suite Desktop after a Release build.

Packages from source

dotnet pack DesktopDriver.slnx -c Release -o artifacts/packages

Sources instead of packages

A product checked out beside this repository can reference the projects themselves:

<ProjectReference Include="..\DesktopDriver.Mcp\DesktopDriver.Bootstrap.Avalonia\DesktopDriver.Bootstrap.Avalonia.csproj" />

A product that builds a second, drivable copy of itself by passing a property on the command line adds GlobalPropertiesToRemove="<that property>" to the reference: the driver has no build of its own for it, and would otherwise be built twice into the same folder.

License

See LICENSE.