Development Environment & Tooling

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production; see the section bibliography for the reference material consulted while preparing these pages.

Before the first line of XAML is written, a Windows desktop developer needs an SDK, an IDE with the right workload, a way to run unsigned code during development, and tools that shorten the edit-run-inspect loop. This page covers that environment for the section’s running application, Bookshelf Desktop, and the tools used to inspect it while it runs.

The page was written against these versions, as verified on 2026-10-23:

.NET 10 LTS, latest patch 10.0.13, supported until 2028-11-14, and C# 14. .NET 8 and .NET 9 go out of support on 2026-11-10. .NET 11 is at release candidate 2 (go-live licence); general availability is expected at .NET Conf, 10-13 November 2026, and this page notes where it matters once it ships.
Visual Studio 2026, latest release 18.11.1. Feature updates ship monthly, so menu names can move between updates.
Windows App SDK 2.5.1 (stable channel) for WinUI 3, and CommunityToolkit.Mvvm 8.4.2 for the view models used in later examples.
Windows 10 and Windows 11. The tools below run on both. Windows 11 is the recommended development machine; consult the supported-OS list of each product before relying on an older Windows 10 build.
The winapp CLI (Microsoft.WinAppCli) is in public preview, v0.7.1 at the time of writing, so its commands and options can change between releases.

The C# language itself and the dotnet command line are covered on Getting Started with C# and Build and Tooling in the C# reference. This page adds what is specific to desktop UI development. The project files that these tools generate are explained on the section page Project Structure & Build, and the stack choice on Windows App Platforms: WPF, WinUI 3, WinForms, MAUI & More.

The Toolchain at a Glance

A desktop workstation is assembled from a handful of independent pieces. The table lists each one, what it gives you and which UI stacks need it.

Table 1. Components of a Windows desktop development environment
Component	Purpose	WPF	WinUI 3	WinForms
Windows 10 / 11	The target and, usually, the development OS. WPF and Windows Forms build only for Windows.	yes	yes	yes
.NET 10 SDK	Compiler, MSBuild, `dotnet` CLI and the Windows desktop targeting pack (`Microsoft.NET.Sdk.WindowsDesktop` is part of the SDK on Windows).	yes	yes	yes
Visual Studio 2026	IDE with designers, debugger, profilers, Hot Reload and the XAML diagnostic tools.	workload ".NET desktop development"	workload "WinUI application development"	workload ".NET desktop development"
Windows App SDK	The NuGet package family that supplies WinUI 3, windowing, app lifecycle and notifications. Restored per project; the SDK version equals the NuGet version since 2.0.	optional	required	optional
Developer Mode	Allows loose-file registration and sideloading of packages without a Store signature. Needed for packaged WinUI development and for debugging packaged apps.	rarely	yes, for packaged apps	rarely
winget	Installs the tools and, with `winget configure`, reproduces the whole setup from a file.	yes	yes	yes
winapp CLI	Preview command-line helper for manifests, debug identity, packaging and signing outside Visual Studio.	optional	optional	optional

Visual Studio is not mandatory. A WPF or Windows Forms application can be built with the .NET SDK and any editor, but the XAML designer, the WinForms designer and the XAML runtime tools described later are Visual Studio features. The official "start here" page of the Windows apps documentation lists the supported ways to begin.

Source: Start developing Windows apps

Developer Mode

Windows normally accepts only apps installed from the Microsoft Store or signed by a trusted certificate. Developer Mode relaxes this on a development machine. It enables the following behaviours:

installing packaged apps from loose files and from locally built packages, so that Visual Studio can deploy and debug a packaged WinUI 3 app (a layout deployment registers the files in the build output folder);
sideloading a package signed with a certificate that is not chained to a trusted root;
some developer-oriented settings of the Settings app, such as File Explorer and Terminal tweaks.

Developer Mode is a per-machine switch and requires administrative rights. Turn it on in Settings > System > For developers (Windows 11; on Windows 10 it is under Update & Security). It is not needed to run or debug a plain unpackaged WPF or Windows Forms executable, which is just a normal process.

Enabling and Checking It

The setting is stored in the registry under the AppModelUnlock key. The script below only reads that key, so it is safe to run without elevation and changes nothing. It reports whether Developer Mode and sideloading are on, which is the first thing to check when a packaged app refuses to deploy.

# Read-only: reports the Developer Mode and sideloading switches.
$path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock'

if (-not (Test-Path $path)) {
    Write-Output 'AppModelUnlock key not present: Developer Mode has never been configured.'
    return
}

$values = Get-ItemProperty -Path $path
[pscustomobject]@{
    DeveloperMode     = [bool]($values.AllowDevelopmentWithoutDevLicense -eq 1)
    SideloadTrustedApps = [bool]($values.AllowAllTrustedApps -eq 1)
}

A typical result on a configured machine:

DeveloperMode SideloadTrustedApps
------------- -------------------
         True                True

The two values map to the settings described in the official page: AllowDevelopmentWithoutDevLicense is the Developer Mode switch, and AllowAllTrustedApps allows installing apps from outside the Store. Group Policy or MDM can lock both, in which case the Settings toggle is disabled and an administrator must change the policy.

Source: Enable your device for development

Why It Is Not a Production Setting

Developer Mode weakens the platform’s install-time checks, so it belongs on development machines only. Customers install Bookshelf Desktop through signed packages, the Store or an installer; none of those paths requires Developer Mode. Publishing is covered on the section pages MSIX Packaging & Signing and Distribution Channels.

Visual Studio 2026 Workloads

The Visual Studio Installer groups components into workloads. Two of them matter for this section.

Table 2. Visual Studio 2026 workloads for desktop development
Workload	What it installs	Use it for
.NET desktop development	WPF and Windows Forms project templates, the XAML designer and the WinForms designer, the .NET SDK and targeting packs, NuGet and the profiling tools.	Bookshelf Desktop in WPF and in Windows Forms.
WinUI application development	The WinUI 3 templates, the Windows App SDK extension, the Windows SDK and the packaging tools used by single-project MSIX.	Bookshelf Desktop in WinUI 3, packaged or unpackaged.
Universal Windows Platform development	UWP templates. UWP is in maintenance mode and is not used by this section’s examples.	Maintaining an existing UWP app.
.NET Multi-platform App UI development	.NET MAUI templates, with Windows as one of the targets.	Cross-platform apps; see the section page .NET MAUI, UWP & Other Options.

Install the workloads from the Visual Studio Installer by choosing Modify on the installed instance. The installer also lets you export the selection as an .vsconfig file, which can be committed to the repository so that a new team member installs exactly the same components with the installer’s import feature or from the command line. This is independent of winget configure, which the next section uses for the machine-level setup.

Visual Studio 2026 is a side-by-side install, so it can coexist with Visual Studio 2022. A solution that contains net10.0-windows projects needs the .NET 10 SDK, which Visual Studio 2026 installs; Visual Studio 2022 does not support .NET 10 projects. Check the release notes for the exact component versions of the build you use.

Source: Visual Studio 2026 release notes

Repeatable Setup with winget configure

winget configure applies a WinGet configuration file: a YAML document that lists resources to bring the machine to a desired state. Resources are DSC (Desired State Configuration) resources, so the same file can install packages, turn on Developer Mode and run other settings modules. Running the file twice is safe because each resource first tests the current state.

The Windows apps documentation publishes a ready-made file for WinUI development at aka.ms/winui-config. The example below is a simplified file in the same format, adapted for Bookshelf Desktop. Save it as bookshelf.dev.winget.

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
properties:
  configurationVersion: 0.2.0
  resources:
    - resource: Microsoft.Windows.Developer/DeveloperMode
      directives:
        description: Enable Developer Mode
        allowPrerelease: true
      settings:
        Ensure: Present

    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: dotnet-sdk
      directives:
        description: Install the .NET 10 SDK
        allowPrerelease: true
      settings:
        id: Microsoft.DotNet.SDK.10
        source: winget

    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: git
      directives:
        description: Install Git
        allowPrerelease: true
      settings:
        id: Git.Git
        source: winget

    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: winapp-cli
      directives:
        description: Install the winapp CLI (public preview)
        allowPrerelease: true
      settings:
        id: Microsoft.WinAppCli
        source: winget

Apply it from an elevated terminal, because Developer Mode is a machine setting:

winget configure --file .\bookshelf.dev.winget --accept-configuration-agreements

The command prints the resources it is about to apply and then one result per resource. The output below is illustrative; the exact wording varies between winget versions.

Applying configuration...
  Enable Developer Mode ............ applied
  Install the .NET 10 SDK .......... applied
  Install Git ...................... already in the desired state
  Install the winapp CLI (public preview) ... applied
Configuration successfully applied.

Three practical points follow from how the feature works:

Configuration files are code that runs with your privileges. Read a file from the internet, including the aka.ms/winui-config one, before applying it, exactly as you would read an install script.
Package identifiers must be exact. Confirm them with winget search (for example, winget search "Microsoft.DotNet.SDK" or winget search "Visual Studio") because identifiers for new product versions are added over time. This page does not hard-code a Visual Studio 2026 identifier for that reason.
The Visual Studio workloads can also be requested from a configuration file, but the official page documents the package-level and settings-level resources; check the current resource list in the documentation before adding a workload resource.

Source: WinGet configuration

The winapp CLI

The winapp CLI (Microsoft.WinAppCli) is a command-line tool from Microsoft for the parts of Windows app development that traditionally needed Visual Studio dialogs or several separate SDK tools: working with the app manifest, giving an executable a debug package identity, building an MSIX package and signing it. It targets developers who use any framework (including WPF, Windows Forms, Electron or plain Win32), and CI pipelines.

It is in public preview, so treat the commands below as a starting point and run winapp --help to see what your installed version supports.

# Install (also done by the winget configuration file above)
winget install Microsoft.WinAppCli

# Confirm the installed version
winapp --version

# List the available commands and options of this version
winapp --help

The documented command groups include project initialisation, creating a debug identity for an unpackaged executable, packaging a build output folder as MSIX, generating a development certificate and signing a package. Their exact names and flags evolve with the preview. The distribution pages of this section show where each step fits in a release pipeline; they use the command names current at the time of writing and link back to the official reference.

What the official documentation does not provide is a stability guarantee for the preview: breaking changes between 0.x releases are possible, and the CLI should be pinned to a version in CI rather than installed as "latest".

Source: winapp CLI

Creating Projects with dotnet new

The .NET SDK ships templates for WPF and Windows Forms. They are the quickest way to create the Bookshelf Desktop solution without Visual Studio, and they are what scripts and CI use.

Table 3. Windows desktop templates in the .NET SDK
Template (short name)	Creates	Notes
`wpf`	WPF application	`net10.0-windows` WinExe with `App.xaml` and `MainWindow.xaml`.
`wpflib`	WPF class library	Reusable XAML resources and view code.
`wpfusercontrollib`	WPF user control library	Starts with a `UserControl`.
`wpfcustomcontrollib`	WPF custom control library	Starts with a templated control and `Themes/Generic.xaml`.
`winforms`	Windows Forms application	`Form1` with designer file; uses the out-of-process designer in Visual Studio.
`winformslib`	Windows Forms class library	Shared forms and components.
`winformscontrollib`	Windows Forms control library	Starts with a `UserControl`.
`classlib`, `xunit`, `mstest`, `nunit`	Non-UI projects	Used for the Core, Data and Tests projects of the solution.

WinUI 3 projects are created from Visual Studio templates installed by the WinUI workload; the official documentation for the .NET SDK templates lists the WPF and Windows Forms ones above. Run dotnet new list on your machine to see exactly what is installed, and treat that output as authoritative.

The following commands create the layered Bookshelf Desktop solution used throughout the section: a WPF app, a core library for view models and abstractions, and an xUnit test project.

dotnet new sln -n BookshelfDesktop
dotnet new wpf -n Bookshelf.Desktop -f net10.0
dotnet new classlib -n Bookshelf.Core -f net10.0
dotnet new xunit -n Bookshelf.Tests -f net10.0

dotnet sln add Bookshelf.Desktop Bookshelf.Core Bookshelf.Tests
dotnet add Bookshelf.Desktop reference Bookshelf.Core
dotnet add Bookshelf.Tests reference Bookshelf.Core
dotnet add Bookshelf.Core package CommunityToolkit.Mvvm --version 8.4.2

dotnet build

Representative output of the first lines and of the final build:

The template "Solution File" was created successfully.
The template "WPF Application" was created successfully.
Processing post-creation actions...
Restoring Bookshelf.Desktop\Bookshelf.Desktop.csproj:
  Restore succeeded.
The template "Class Library" was created successfully.
The template "xUnit Test Project" was created successfully.
Project `Bookshelf.Desktop\Bookshelf.Desktop.csproj` added to the solution.
...
Build succeeded.
    0 Warning(s)
    0 Error(s)

The generated WPF project file is short because the SDK supplies the rest:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

</Project>

The -windows suffix of the target framework moniker is what unlocks the Windows desktop APIs, and UseWPF (or UseWindowsForms) adds the matching framework references. On Linux or macOS the SDK refuses to build such a project by default (error NETSDK1100); setting <EnableWindowsTargeting>true</EnableWindowsTargeting> in the project file lets it build there, which is useful for CI, but the app still only runs on Windows.

Source: Windows Presentation Foundation overview

Source: NETSDK1100: Windows is required to build Windows desktop applications

.NET Framework Projects Versus Current .NET

Developers arriving from .NET Framework see the same designers and many of the same tools, but the project model is different. The table summarises what changes in the environment.

Table 4. What changes when moving a desktop project from .NET Framework to .NET 8, 9 and 10
Area	.NET Framework 4.x	.NET 8 / 9 / 10
Project file	Verbose, lists every file and reference.	SDK-style, short, files included by globbing, `PackageReference` for packages.
Runtime	Installed with Windows or as a redistributable, machine-wide.	Side-by-side, per application or shared; self-contained deployment is possible.
Designer for WinForms	In-process.	Out-of-process designer, with some third-party control incompatibilities.
Unavailable technologies	AppDomains, .NET Remoting, WCF server, `WebBrowser` is legacy.	Not available or changed; WebView2 replaces `WebBrowser` for web content.
WPF additions	None since 4.8.	Fluent theme in .NET 9 and more controls styled in .NET 10, `OpenFolderDialog`, new `MessageBox` options.
Support	4.8 receives security and reliability fixes.	.NET 10 is LTS to 2028-11-14; .NET 8 and 9 end on 2026-11-10.

The official migration guide explains the porting steps and the technologies that are not available on .NET. The Upgrade Assistant tool that earlier guides recommended is deprecated; Microsoft now points to GitHub Copilot app modernization for assisted upgrades.

Source: Upgrade a WPF app to .NET

XAML Hot Reload

XAML Hot Reload applies edits to XAML files to the running application without restarting it, while keeping the application state: the window stays open, the selected book stays selected, and the data stays loaded. It works for WPF and WinUI 3 projects debugged from Visual Studio (and for other XAML stacks listed in the official page). Managed code edits are handled by the separate .NET Hot Reload feature, with limits on what kinds of edits are applied.

A Hot Reload Workflow for Bookshelf Desktop

The following loop is the recommended way to build the main window. It uses the MainWindow below, with a binding to a BooksViewModel that is introduced properly on the MVVM pages of this section.

<Window x:Class="Bookshelf.Desktop.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:vm="clr-namespace:Bookshelf.Desktop.ViewModels"
        mc:Ignorable="d"
        d:DataContext="{d:DesignInstance Type=vm:BooksViewModel}"
        Title="Bookshelf Desktop" Height="480" Width="720">
    <Grid Margin="12">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>

        <TextBox Grid.Row="0" Margin="0,0,0,8"
                 Text="{Binding SearchText, UpdateSourceTrigger=PropertyChanged}"/>

        <ListView Grid.Row="1" ItemsSource="{Binding Books}"
                  SelectedItem="{Binding SelectedBook}">
            <ListView.View>
                <GridView>
                    <GridViewColumn Header="Title" DisplayMemberBinding="{Binding Title}" Width="320"/>
                    <GridViewColumn Header="Author" DisplayMemberBinding="{Binding Author}" Width="220"/>
                </GridView>
            </ListView.View>
        </ListView>
    </Grid>
</Window>

Follow these steps:

Start debugging with F5. Visual Studio builds the app, launches it and attaches the debugger.
Confirm that Hot Reload is enabled. In Tools > Options > Debugging > Hot Reload (the dialog is also reachable from the Hot Reload drop-down on the toolbar) the XAML Hot Reload option must be on, and "Enable Hot Reload on file save" controls whether reload happens when you save instead of when you click the toolbar button.
Edit the XAML while the app runs, for example change the Width of the Title column from 320 to 360, or change Margin="12" to Margin="24".
Save the file or choose Hot Reload in the debug toolbar. The running window updates in place, and the selection and scroll position are kept.
Keep editing. If the change cannot be applied, the editor reports it and the app keeps running with the previous UI; stop and restart debugging only for such cases.

Edits that need a restart in practice are those that change what the compiler produces rather than what the XAML loader reads, for example changing x:Class, adding code-behind members or changing the project’s target framework. The official pages list the supported scenarios per stack; this page does not enumerate them, because the list changes with Visual Studio updates.

Source: Write and debug running XAML code with XAML Hot Reload

Design-Time Data with the d: Namespace

The mc:Ignorable="d" and d:DataContext lines in the example let the XAML designer, and the Live Preview window, render the window with sample data without running the application. The d: attributes are ignored by the runtime XAML loader. They are described on the XAML fundamentals page of this section.

Inspecting the Running UI

While the app runs under the debugger, Visual Studio overlays an in-app toolbar on the application window and opens extra tool windows. Together they answer the question every XAML developer asks: why does this element look or behave like this?

Table 5. XAML runtime inspection tools
Tool	What it shows	Open it from
In-app toolbar	Buttons to select an element on screen, display layout adorners, track the focused element and toggle Hot Reload.	Appears over the running window when UI debugging tools are on.
Live Visual Tree	The tree of the running UI: the elements actually created, including those generated by templates. Selecting a node highlights it in the running window and the reverse.	Debug > Windows > Live Visual Tree
Live Property Explorer	Every dependency property of the selected element with its current value, and where the value comes from (local, style, template, inherited, default).	Debug > Windows > Live Property Explorer
Live Property Explorer editing	Property values can be changed on the running element to try a fix before moving it to the source file.	Same window.
XAML Binding Failures	Failed bindings, with the path, source and the reason, collected while the app runs.	Debug > Windows > XAML Binding Failures
XAML Live Preview	The running app (or the designer view) shown inside the IDE window so you can edit XAML and see the result side by side. Availability depends on the stack and the Visual Studio update.	Debug > Windows menu; see the official page

The Live Visual Tree is especially useful in WPF, where one Button is expanded by its ControlTemplate into a dozen visual elements. The tree separates what you wrote (the logical tree) from what rendered (the visual tree), an idea covered in depth on the WPF architecture page of this section.

Debugging a Binding Problem Step by Step

Suppose the book list is empty although the view model contains data. Use the tools in this order:

Open XAML Binding Failures. A row such as "Cannot find source" or "Property 'Books' not found on object" tells you that either the DataContext or the path is wrong.
In Live Visual Tree, select the ListView and open Live Property Explorer. Look at DataContext: if it is null, the window never received its view model. If it is a different type, the binding path points at the wrong object.
Check ItemsSource in the explorer. If it shows a collection, the problem is in the item template; if it is empty, the problem is in the view model.
Fix the source (for example assign the DataContext in the composition root), save, and let Hot Reload apply it.

Source: Inspect XAML properties while debugging

The Debugger and Diagnostics

The general Visual Studio debugger works unchanged for desktop apps. The features that matter most for UI code are listed below.

Table 6. Debugger features used in desktop UI work
Feature	Use in Bookshelf Desktop
Breakpoints and conditional breakpoints	Stop in a command handler only for a specific book, for example when `Title` equals a given value.
Data tips and the Watch windows	Inspect `SelectedBook` and `Books.Count` at a breakpoint inside `BooksViewModel`.
Exception settings	Break when an exception is thrown (first chance), not only when it is unhandled; helpful for binding and converter exceptions that WPF otherwise swallows.
Output window and trace sources	WPF writes binding errors to the Output window of the Debug category, as `System.Windows.Data Error: 40` lines. The verbosity can be raised with `PresentationTraceSources`.
Parallel Stacks, Tasks and Threads windows	Find the UI thread and diagnose a deadlock between `Dispatcher.Invoke` and `.Result`.
Hot Reload for managed code	Apply many C# edits to a running process; unsupported edits ask for a rebuild.
Diagnostic tools window	Memory and CPU usage while debugging, with events. Deeper profiling is covered on the Performance & Diagnostics page of the section.

A debugging setup for WPF data binding raises the trace level in code during development. This is a standard technique from the WPF data binding documentation; keep it out of release builds.

using System.Diagnostics;

namespace Bookshelf.Desktop;

public partial class App : System.Windows.Application
{
    protected override void OnStartup(System.Windows.StartupEventArgs e)
    {
#if DEBUG
        // Verbose binding diagnostics in the Visual Studio Output window.
        PresentationTraceSources.Refresh();
        PresentationTraceSources.DataBindingSource.Listeners.Add(new ConsoleTraceListener());
        PresentationTraceSources.DataBindingSource.Switch.Level = SourceLevels.Warning | SourceLevels.Error;
#endif
        base.OnStartup(e);
    }
}

Source: Windows Presentation Foundation overview

Debugging Packaged WinUI 3 Apps

A packaged app runs with a package identity and in the MSIX layout, and Visual Studio registers it before launching it (this is where Developer Mode is needed). An unpackaged WinUI 3 app runs as a normal executable. The two modes therefore differ when you debug features that require identity, such as notifications or some storage APIs. For a non-packaged executable, a debug identity can be added from the command line, which is one of the uses of the winapp CLI described above.

Cross-Stack Comparison of the Environment

Table 7. Environment differences among the three stacks
Aspect	WPF	WinUI 3	Windows Forms
Visual Studio workload	.NET desktop development	WinUI application development	.NET desktop development
Project creation from the CLI	`dotnet new wpf`	Visual Studio templates (and the winapp CLI helpers)	`dotnet new winforms`
Extra NuGet packages	None required for the base	Windows App SDK (`Microsoft.WindowsAppSDK`)	None required for the base
Designer	XAML designer and Live Preview	XAML designer (availability varies by update)	Out-of-process WinForms designer
Hot Reload	XAML Hot Reload and managed Hot Reload	XAML Hot Reload and managed Hot Reload	Managed Hot Reload (there is no XAML)
Developer Mode	Not needed	Needed for packaged apps	Not needed
Binding diagnostics	XAML Binding Failures window, `PresentationTraceSources`	XAML Binding Failures window (compiled `x:Bind` reports many errors at build time)	Binding exceptions at run time through `BindingSource`

Pitfalls

Running the wrong Visual Studio. Opening a net10.0-windows solution in Visual Studio 2022 gives a missing-SDK error. Use Visual Studio 2026 or build with the .NET 10 SDK from the command line.
Applying a configuration file blindly. winget configure executes resources with your privileges. Review the YAML, including the official one, before applying it.
Leaving Developer Mode on in a shared or build image. Enable it where development happens and not on machines that run only production software.
Expecting Hot Reload to cover everything. Changes to the compiled shape of the app require a restart. If the running UI does not change, check the Hot Reload output and the Options setting before assuming a bug.
Ignoring the Output window. WPF swallows binding errors and shows blank UI. Binding failures are the first thing to check for an empty control.
Pinning nothing. The winapp CLI is in preview and the winget package may update. Record the version used by CI and by global.json for the SDK so builds are reproducible.
Mixing target frameworks. A test project that targets net10.0 cannot reference a net10.0-windows WPF project directly. Keep view models in a plain net10.0 library, as in the solution above, and test them there.

Historical Tools

Two tools appear in older tutorials and are described here only so that you recognise them.

Windows Template Studio was a Visual Studio extension that generated WinUI and UWP apps from a wizard. Its last release was in 2023 and there is no Microsoft Learn page for it, so this section does not use it.
Dev Home was a Windows dashboard that could run machine setup, including WinGet configuration files. It has been retired. The winget configure command described above works without it.

What the Official Documentation Does Not Provide

There is no single Microsoft Learn page that lists everything a WPF developer should install; the "start here" page is the closest, and it leads with WinUI. Treat the WPF overview and the .NET SDK documentation as complementary.
The aka.ms/winui-config file targets WinUI development. A WPF-only or Windows Forms-only configuration is a user composition of the same resources, as shown above, and is not an official file.
The winapp CLI documentation is a preview reference; there is no compatibility guarantee between 0.x versions.
WinUI 3 project creation from the dotnet CLI is not covered by the .NET SDK template documentation.

Third-party tools such as Avalonia’s templates, Uno Platform’s tooling, the FlaUI automation library and the XAML Styler formatting extension also exist. They are third-party products and are not covered here.

References

Start developing Windows apps — Microsoft Learn
Enable your device for development — Developer Mode, Microsoft Learn
WinGet configuration — Microsoft Learn
winapp CLI — Microsoft Learn
Visual Studio 2026 release notes — Microsoft Learn
XAML Hot Reload — Microsoft Learn
Inspect XAML properties while debugging — Live Visual Tree and Live Property Explorer, Microsoft Learn
Windows Presentation Foundation overview — Microsoft Learn
Upgrade a WPF app to .NET — Microsoft Learn
What is new in WPF for .NET 10 — Microsoft Learn
.NET support policy — Microsoft
Mark J. Price, C# 13 and .NET 9 - Modern Cross-Platform Development Fundamentals, 9th edition, Packt, 2024, chapter 4 ("Writing, Debugging, and Testing Functions"). It contributes the general debugging workflow in Visual Studio, the use of Hot Reload for managed code and xUnit unit testing. The book targets .NET 9 and does not cover XAML, WPF or WinUI tooling, so the desktop-specific material on this page follows the official documentation.