{"id":5226,"date":"2026-10-05T17:13:10","date_gmt":"2026-10-05T17:13:10","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/10\/05\/uwp-and-winui-3-apps-ui-testing-with-mstest\/"},"modified":"2026-10-05T17:13:10","modified_gmt":"2026-10-05T17:13:10","slug":"uwp-and-winui-3-apps-ui-testing-with-mstest","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/10\/05\/uwp-and-winui-3-apps-ui-testing-with-mstest\/","title":{"rendered":"UWP and WinUI 3 apps: UI testing with MSTest"},"content":{"rendered":"

Reliable testing of UWP and WinUI 3 apps needs the app\u2019s real UI dispatcher,
\nnot just a single-threaded apartment (STA) thread, so that test setup, async
\ntest code, and cleanup all run with UI-thread access. A WinUI 3 test still
\nlooks this simple:<\/p>\n

[UITestMethod]\npublic async Task GridCanBeCreatedOnTheUIThread()\n{\n    await Task.Yield();\n\n    var grid = new Grid();\n\n    Assert.IsTrue(grid.DispatcherQueue.HasThreadAccess);\n}<\/code><\/pre>\n
With MSTest<\/a>
\n4.5 and Microsoft.Testing.Platform<\/a> (MTP) 2.5,
\nyou can use the same UI-thread testing pattern for UWP and WinUI 3 apps. The
\nsupported models are classic and modern UWP, packaged or unpackaged WinUI 3,
\nand WinUI hosts that use AppContainer.
\nMSTest.Sdk<\/code> picks the launch path for each model. It starts unpackaged apps
\ndirectly and uses
\nMicrosoft.Testing.Extensions.PackagedApp<\/code><\/a>
\nto register and activate packaged apps by AUMID. For AppContainer hosts, it
\nalso grants the exact package SID access to the controller and report pipes.
\nPackaged and sandboxed apps do not start as the initial test tool.
\nMSTest.Sdk<\/code> launches a normal full-trust sidecar controller that owns
\ntest arguments, cancel requests, reports, retries, and the final exit code. It
\nthen starts the app that hosts the tests. No Microsoft.NET.Test.Sdk<\/code>,
\nvstest.console<\/code>, UwpTestHostRuntimeProvider<\/code>, or Visual Studio deployment
\nruntime is used.<\/p>\n
For more background, read the
\nintroduction to MSTest.Sdk<\/a>
\nand the overview of
\nMicrosoft.Testing.Platform support across .NET test frameworks<\/a>.<\/p>\n\n
\n
<\/i>Packaged activation needs machine setup<\/strong><\/p>\n
To register an unsigned build-output layout, you need Developer Mode or a similar sideloading policy. Therefore, run AppContainer tests non-elevated, and confirm the policy on your CI agent, not just your workstation.<\/p><\/div>\n
Choose the model for UWP and WinUI 3 apps<\/h2>\n
Packaging and sandboxing are separate choices. Packaging adds MSIX
\nidentity and AUMID activation; the trust level decides whether the process is
\nfull trust or runs in AppContainer.<\/p>\n
\"Application<\/p>\n\n\n\n\n\n\n\n\n\n
Application model<\/th>\nIdentity and trust<\/th>\nMTP test-host path<\/th>\n<\/tr>\n<\/thead>\n
Classic UWP<\/a> (uap10.0<\/code>)<\/td>\nMSIX, AppContainer<\/td>\nSidecar controller, UAP adapter\/bootstrap assets, AUMID activation<\/td>\n<\/tr>\n
Modern UWP<\/a> (UseUwp<\/code>)<\/td>\nMSIX, AppContainer<\/td>\nSidecar controller, Native AOT host, AUMID activation<\/td>\n<\/tr>\n
Unpackaged WinUI 3<\/a><\/td>\nNo package identity, full trust<\/td>\nDirect apphost launch<\/td>\n<\/tr>\n
Packaged WinUI 3<\/a><\/td>\nMSIX, full trust<\/td>\nSidecar controller, package registration, AUMID activation<\/td>\n<\/tr>\n
WinUI 3 packagedClassicApp<\/code> with AppContainer trust<\/a><\/td>\nMSIX, AppContainer<\/td>\nSidecar controller and exact package-SID pipe authorization<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
For WinUI, start unpackaged unless the behavior under test needs package
\nidentity, packaged activation contracts, or an exact match with installed app
\nbehavior. In contrast, UWP is inherently packaged and sandboxed.<\/p>\n
Select MSTest.Sdk and MTP for UWP and WinUI 3 apps<\/h2>\n
At the solution or repo root, use global.json<\/code> to pin MSTest.Sdk 4.5
\nand select Microsoft.Testing.Platform for the native .NET 10
\ndotnet test<\/code> experience:<\/p>\n
{\n  \"test\": {\n    \"runner\": \"Microsoft.Testing.Platform\"\n  },\n  \"msbuild-sdks\": {\n    \"MSTest.Sdk\": \"4.5.0\"\n  }\n}<\/code><\/pre>\n
Otherwise, .NET 10 uses VSTest for dotnet test<\/code>.
\nMSTest.Sdk 4.5 includes MTP 2.5, the app-model sidecar controller, UWP
\nadapter\/bootstrap assets, and the packaged launcher.<\/p>\n
Configure UWP and WinUI 3 apps<\/h2>\n
Modern UWP<\/h3>\n
For a modern UWP project, the test setup is small:<\/p>\n
<Project Sdk=\"MSTest.Sdk\">\n  <PropertyGroup>\n    <TargetFramework>net10.0-windows10.0.26100.0<\/TargetFramework>\n    <UseUwp>true<\/UseUwp>\n    <PublishAot>true<\/PublishAot>\n  <\/PropertyGroup>\n<\/Project><\/code><\/pre>\n
Keep the app\u2019s XAML, manifest, architecture, and Native AOT settings. Then,
\nfrom OnLaunched<\/code>, pass the activation string to the generated MTP helper:<\/p>\n
using Microsoft.Testing.Extensions;\n\nprotected override async void OnLaunched(LaunchActivatedEventArgs args)\n{\n    Window.Current.Activate();\n    string[] testArguments =\n        PackagedAppExtensions.GetTestApplicationArguments(args.Arguments);\n    Environment.ExitCode =\n        await MicrosoftTestingPlatformApplication.RunAsync(testArguments);\n    Exit();\n}<\/code><\/pre>\n
Classic UWP<\/h3>\n
Classic uap10.0<\/code> projects keep their existing UWP project structure and
\nimport MSTest.Sdk<\/code> alongside MSBuild.Sdk.Extras<\/code>. MSTest 4.5 includes the
\nUAP-compatible adapter, generated bootstrap, packaged-app launcher, and TRX
\nclient assets. The sidecar builds the .build.appxrecipe<\/code> layout,
\ninstalls its declared frameworks, and starts the app by AUMID.<\/p>\n
Classic and modern UWP builds still need the Visual Studio MSBuild\/UWP
\ntoolchain. However, they no longer need its VSTest runtime or deployment
\nprovider.
\nSee the UWP and WinUI testing guide<\/a>
\nfor the complete classic project imports and package layout.<\/p>\n
Therefore, run UWP tests from a Developer PowerShell for Visual Studio. Build
\nwith the desktop MSBuild toolchain, then invoke the MTP target:<\/p>\n
msbuild .MyUwpTests.sln \/restore \/p:Configuration=Release \/p:Platform=x64\nmsbuild .MyUwpTests.csproj \/t:InvokeTestingPlatform \/p:Configuration=Release \/p:Platform=x64<\/code><\/pre>\n
AppContainer-configured WinUI 3<\/h3>\n
A packaged WinUI 3 app is full trust by default. For example, to test a
\nsupported packagedClassicApp<\/code> AppContainer setup, keep the packaged WinUI host
\nshown below and set uap10:TrustLevel=\"appContainer\"<\/code> in the manifest. The
\nhost still receives normal process arguments, while MTP grants only that
\npackage SID access to its controller, cancellation, TRX, HangDump, and Retry
\npipes. Do not grant ALL APPLICATION PACKAGES<\/code>.<\/p>\n
Then, run this AppContainer shape from a non-elevated Developer PowerShell
\nthrough the MTP MSBuild target:<\/p>\n
dotnet build .MyAppContainerTests.csproj -c Release -p:Platform=x64\ndotnet msbuild .MyAppContainerTests.csproj \/t:InvokeTestingPlatform \/p:Configuration=Release \/p:Platform=x64<\/code><\/pre>\n
Build the self-hosted WinUI 3 test app<\/h2>\n
The following complete WinUI 3 test app supplies that dispatcher and runs
\nMSTest inside the app itself. Build this shared host once; the packaged and
\nunpackaged deltas come afterward. Three pieces make up that shared project:<\/p>\n
\"The<\/p>\n
Configure the shared project<\/h3>\n
You need Windows, the .NET 10 SDK, and the Windows App SDK tooling (installed
\nby Visual Studio\u2019s \u201cWindows application development\u201d workload, or restored
\nfrom NuGet if you build from the CLI). Then, start from Visual Studio\u2019s
\n\u201cBlank App, Packaged (WinUI 3 in Desktop)\u201d template, retain its
\nPackage.appxmanifest<\/code> and package assets for the packaged form, and apply
\nthis shared project setup.<\/p>\n
<Project Sdk=\"MSTest.Sdk\">\n  <PropertyGroup>\n    <OutputType>Exe<\/OutputType>\n    <TargetFramework>net10.0-windows10.0.19041.0<\/TargetFramework>\n    <TargetPlatformMinVersion>10.0.17763.0<\/TargetPlatformMinVersion>\n    <UseWinUI>true<\/UseWinUI>\n    <ImplicitUsings>enable<\/ImplicitUsings>\n    <Nullable>enable<\/Nullable>\n  <\/PropertyGroup>\n\n  <ItemGroup>\n    <Page Remove=\"UnitTestApp.xaml\" \/>\n    <ApplicationDefinition Include=\"UnitTestApp.xaml\" \/>\n    <ProjectCapability Include=\"TestContainer\" \/>\n  <\/ItemGroup>\n\n  <ItemGroup>\n    <PackageReference Include=\"Microsoft.WindowsAppSDK\"\n                      Version=\"1.8.251106002\" \/>\n  <\/ItemGroup>\n<\/Project><\/code><\/pre>\n
Define the application entry point<\/h3>\n
The ApplicationDefinition<\/code> points to this minimal UnitTestApp.xaml<\/code>:<\/p>\n
<Application\n    x:Class=\"MyWinUiTests.UnitTestApp\"\n    xmlns=\"http:\/\/schemas.microsoft.com\/winfx\/2006\/xaml\/presentation\"\n    xmlns:x=\"http:\/\/schemas.microsoft.com\/winfx\/2006\/xaml\">\n  <Application.Resources \/>\n<\/Application><\/code><\/pre>\n
Host the test run from OnLaunched<\/h3>\n
The WinUI app owns its entry point through this ApplicationDefinition<\/code>.
\nMSTest.Sdk<\/code> detects that entry point, suppresses its own competing Main<\/code>,
\nand generates a reusable MicrosoftTestingPlatformApplication.RunAsync<\/code>
\nhelper. Finally, the app\u2019s code-behind creates the window, publishes its
\ndispatcher, and calls that helper:<\/p>\n
using Microsoft.UI.Xaml;\nusing Microsoft.VisualStudio.TestTools.UnitTesting.AppContainer;\n\nnamespace MyWinUiTests;\n\npublic partial class UnitTestApp : Application\n{\n    private Window? _window;\n\n    public UnitTestApp() => InitializeComponent();\n\n    protected override async void OnLaunched(LaunchActivatedEventArgs args)\n    {\n        _window = new Window();\n        _window.Activate();\n        UITestMethodAttribute.DispatcherQueue = _window.DispatcherQueue;\n\n        try\n        {\n            Environment.ExitCode = await MicrosoftTestingPlatformApplication.RunAsync(Environment.GetCommandLineArgs()[1..]);\n        }\n        finally\n        {\n            _window.Close();\n            Exit();\n        }\n    }\n}<\/code><\/pre>\n
That single OnLaunched<\/code> override plays out in this order every time the app
\nstarts, whether launched directly or activated by AUMID:<\/p>\n
sequenceDiagram\n    participant OS as Windows\n    participant App as UnitTestApp.OnLaunched\n    participant MTP as Microsoft.Testing.Platform\n    participant Tests as MSTest UITestMethod tests\n\n    OS->>App: Launch (apphost or AUMID activation)\n    App->>App: Create and activate the Window\n    App->>Tests: Publish UITestMethodAttribute.DispatcherQueue\n    App->>MTP: MicrosoftTestingPlatformApplication.RunAsync\n    MTP->>Tests: Run tests on the published dispatcher\n    MTP-->>App: Test-run result\n    App->>App: Environment.ExitCode = result\n    App->>OS: Window.Close + Exit<\/code><\/pre>\n
Assigning Environment.ExitCode<\/code> is important: a WinUI-generated entry point
\nreturns void<\/code>, so without it a failing test run can look successful to a
\nbuild or CI system. MSTest.Sdk<\/code> owns MSTest references, extension
\nregistration, and the packaged-app launcher registration. The
\nWinUI testing guide<\/a>
\ncovers the generated helper and hosting model in more depth.<\/p>\n
Verify the dispatcher in a UI test<\/h3>\n
The app and tests now form one host. For example, this async test
\nchecks that TestInitialize<\/code>, the test body, and TestCleanup<\/code> keep access to
\nthe UI dispatcher:<\/p>\n
using Microsoft.UI.Dispatching;\nusing Microsoft.UI.Xaml.Controls;\nusing Microsoft.VisualStudio.TestTools.UnitTesting;\n\nnamespace MyWinUiTests;\n\n[TestClass]\npublic sealed class ViewTests\n{\n    private bool _initializedOnUiThread;\n    private bool _verifyCleanupOnUiThread;\n\n    [TestInitialize]\n    public async Task InitializeAsync()\n    {\n        await Task.Yield();\n        _initializedOnUiThread =\n            DispatcherQueue.GetForCurrentThread()?.HasThreadAccess == true;\n    }\n\n    [TestCleanup]\n    public async Task CleanupAsync()\n    {\n        await Task.Yield();\n\n        if (_verifyCleanupOnUiThread)\n        {\n            Assert.IsTrue(\n                DispatcherQueue.GetForCurrentThread()?.HasThreadAccess == true);\n        }\n    }\n\n    [UITestMethod]\n    public async Task ControlCanBeCreatedAfterAsyncInitialization()\n    {\n        _verifyCleanupOnUiThread = true;\n        await Task.Yield();\n\n        var grid = new Grid();\n\n        Assert.IsTrue(_initializedOnUiThread);\n        Assert.IsTrue(grid.DispatcherQueue.HasThreadAccess);\n    }\n}<\/code><\/pre>\n
[STATestMethod]<\/code> can provide an STA thread, but it does not create a WinUI
\ndispatcher. [UITestMethod]<\/code> dispatches the full MSTest call for each test,
\nincluding its setup and cleanup.<\/p>\n
Apply deployment models to UWP and WinUI 3 apps<\/h2>\n
For UWP and WinUI 3 apps, apply the delta that matches the deployment model
\nyou chose in \u201cChoose the model for UWP and WinUI 3 apps.\u201d MSTest.Sdk<\/code> keeps
\nthe runner setup shared between both models.<\/p>\n
Unpackaged WinUI 3 (default choice)<\/h3>\n
Add these properties and do not include MSIX manifest or package asset items:<\/p>\n
<PropertyGroup>\n  <WindowsPackageType>None<\/WindowsPackageType>\n  <EnableMsixTooling>false<\/EnableMsixTooling>\n<\/PropertyGroup><\/code><\/pre>\n
The resulting apphost is a standard executable. As a result,
\nMicrosoft.Testing.Platform uses its normal launch path, and this route does
\nnot use VSTest\u2019s appx runtime provider.<\/p>\n
Packaged full-trust WinUI 3 (when you need identity)<\/h3>\n
Remove the two unpackaged overrides; do not leave
\n<WindowsPackageType>None<\/WindowsPackageType><\/code> in the project. Retain the
\ntemplate\u2019s normal Package.appxmanifest<\/code> and package assets. The output then
\nhas MSIX identity, so Windows must register the package layout and activate the
\ntest host by AUMID. It needs a Windows target framework moniker (TFM) at
\n10.0.19041.0<\/code> or later and Developer Mode or a similar sideloading policy for
\nunsigned build output.<\/p>\n
In addition, MSTest.Sdk<\/code> adds and registers the packaged-app launcher for
\npackaged WinUI projects. Leave
\nTESTINGPLATFORM_PACKAGEDAPP_LAUNCHER<\/code> unset. Its default, auto<\/code>, enables the
\npackaged launch path only when a matching AppxManifest.xml<\/code> describes the
\napp. Otherwise it keeps the normal, faster launch path with no controller
\nrestart or deployment-copy overhead. The
\nWinUI testing guide<\/a>
\ncovers the always<\/code> and never<\/code> overrides for less common scenarios.<\/p>\n\n
\n
<\/i>Validate on your CI agent first<\/strong><\/p>\n
Confirm Developer Mode (or your sideloading policy) and a clean, passing exit code on your own packaged app and CI agent, as covered in \u201cPackaged activation needs machine setup\u201d above, before wiring this into a required gate.<\/p><\/div>\n
Run it<\/h3>\n
Use dotnet run<\/code> for either deployment model. It launches the generated
\napphost, which hosts Microsoft.Testing.Platform inside the process that owns
\nthe window and dispatcher:<\/p>\n
dotnet run<\/code><\/pre>\n
The .NET 10 native MTP runner also supports dotnet test<\/code> for either
\ndeployment model:<\/p>\n
dotnet test --project .MyWinUiTests.csproj -c Release -a x64<\/code><\/pre>\n
For an unpackaged app, you can also launch the generated apphost directly.
\nHowever, do not use dotnet exec<\/code>, which puts dotnet.exe<\/code> in the middle and
\ncan break WinUI resource loading.<\/p>\n
A window flashes briefly while the test runs, and the console reports a
\nsummary:<\/p>\n
Passed! - Failed: 0, Passed: 1, Skipped: 0, Total: 1, Duration: 63ms - MyWinUiTests.dll (net10.0-windows10.0.19041.0)<\/code><\/pre>\n
The packaged development layout can remain registered after the run. Remove
\nit when needed by using its manifest Identity<\/code> name:<\/p>\n
Get-AppxPackage -Name '<package identity name>' |\n  Remove-AppxPackage -PreserveApplicationData<\/code><\/pre>\n
Validate UWP and WinUI 3 apps on the target machine<\/h2>\n
For a packaged test host, a passing build is only the first step. Therefore,
\ncheck your actual CI agent image, not just a developer workstation, for a user
\ncontext that can register the package, the required Developer Mode or
\nsideloading policy, and the frameworks declared by the package. Otherwise, a
\nworkstation that already has the UWP framework packages or Windows App SDK
\nruntime installed can hide a gap that only appears on a clean build agent.<\/p>\n
Framework-dependent WinUI 3 apps need the matching Windows App SDK runtime on
\nthe agent. A self-contained WinUI 3 build can remove that machine need, but test
\nit using the exact package model that will run in CI.<\/p>\n
Start testing UWP and WinUI 3 apps<\/h2>\n
Use this checklist to start testing UWP and WinUI 3 apps:<\/p>\n
    \n
  1. Select Microsoft.Testing.Platform in global.json<\/code> and use
    \nMSTest.Sdk<\/code> 4.5.<\/li>\n
  2. For modern UWP, set UseUwp<\/code> and PublishAot<\/code>. For classic UWP, import
    \nMSTest.Sdk<\/code> into the existing project. For WinUI 3, set UseWinUI<\/code> and
    \nchoose packaged or unpackaged deployment.<\/li>\n
  3. Call the generated MicrosoftTestingPlatformApplication.RunAsync<\/code> helper
    \nfrom OnLaunched<\/code>. Modern UWP restores args.Arguments<\/code> through
    \nPackagedAppExtensions.GetTestApplicationArguments<\/code>; WinUI uses process
    \narguments. Publish the UI dispatcher where required.<\/li>\n
  4. Run full-trust WinUI with dotnet run<\/code> or dotnet test<\/code>. Run UWP and
    \nAppContainer WinUI through the InvokeTestingPlatform<\/code> MSBuild target from
    \na non-elevated Developer PowerShell.<\/li>\n
  5. For packaged and AppContainer models, confirm Developer Mode (or your
    \nsideloading policy) and run non-elevated on the test agent.<\/li>\n<\/ol>\n
    Get the UWP and WinUI testing guide<\/a><\/div>\n
    One test platform for UWP and WinUI 3 apps<\/h2>\n
    Keep MSTest.Sdk<\/code>, the generated MTP helper, and [UITestMethod]<\/code> across the
    \nWindows app models. Let the SDK choose direct startup for unpackaged
    \nWinUI or the sidecar controller for package registration, AUMID activation,
    \nand AppContainer isolation.<\/p>\n
    Three takeaways to carry forward:<\/p>\n