WinApp v0.4 Preview Brings WinUI XAML IntelliSense to VS Code

Where this fits in the WinApp extension's history​

The WinApp extension wraps the Windows App Development CLI. It lets you initialize, run, debug, package and sign Windows apps built with .NET, WPF, WinUI, C++, Electron, Rust, Tauri or Flutter without switching tools. The earlier v0.3.0 release added schema-aware IntelliSense for manifest files. It introduced AppxManifest IntelliSense in VS Code. v0.4 applies the same idea to the XAML that defines your UI. The key difference is that manifest IntelliSense works from a fixed schema. XAML IntelliSense has to understand your project's own types, referenced projects and resources.

What the XAML language service does​

Microsoft says the service understands your app's types, referenced projects and resources. Suggestions are meant to reflect the project you're editing, not just the generic WinUI control set. The announced capabilities are:

• Element completion: WinUI controls and your own custom controls. If a custom control needs a namespace, the extension can add the xmlns declaration for you.
• Property and event completion: properties, events and attached properties for the current element.
• Value completion: enum and Boolean values, markup extensions and resource keys.
• Hover information: type and member details for elements, properties and resource references.
• Diagnostics as you type: malformed XAML and semantic errors checked against your project's resolved types. Microsoft's examples are an unresolved type and an invalid x:Bind path. These can appear in the editor before your next build.
• Quick fixes: press Ctrl+. to see the available fixes.
• Navigation: F12 or Ctrl+Click jumps from an event handler or x:Bind member to its C# declaration. It can also jump to an x:Name or a resource-key declaration. Find All References and Rename work for XAML names and resource keys.

One limit matters for day-to-day work. For framework and NuGet types that exist only as compiled metadata, hover works but Go to Definition does not open source. If you expect to F12 into WinUI internals, you won't get that here.

Prerequisites and limits​

This is where the announcement matters most. Read it before you assume your project is covered.

The service is on by default once the extension is installed. You open a .xaml file in a WinUI project to use it.

Staged loading​

Features arrive in stages. Basic editing comes first. SDK and package types follow, then your own types and semantic diagnostics. The status bar shows progress and flags missing prerequisites or project-loading problems. If you see only partial suggestions right after opening a project, this loading order is the likely reason. Check the status bar before assuming something is broken.

If the language server can't start, syntax highlighting stays available. A notification explains the cause.

Turning it down or off​

• winapp.xaml.intelliSense.enable turns the language service off.
• winapp.xaml.diagnostics.level lets you keep completions while filtering diagnostic underlines. Microsoft doesn't list the accepted values in the announcement.

The manifest IntelliSense settings in the Marketplace listing are a separate pair, winapp.manifest.intelliSense.enable and winapp.manifest.diagnostics.level. They follow the same pattern. The manifest enable setting controls completions, hover, diagnostics and Go to Definition together. Don't mix the two sets up.

Creating a WinUI app from the Command Palette​

Until now, WinApp: Initialize Project assumed a project already existed. In v0.4 you can start one from the editor:

• Open the Command Palette and run WinApp: Create WinUI App.
• Choose an official Windows App SDK template.
• Enter an app name.
• Choose the parent folder.

The extension creates the project and reports where it saved it. You don't need a folder or workspace open first.

Templates come from the .NET CLI, not a list built into the extension. The template pack is installed on first use. If you already have one, you can keep it or install the latest. This command requires the .NET SDK 8.0.100 or later.

Run and debug from a project file​

Before v0.4, WinApp: Run Application asked you to find a folder containing a built executable. Now it can discover runnable .NET projects and solutions. The extension then restores, builds and launches the app with package identity. It looks for projects and solutions first and falls back to build-output folders. If there are several targets, you pick one from a Quick Pick. Browse… remains available for anything not listed.

The same support works with F5. A new input property in launch.json accepts a project, solution or build-output folder. Microsoft's example points it at a project file:

{
  "type": "winapp",
  "request": "launch",
  "name": "WinApp: Launch and Attach",
  "input": "${workspaceFolder}\\MyApp.csproj"
}

Pointing at the project means a restore and build happen before each launch. WinApp: Run Application With Options… prompts for build configuration, target architecture and run options. Those options include skipping the build and unregistering the development package on exit. Persistent settings belong in launch.json, which now also supports target frameworks, runtime identifiers and MSBuild properties.

A common failure point​

If you point input at an already-built output folder, nothing gets built. That includes output folders for non-.NET apps. If you debug that way and your changes don't appear, you are probably running stale binaries. Rebuild first, or add a preLaunchTask.

Debugging also needs the debugger extension that matches your app's language: C#, C/C++ or built-in Node.js.

Smaller v0.4 changes​

AppxManifest visual editor

• Resource-qualified assets are no longer wrongly reported as missing.
• XML edits keep your selected tab, expanded fields and scroll position, even through temporary parse errors.
• Microsoft Learn links follow your language preference.

Signing and certificates

• Package lists show packages first, with up to 10 recent results plus Browse…
• The certificate publisher comes from the manifest when available. Otherwise you are prompted for one.
• You can reuse or overwrite an existing development certificate.

Installing it​

You need Windows 10 or later and VS Code 1.109.0 or later. XAML IntelliSense needs Windows x64 or ARM64. Install it in either of two ways:

• Press Ctrl+Shift+X, search for WinApp, and click Install.
• Run code --install-extension Microsoft-WinAppCLI.winapp from a command line.

The WinApp CLI is bundled with the extension, so you don't install it separately. This differs from an older Microsoft Learn page. That page says the extension requires the WinApp CLI to be installed first. The v0.4 announcement and the Marketplace listing both say the CLI is bundled. If a setup guide conflicts with that, treat the newer announcement as current.

What it means for Windows developers​

The practical question is whether this is enough to leave Visual Studio for WinUI work. Today the answer is "maybe, for C# projects." Microsoft's own caveats set the boundaries:

• It is experimental.
• C++ WinUI has no full IntelliSense yet.
• Go to Definition stops at compiled metadata.
• The .NET 10 SDK is required.

Competing community options exist too. One third-party extension, WinDev Helper, says it is published to both the Visual Studio Marketplace and the Open VSX Registry, so it works in compatible editors. Its repository listed XAML IntelliSense and Hot Reload as planned for future releases. Microsoft's first-party language service is therefore a notable step for the VS Code ecosystem. I haven't tested either extension, so I can't compare quality.

Moving diagnostics into the editor is the biggest practical gain. Catching a bad x:Bind path while typing is a real time-saver compared with finding it after a build. As a preview, expect rough edges. Microsoft is asking for bug reports and feature requests on its GitHub repo.

Correction (November 3, 2026): An earlier version of this article said the WinApp: Create WinUI App command requires the .NET 10 SDK. Microsoft's WinApp listing states that command requires the .NET SDK 8.0.100 or later; .NET 10 is required for project-aware XAML IntelliSense in C# projects, not for creating an app.