Windows App SDK 1.0.0-Preview2 with Windows styles from WinUI 2.6.

Reading time icon 5 min. read


Readers help support MSPoweruser. When you make a purchase using links on our site, we may earn an affiliate commission. Tooltip Icon

Read the affiliate disclosure page to find out how can you help MSPoweruser effortlessly and without spending any money. Read more

winui 3

Microsoft has just released Windows App SDK 1.0.0-Preview2, a toolkit that empowers desktop app developers to build apps with a modern Windows UI, APIs, and platform features.

[lwptoc title=”WindowsAppSDK 1.0 preview 2″ width=”30%” float=”right”]

Version 1.0.0-Preview2 of the SDK brings the following features and improvements:

WinUI 3

New updates:

  • Controls have been updated to reflect the latest Windows styles from WinUI 2.6.
  • Single-project MSIX is supported.
  • WinUI package can now target build 17763 and above. See issue #921 for more information.
  • In-app toolbar is supported. However, the in-app toolbar and existing Hot Reload/Live Visual Tree support require the upcoming Visual Studio 17.0 Preview 5 release, available later in October.

Bug fixed: WebView2Runtime text is now localized.

Windowing

This release introduces updates to the AppWindow class. There are no major new features added in this release, but there are changes to method names, properties, and some return values have been removed. See the documentation and samples for detailed updates. If you worked with AppWindow in the 1.0 Experimental or 1.0 Preview 1 releases, expect some changes to your code.

New updates:

  • The AppWindowConfiguration class has been removed. The properties of this class is now available on the AppWindow itself, or on the Presenter classes.
  • Most bool return values for the WinRT API methods in this space has been removed and are now void since these methods would always succeed.
  • The C# ImportDll calls are no longer needed for GetWindowIdFromWindow and GetWindowFromWindowId. Use the .NET wrapper methods available in Microsoft.UI.Win32Interop instead.

Important limitations:

  • The Windows App SDK does not currently provide methods for attaching UI framework content to an AppWindow; you are limited to using the HWND interop access methods.
  • Window title bar customization works only on Windows 11. Use the IsCustomizationSupported method to check for title bar customization feature support. We intend to bring this functionality down-level.

For more information, see Manage app windows.

Important limitations:

  • This release of AppWindow is currently available only to Win32 apps (both packaged and unpackaged).
  • The Windows App SDK does not currently provide methods for attaching UI framework content to an AppWindow; you are limited to using the HWND interop access methods.
  • Window title bar customization works only on Windows 11. Use the IsCustomizationSupported method to check for title bar customization feature support. We intend to bring this functionality down-level.

For more information, see Manage app windows.

Input

New updates:

  • Improved support for precision touchpad input.

Important limitations:

  • All PointerPoint static factory functions have been removed: GetCurrentPointGetCurrentPointTransformedGetIntermediatePoints, and GetIntermediatePointsTransformed.
  • The Windows App SDK does not support retrieving PointerPoint objects with pointer IDs. Instead, you can use the PointerPoint member function GetTransformedPoint to retrieve a transformed version of an existing PointerPoint object. For intermediate points, you can use the PointerEventArgs member functions GetIntermediatePoints and GetTransformedIntermediatePoints. See the documentation for additional details.

MRT Core

New updates:

  • App developers can now opt out an image file or a RESW file from being indexed in the PRI file in .NET projects. See issue 980 for more information.

Important limitations:

  • In .NET projects, resource files copy-pasted into the project folder aren’t indexed on F5 if the app was already built. As a workaround, rebuild the app. See issue 1503 for more information].
  • In .NET projects, existing resource files added from an external folder aren’t indexed without manual setting of the Build Action. To work around this issue, set the Build Action in Visual Studio: Content for image files and PRIResource for RESW files. See issue 1504 for more information.

Deployment for unpackaged apps

New features:

  • Windows App SDK 1.0 Preview 2 introduces a .NET wrapper for the bootstrapper API. The bootstrapper API is a set of native C/C++ functions that unpackaged apps must use to dynamically take a dependency on the Windows App SDK framework package at run time. The .NET wrapper provides an easier way to call the bootstrapper API from .NET apps, including Windows Forms and WPF apps. The .NET wrapper for the bootstrapper API is available in the Microsoft.WindowsAppRuntime.Bootstrap.Net.dll assembly, which is local to your app project. For more information about the .NET wrapper, see .NET wrapper library.
  • Packaged apps can now use the deployment API to get the main and singleton MSIX packages installed on the machine. The main and singleton packages are part of the framework package that is installed with the app, but due to a limitation with the Windows application model, packaged apps will need to take this additional step in order to get those packages installed. For more information about how the deployment API works, see the deployment guide for packaged apps.

App Lifecycle

Most of the App Lifecycle features already exist in the UWP platform, and have been brought into the Windows App SDK for use by all app types, especially unpackaged Console apps, Win32 apps, Windows Forms apps, and WPF apps. The Windows App SDK implementation of these features cannot be used in UWP apps, since there are equivalent features in the UWP platform itself.

Non-UWP apps can also be packaged into MSIX packages. While these apps can use some of the Windows App SDK App Lifecycle features, they must use the manifest approach where this is available. For example, they cannot use the Windows App SDK RegisterForXXXActivation APIs and must instead register for rich activation via the manifest.

All the constraints for packaged apps also apply to WinUI apps, which are packaged, and there are additional considerations as described below.

Read more and find the download links at Microsoft here.

More about the topics: Windows App SDK 1.0.0, winui 3