📢Announcing: WinUI 3 in Windows App SDK 1.0 Preview 3 📦

[gabbybilka]

We've just shipped the latest version of WinUI 3, which is a part of Windows App SDK 1.0 preview release! This release includes new features, bug fixes and provides access to APIs and features we are intending to include in the next stable release.

Shipping WinUI 3 as a part of the Windows App SDK

In order to use this version of WinUI 3, you'll download the Windows App SDK (Preview) Visual Studio Extension (VSIX) to get started. The Windows App SDK VSIX includes WinUI project templates that you'll use to build your WinUI 3 app, as well as access to other Windows App SDK components. The Windows App SDK package includes a reference to the WinUI 3 NuGet package.

For more on the Windows App SDK, see their documentation and repository. For installation instructions, see Set up your development environment.

NOTE: The Windows App SDK was previously known by the code name Project Reunion. Some SDK assets may still use the code name, but these assets will be renamed in a future release. The term Project Reunion may also be used when referring to an existing asset or a specified earlier release.

What's new

This release of WinUI 3 is focused on supporting unpackaged apps. Please view Instructions for WinUI 3 unpackaged desktop apps to configure your WinUI 3 application to support unpackaged deployment.

Stability

This release includes unstable APIs and does not support building production apps. If you'd like to use WinUI 3 to build a production app, feel free to continue using the latest Windows App SDK 0.8 release.

Known Issues

For a list of all the known issues for this Windows App SDK 1.0 preview release, please see the Windows App SDK release notes.

• Unpackaged WinUI 3 applications are only supported on Windows versions 1909 and later.
• Unpackaged WinUI 3 applications are supported on x86 and x64, arm64 support will be added in the next stable release.
• Single-project MSIX Packaging Tools for VS 2019 or VS 2022 is required for unpackaged apps.
• In an unpackaged app, you may receive a prompt to install .NET 3.5; if you do, you can ignore it.
• Some APIs are not currently supported in unpackaged apps. We are aiming to fix this in the next stable release. A few examples:
  • ApplicationData
  • StorageFile.GetFileFromApplicationUriAsync
  • ApiInformation (not supported on Windows 10)
  • Package.Current
• ListView, CalendarView, and GridView controls are using the incorrect styles and we are aiming to fix this in the next stable release.

Getting started

First, you'll need to set up your dev environment with the appropriate technologies. See our documentation for installation instructions and more information on project types:

Install the Windows App SDK

Create WinUI 3 Projects

While you're developing, check out the API Reference documentation.

Take a look at our walk-through docs:

• Get started developing apps with WinUI 3

• Build a basic WinUI 3 app for desktop

You can also update your existing WinUI 3 app to use the new Windows App SDK 1.0 preview release using these instructions: Update existing projects to the latest release of the Windows App SDK.

We love feedback! We encourage you to file any bug, big or small, on our repo using this template. Knowing which issues and features are important and/or critical to our customers highly influences which ones we tackle. Even though we ship with the Windows App SDK, please continue to file WinUI-specific bugs on this repo.

Using WinUI 3 and the Windows App SDK with our ecosystem partners

This latest release is in the process of being integrated into several other important ecosystem technologies. To test out and follow that progress, check out some of our partner technologies below (note that some of these technologies may not yet be available for Windows App SDK 1.0 preview):

• Actipro Software is migrating their vast UI control offerings over to WinUI 3, including their SyntaxEditor code editor, propertygrid, native type edit boxes, docking/MDI, charts, and more.

• DevExpress: DevExpress has released 20 new WinUI controls with Windows App SDK 0.8 support, including the Data Grid, Scheduler, Charts, Ribbon Toolbar, and more. All 20 UI components are available free-of-charge.

• Esri: ArcGIS Runtime SDK for .NET adds mapping, spatial analytics, and location intelligence capabilities to your apps on Android, iOS, and Windows. Support for WinUI 3 is now available.

• GrapeCity: The ComponentOne WinUI controls support modern desktop apps (Win32) and include calendar, accordion, input and our fast and flexible datagrid, FlexGrid.

• Infragistics: Ultimate UI for WinUI brings business critical, high performing, and feature rich line of business controls to your apps that target any platform that runs Windows (including Windows on ARM64).

• Syncfusion: Updated their projects to Microsoft.ProjectReunion from Microsoft.WinUI following upgrade instructions. All their controls are working fine.

• Telerik UI for WinUI: the market first UI controls suite for crafting Win32 and UWP apps with WinUI 3, comes with feature-rich controls like Ribbon, DataGrid, Charts, Gauges, Barcode, and more.

• Uno Platform: Use WinUI 3 – Windows App SDK 0.8, XAML and C# to build pixel-perfect, single-codebase, native applications that can run on Web, Desktop and Mobile. It is free, open-source and available today.

• Windows Community Toolkit (Microsoft): The WCT is currently working on supporting Windows App SDK 0.8 RC. It provides tons of new controls and capabilities for use in your WinUI app. You can check out their open source repo here.

What's next

To keep up with progress being made on WinUI 3, please see our feature roadmap which gets updated regularly. We also give monthly updates on our WinUI Community Calls, where you can directly ask the team any questions you have.

[sylveon]

Is single-file output supported for unpackaged projects? e.g. can I get a single portable exe that I can share with users, or does it need to have various DLL and accompanying files

[wjk]

@sylveon Not only does it need accompanying files, those files are only officially supplied as MSIX packages, which are very poorly documented, hard to handle, can only be installed system-wide (and are very difficult to remove on uninstall), and may or may not require Windows Store access at your app’s runtime.

I don’t know why they insist on using these MSIX packages for “unpackaged”, “app-local” deployments when you can use registration-free WinRT activation instead. This technique would work just as well, but is also poorly documented (the only reference I could find for it anywhere was that blog post) and is not compatible with the SDK packages as published (since you have to copy the implementation DLLs to your OutDir for it to work, and those DLLs are shipped only inside the MSIX packages). While I supposer you could make it work by manually extracting the contents of the MSIX packages (they’re just zip files) and copying the DLLs into your OutDir from there, Microsoft will no doubt be quick to swoop in and state that this isn’t a “supported” technique. (It also de facto requires that you commit the binaries into your Git repo, since there is no good way to extract them at build time, and that is an antipattern I try to avoid.)

Sorry for the bad news!

[shelllet]

Are there any example of how to Activate a Window in unpackaged app?

Is it so?

MddBootstrapInitialize(...)

auto window = make<MainWindow>();
window Activate();

// where is message loop ?

MddBootstrapShutdown();

[seven-mile]

@sylveon Not only does it need accompanying files, those files are only officially supplied as MSIX packages, which are very poorly documented, hard to handle, can only be installed system-wide (and are very difficult to remove on uninstall), and may or may not require Windows Store access at your app’s runtime.

I don’t know why they insist on using these MSIX packages for “unpackaged”, “app-local” deployments when you can use registration-free WinRT activation instead. This technique would work just as well, but is also poorly documented (the only reference I could find for it anywhere was that blog post) and is not compatible with the SDK packages as published (since you have to copy the implementation DLLs to your OutDir for it to work, and those DLLs are shipped only inside the MSIX packages). While I supposer you could make it work by manually extracting the contents of the MSIX packages (they’re just zip files) and copying the DLLs into your OutDir from there, Microsoft will no doubt be quick to swoop in and state that this isn’t a “supported” technique. (It also de facto requires that you commit the binaries into your Git repo, since there is no good way to extract them at build time, and that is an antipattern I try to avoid.)

Sorry for the bad news!

You mean the WindowsAppSDK redist? I think it make sense. Some documents mentioned that we will be able to deploy self-contained apps, which fit the situation you described.

I still prefer installing a common library for saving disk space. Something like Electron apps who brings the whole huge CEF runtime with it is already notorious, isn't it?

I think the redist is similar to WebView2 runtime providing both deployment modes. And hopefully stable channel will be integrated in the Windows system (?). Most apps requires vcredist, dotnet redist... It just doesn't matter. With the redist installed, the xcopy deployment seems to just work: I can copy the executable file, the BootstrapDLL(100+KB) and binary XAML files(guessed by the name MainWindow.xbf, they are very small and can be linked into the executable file resources region easily in the future).

[wjk]

@sylveon I didn’t know what kind of self-contained deployment you were talking about, so I assumed the most restrictive case (pure xcopy-and-run). And yeah, Electron apps installing CEF over and over again is indeed quite wasteful.

Since use of redist packages is OK, I would therefore recommend using the WindowsAppRuntimeInstall.exe program. You can download it here (see step 8). All the MSIX packages you’ll need are embedded within, and it has no outside runtime dependencies (no vcruntime, nothing). You would run it in your installer program and it will extract and install the packages synchronously before exiting. If you prefer, that zip file also includes the MSIX packages as “loose” artifacts, if you want to install them using the Windows PackageManager directly.

[sylveon]

I mean single file. People download an exe (and only a singular exe, no self extracting or installing anything), and double clicking said exe file immediately launches the app. No dependencies to install required. Like Rufus, where there is nothing but their exe file you need to download, and it runs everywhere.

[wjk]

@sylveon In that case, there’s no way to do it. The best you can hope for is a self-extracting wrapper program that automatically deletes its contents before exiting, but you already said that wasn’t an option. Sorry about that!

[seven-mile]

@sylveon In that case, there’s no way to do it. The best you can hope for is a self-extracting wrapper program that automatically deletes its contents before exiting, but you already said that wasn’t an option. Sorry about that!

Why can't the BootstrapDLL be linked statically and all resource files be collected into the PE executable? I think it's not quite complicated. Or you means it's impossible just for now? Any future plans?

[wjk]

Why can't the BootstrapDLL be linked statically and all resource files be collected into the PE executable?

My apologies for misunderstanding; I thought you had ruled out that approach as well. What you are describing would very much work. If you statically link the BootstrapDLL into the EXE, and extract and install the MSIX packages yourself before initializing Bootstrap or referencing any functionality that depends on it, then everything should work.

[jschwizer99]

@gabbybilka Many thanks for the WinUI 1.0.0 Preview3 fixing the path issue microsoft/WindowsAppSDK#1599 (https://github.com/microsoft/WindowsAppSDK/milestone/8?closed=1). This allows us to validate the new design changes with our application users.

I couldn't find any list of additional fixes in the release notes https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/preview-channel. I've tried to find possible fixes in the WinUI issue list by labels. But the labels version-winui3preview3 and version-winui3preview4 seem not to match and rather refer to earlier versions.

Can you point me to the place where I can find an overview on newly fixed issues since preview2? Many thanks.

[IndianaGary]

I've been playing with a Maui-based WinUI 3 desktop app and recently updated my Microsoft.WindowsAppSDK nuget package to 1.0.0-preview3. Upon testing the app it crashes with "Cannot find Microsoft.WindowsAppSDK.Bootstrap.dll". After reverting to 1.0.0-experimental1, the problem disappears. Am I missing something? If this looks like a bug, where should I report it?

[seven-mile]

@IndianaGary I don't know well about MAUI-based WinUI3. But in preview release compared with experimental1 they renamed Microsoft.WindowsAppSDK.Bootstrap.dll to Microsoft.WindowsAppRuntime.Bootstrap.dll. Maybe some of your MAUI supportting libraries have not been updated to preview channel yet.

[IndianaGary]

@seven-mile Basically, Maui maps Maui controls to WinUI 3 controls to support Windows. It's a cross-platform UI abstraction layer based upon Xamarin XAML syntax. I'll bet that your surmise is likely correct and I'll simply need to wait for Maui Preview 10 due out in the next few weeks.

[kmgallahan]

@gabbybilka Now that WASDK 1.0 has been released this issue and all of these older announcements can probably be closed to help with the issue count:

#6049
#5906
#5789
#5651
#5262
#5260
#5195
#5102
#4682
#4480
#4156
#3620
#2917

Could add a final comment on each to direct any further comments to the WASDK release issue.

Similarly, there are several old WinUI Community Call issues still open:

#6050
#5281
#4816
#4150
#3791

[gabbybilka]

Thanks @kmgallahan for aggregating this list of stale issues and giving me the nudge I needed 😊 'Tis the season for some issue cleanup.

For this thread, please check out the WASDK 1.0 release for the latest updates on WinUI 3 in Windows App SDK: #6325

[kmgallahan]

@gabbybilka 4 leftovers from above list:

Thanks for the cleanup.