Partager via

Notes de publication du canal d'aperçu pour le SDK d'application Windows 1.0

  • Article

Important

Le canal d'aperçu n'est pas pris en charge pour une utilisation dans des environnements de production, et les apps qui utilisent les versions d'aperçu ne peuvent pas être publiées sur le Microsoft Store.

La chaîne de prévisualisation comprend des versions du SDK d'application Windows avec des fonctionnalités de la chaîne de prévisualisation à des stades avancés de développement. Les versions d'évaluation n'incluent pas de fonctionnalités et d'API expérimentales, mais peuvent encore faire l'objet de modifications avant la prochaine version stable.

Liens importants :

Dernière version de la chaîne de prévisualisation :

Dernière version de la chaîne stable :

Version 1.0 Aperçu 3 (1.0.0-preview3)

Preview 3 est la dernière version du canal de préversion pour la version 1.0 du Kit de développement logiciel (SDK) d’application Windows. Preview 3 prend en charge toutes les fonctionnalités de canal d’aperçu.

Télécharger les extensions Visual Studio 1.0 Preview 3 (VSIX)

Remarque

Si vous avez déjà installé des extensions Visual Studio (VSIX) du SDK d’application Windows, désinstallez-les avant d’installer une nouvelle version. Pour obtenir des instructions, consultez Gérer les extensions pour Visual Studio.

Dans le tableau ci-dessous, vous pouvez télécharger les extensions Visual Studio (VSIX) pour la version 1.0 Preview 3. Pour toutes les versions, consultez les derniers téléchargements du SDK d'application Windows. Si vous ne l’avez pas déjà fait, commencez par configurer votre environnement de développement, en suivant les étapes décrites dans Installer les outils pour le Kit de développement logiciel (SDK) d’application Windows.

Les extensions ci-dessous sont adaptées à votre langage de programmation et à votre version de Visual Studio.

Téléchargements 1.0 Aperçu 3 Description
Extension Visual Studio 2019 C# Générez des applications C# avec l’extension Visual Studio 2019 du SDK d’application Windows.
Extension Visual Studio 2019 C++ Générez des applications C++ avec l’extension Visual Studio 2019 du SDK d’application Windows.
Extension Visual Studio 2022 C# Générez des applications C# avec l’extension Visual Studio 2022 du SDK d’application Windows.
Extension Visual Studio 2022 C++ Générez des applications C++ avec l’extension Visual Studio 2022 du SDK d’application Windows.
Le .exe programme d’installation et les packages MSIX Déployez le Kit de développement logiciel (SDK) d’application Windows avec votre application à l’aide du .exe programme d’installation et des packages MSIX.

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour la version 1.0.

WinUI 3 (1.0.0-preview3)

Nous prenons désormais en charge le déploiement d’applications WinUI 3 sans empaquetage MSIX. Consultez Créer votre premier projet WinUI 3 (SDK d'application Windows) pour configurer votre application WinUI 3 pour prendre en charge le déploiement non empaqueté.

Limitations importantes :

  • Les applications WinUI 3 non empaquetées sont prises en charge uniquement sur les versions 1909 et ultérieures de Windows.
  • Les applications WinUI 3 non empaquetées sont prises en charge sur x86 et x64 ; la prise en charge d’arm64 sera ajoutée dans la prochaine version stable.
  • Projet unique MSIX Packaging Tools pour Visual Studio 2019 ou Visual Studio 2022 est requis pour les applications non empaquetées.
  • Dans une application non empaquetée, vous pouvez recevoir une invite pour installer .NET 3.5 ; si vous le faites, vous pouvez l’ignorer.
  • Certaines API ne sont actuellement pas prises en charge dans les applications non empaquetées. Nous voulons résoudre ce problème dans la prochaine version stable. Voici quelques exemples :
  • Les contrôles ListView, CalendarView et GridView utilisent les styles incorrects, et nous souhaitons résoudre ce problème dans la prochaine version stable.

Pour plus d’informations ou pour commencer à développer avec WinUI, consultez :

Autres limitations et problèmes connus :

  • Les applications non empaquetées ne sont pas prises en charge sur Windows 10 version 1809. Nous souhaitons résoudre ce problème dans la prochaine version du canal stable.

  • L’application MSIX à projet unique C# ne compile pas si les outils UWP C++ ne sont pas installés. Si vous avez un projet MSIX à projet unique C#, vous devez installer le composant facultatif Outils de plateforme Windows universelle C++ (v14x).

  • Cette version présente les modèles de projet Application vide, Empaqueté (WinUI 3 in Desktop) pour C# et C++. Ces modèles vous permettent de générer votre application dans un package MSIX sans utiliser de projet de package distinct (voir Empaqueter votre application à l’aide de MSIX à projet unique). Ces modèles présentent des problèmes connus dans cette version :

    • Élément de menu Publier manquant jusqu’à ce que vous redémarrez Visual Studio. Lors de la création d'une nouvelle app dans Visual Studio 2019 et Visual Studio 2022 à l'aide du modèle de projet App vierge, package (WinUI 3 dans Desktop), la commande de publication du projet n'apparaît pas dans le menu tant que vous ne fermez pas et ne rouvrez pas Visual Studio.

    • Erreur lors de l’ajout de références de projet de bibliothèque statique/dynamique C++ à des applications C++ à l’aide d’un package MSIX à projet unique. Visual Studio affiche une erreur indiquant que le projet ne peut pas être ajouté comme référence, car les types de projet ne sont pas compatibles.

    • Erreur lors du référencement d’un contrôle utilisateur personnalisé dans un projet de bibliothèque de classes. L’application se bloque avec l’erreur indiquant que le système ne trouve pas le chemin spécifié.

    • Modèle C# ou C++ pour Visual Studio 2019. Lorsque vous essayez de générer le projet, vous rencontrerez l’erreur « Le projet ne sait pas comment exécuter le nom du projet de profil ». Pour résoudre ce problème, installez l'extension Single-project MSIX Packaging Tools.

    • Modèle C# pour Visual Studio 2019 et Visual Studio 2022. Dans Visual Studio lorsque vous démarrez le débogage ou démarrez sans débogage, si votre application ne déploie pas et ne s’exécute pas (et qu’il n’y a aucun commentaire de Visual Studio), cliquez sur le nœud de projet dans Explorateur de solutions pour le sélectionner, puis réessayez.

    • Modèle C# pour Visual Studio 2019 et Visual Studio 2022. Vous rencontrerez l’erreur suivante quand vous tenterez d’exécuter ou de déboguer votre projet sur l’ordinateur de développement : « Le projet doit être déployé pour que nous puissions effectuer un débogage. Activez Deploy dans Configuration Manager. » Pour résoudre ce problème, activez le déploiement de votre projet dans Configuration Manager. Pour obtenir des instructions, consultez Créer votre premier projet WinUI 3 (SDK d'application Windows).

    • Modèle C++ pour Visual Studio 2022 version 17.0 jusqu’à Preview 4. Vous rencontrerez l’erreur suivante la première fois que vous essayez d’exécuter votre projet : « Il y a eu des erreurs de déploiement ». Pour résoudre ce problème, exécuter ou déployer votre projet une deuxième fois. Ce problème sera résolu dans Visual Studio 2022 version 17.0 préversion 7.

  • Aucune prise en charge de configuration de build de processeur : lorsque vous ajoutez le SDK d’application Windows à une application ou un composant .NET existant qui prend en charge n’importe quel processeur, vous devez spécifier l’architecture souhaitée : x86, x64 ou arm64.

  • Les projets C# utilisant la version 1.0 Aperçu 3 doivent utiliser le Kit de développement logiciel (SDK) .NET 6 suivant ou version ultérieure (voir Télécharger .NET et .NET 5 atteindre la fin du support le 10 mai 2022).

  • Une alternative à DispatcherQueue.TryEnqueue (pour reprendre l’exécution sur le thread de file d’attente du répartiteur) consiste à utiliser la fonction d’assistance resume_foreground dans la bibliothèque d’implémentation Windows (WIL) :

    1. Ajoutez une référence à votre projet au package NuGet Microsoft.Windows.ImplementationLibrary .
    2. Ajoutez #include <wil/cppwinrt_helpers.h> à votre pch.h.
    3. Ajoutez #include <winrt/Microsoft.UI.Dispatching.h> à votre pch.h.
    4. Maintenant co_await wil::resume_foreground(your_dispatcherqueue);.

Problème important impactant 1.0 Aperçu 1 et Aperçu 2

La version 1.0 Aperçu 1 et Aperçu 2 du SDK d'application Windows inclut un mécanisme permettant de nettoyer les modifications apportées à une variable d’environnement par une application empaquetée lorsque cette application est désinstallée. Cette fonctionnalité est dans un état expérimental, et la première version inclut un bogue connu qui peut endommager la variable d’environnement PATH système.

Aperçu 1 et Aperçu 2 endommage toute variable d’environnement PATH qui contient le caractère d’extension %. Cela se produit chaque fois qu’une application empaquetée est désinstallée, que cette application utilise le Kit de développement logiciel (SDK) de l’application Windows.

Consultez également le problème de corruption des variables d’environnement PATH.

Détails

L’entrée PATH système est stockée dans la valeur Path dans la clé suivante dans le Registre Windows :

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Si vous lancez l’Éditeur du Registre (regedit.exe), vous pouvez copier et coller le chemin ci-dessus dans la barre de navigation (immédiatement en dessous de la barre de menus), puis appuyer sur Entrée pour localiser la touche.

La valeur Path de cette clé doit être de type REG_EXPAND_SZ, mais le bogue le modifie en REG_SZ. Et cela rend la variable d’environnement PATH système inutilisable si elle contient le caractère d’extension de variable %.

Versions concernées :

Limitation des risques

Pour ramener votre machine dans un bon état, procédez comme suit :

  1. Vérifiez si le chemin d’accès dans le Registre est endommagé et, le cas échéant, réinitialisez-le en exécutant le script ci-dessous.

    Vous pouvez effectuer l’étape 1 avec le script Windows PowerShell suivant (PowerShell Core ne fonctionnera pas). Exécutez-le avec élévation de privilèges.

    # This script must be run from an elevated Windows PowerShell
# window (right-click Windows PowerShell in the Start menu,
# and select Run as Administrator).

# If the PATH in the Registry has been set to REG_SZ, then delete
# it, and recreate it as REG_EXPAND_SZ.

$EnvPath = 'Registry::HKLM\System\CurrentControlSet\Control\Session Manager\Environment'
$Environment=Get-Item $EnvPath
$PathKind = $Environment.GetValueKind('Path')

if ($PathKind -ne 'ExpandString') {
  $Path = $Environment.GetValue('Path')
  Remove-ItemProperty $EnvPath -Name Path
  New-ItemProperty $EnvPath -Name Path -PropertyType ExpandString -Value $Path
}

  2. Désinstallez toutes les applications qui utilisent le Kit de développement logiciel (SDK) d’application Windows 1.0 Preview1 ou Preview2 (voir le script ci-dessous).

  3. Désinstallez les packages SDK d'application Windows 1.0 Preview1/Preview2, y compris le package qui contient le bogue (voir le script ci-dessous).

    Vous pouvez effectuer les étapes 2 et 3 avec le script Windows PowerShell suivant (PowerShell Core ne fonctionnera pas). Exécutez-le avec élévation de privilèges.

    # This script must be run from an elevated Windows PowerShell
# window (right-click Windows PowerShell in the Start menu,
# and select Run as Administrator).

# Remove the Windows App SDK 1.0 Preview1/2, and all apps that use it.

$winappsdk = "Microsoft.WindowsAppRuntime.1.0-preview*"
Get-AppxPackage | Where-Object { $_.Dependencies -like $winappsdk } | Remove-AppxPackage
Get-AppxPackage $winappsdk | Remove-AppxPackage

Correctif dans le Kit de développement logiciel (SDK) d’application Windows 1.0 Preview 3

La fonctionnalité à l’origine de la corruption de la variable d’environnement PATH sera supprimée dans la prochaine version du Kit de développement logiciel (SDK) d’application Windows 1.0 Preview 3. Elle peut être réintroduite à une date ultérieure, lorsque tous les bogues ont été corrigés et testés minutieusement.

Nous vous recommandons d’utiliser la version 1.0 Preview 3.

Version 1.0 Aperçu 2 (1.0.0-preview2)

Important

La version 1.0 Aperçu 1 et Aperçu 2 contiennent un bogue critique. Si vous avez déjà installé l’un de ces aperçus, consultez comment résoudre le problème. Nous vous recommandons d’utiliser la version 1.0 Aperçu 3 à la place.

Il s’agit de la dernière version de l’aperçu du canal pour la version 1.0. Il prend en charge tous les aperçus fonctionnalités du canal.

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour cette version.

WinUI 3 (1.0.0-preview2)

Nouvelles mises à jour :

  • Les contrôles ont été mis à jour pour refléter les derniers styles Windows de WinUI 2.6.
  • MSIX à projet unique est pris en charge.
  • Le package WinUI 3 peut désormais cibler la build 17763 et les versions ultérieures. Pour plus d’informations, consultez le problème 921.
  • La barre d’outils dans l’application est prise en charge. Toutefois, la barre d’outils dans l’application et la prise en charge existante d’Rechargement à chaud/Live Visual Tree nécessitent la prochaine version de Visual Studio 17.0 Preview 5, disponible plus tard en octobre.

Résolution du bogue : le texte WebView2Runtime est désormais localisé.

Pour plus d’informations ou pour commencer à développer avec WinUI 3, consultez :

Windowing (1.0.0-preview2)

Cette version introduit les mises à jour de la classe AppWindow. Il n’existe aucune nouvelle fonctionnalité majeure ajoutée dans cette version, mais il existe des modifications apportées aux noms de méthode, aux propriétés et à certaines valeurs de retour ont été supprimées. Consultez la documentation et les exemples pour obtenir des mises à jour détaillées. Si vous avez travaillé avec AppWindow dans les versions 1.0 Experimental ou 1.0 Preview 1, attendez-vous à certaines modifications apportées à votre code.

Nouvelles mises à jour :

  • La classe AppWindowConfiguration a été supprimée. Les propriétés de cette classe sont désormais disponibles sur AppWindow lui-même ou sur les classes Présentateur.
  • La plupart des bool valeurs de retour pour les méthodes d’API WinRT dans cet espace ont été supprimées et sont maintenant void depuis que ces méthodes réussissent toujours.
  • Les appels ImportDll C# ne sont plus nécessaires pour GetWindowIdFromWindow et GetWindowFromWindowId. Utilisez les méthodes wrapper .NET disponibles dans la classe Microsoft.UI.Win32Interop à la place.

Limitations importantes :

  • Le SDK d'application Windows ne fournit pas actuellement de méthodes pour attacher le contenu d'une infrastructure d’interface utilisateur à une AppWindow ; vous êtes limité à l'utilisation des méthodes d'accès interopérables HWND.
  • La personnalisation de la barre de titre de fenêtre fonctionne uniquement sur Windows 11. Utilisez la méthode IsCustomizationSupported pour vérifier la prise en charge des fonctionnalités de personnalisation de la barre de titre. Nous avons l’intention d’apporter cette fonctionnalité de bas niveau.

Pour plus d'informations, voir Gérer les fenêtres d'application (SDK d'application Windows).

Input (1.0.0-preview2)

Nouvelles mises à jour :

  • Prise en charge améliorée de l’entrée du pavé tactile de précision.

Limitations importantes :

  • Toutes les fonctions de fabrique statique de PointerPoint ont été supprimées : GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints et GetIntermediatePointsTransformed.
  • Le SDK d'application Windows ne prend pas en charge la récupération d’objets PointerPoint avec des ID de pointeur. Au lieu de cela, vous pouvez utiliser la fonction membre GetTransformedPoint de PointerPoint pour récupérer une version transformée d’un objet PointerPoint existant. Pour les points intermédiaires, vous pouvez utiliser les fonctions membres de GetIntermediatePoints et GetTransformedIntermediatePoints de PointerEventArgs. Pour plus d’informations, consultez la documentation du serveur IIS.

MRT Core (1.0.0-preview2)

Nouvelles mises à jour :

  • Les développeurs d’applications peuvent désormais refuser l’indexation d’un fichier image ou d’un fichier RESW dans le fichier IRP dans les projets .NET. Pour plus d’informations, consultez le problème 980.

Limitations importantes :

  • Dans les projets .NET, les fichiers de ressources copiés-collés dans le dossier du projet ne sont pas indexés sur F5 si l’application a déjà été générée. Pour contourner ce problème, générez à nouveau l’application. Pour plus d’informations, consultez le problème 1503.
  • Dans les projets .NET, les fichiers de ressources existants ajoutés à partir d’un dossier externe ne sont pas indexés sans paramètre manuel de l’action de génération. Pour contourner ce problème, définissez l’action de génération dans Visual Studio : contenu pour les fichiers image et PRIResource pour les fichiers RESW. Pour plus d’informations, consultez le problème 1504.

Déploiement pour les applications non empaquetées

Nouvelles fonctionnalités :

  • SDK d'application Windows 1.0 Aperçu 2 introduit un wrapper .NET pour l’API de programme d’amorçage (voir Utiliser le runtime du SDK d’application Windows pour les applications empaquetées avec un emplacement externe ou non empaqueté). L’API de démarrage est un ensemble de fonctions C/C++ natives que les applications non empaquetées doivent utiliser pour prendre dynamiquement une dépendance sur le package d’infrastructure du SDK d’application Windows au moment de l’exécution. Le wrapper .NET offre un moyen plus simple d’appeler l’API de démarrage à partir d’applications .NET, y compris les applications Windows Forms et WPF. Le wrapper .NET pour l’API de démarrage est disponible dans l’assembly Microsoft.WindowsAppRuntime.Bootstrap.Net.dll, qui est local dans votre projet d’application. Pour plus d’informations sur le wrapper .NET, consultez Bibliothèque de wrapper .NET.
  • Les applications empaquetées peuvent désormais utiliser l’API de déploiement pour obtenir les packages MSIX principaux et singleton installés sur l’ordinateur. Les packages principaux et singleton font partie du package d’infrastructure installé avec l’application, mais en raison d’une limitation avec le modèle d’application Windows, les applications empaquetées devront effectuer cette étape supplémentaire afin d’installer ces packages. Pour plus d’informations sur le fonctionnement de l’API de déploiement, consultez Guide de déploiement du SDK d’application Windows pour les applications empaquetées dépendantes du framework.

Limitations importantes :

  • Le wrapper .NET pour l’API Bootstrapper est uniquement destiné à être utilisé par les applications .NET non empaquetées afin de simplifier l’accès aux SDK d'application Windows.
  • Seules les applications empaquetées MSIX qui sont entièrement approuvées ou dont la fonctionnalité packageManagement est restreinte ont l’autorisation d’utiliser l’API de déploiement pour installer les dépendances de package main et singleton. La prise en charge des applications empaquetées à confiance partielle sera disponible dans les versions ultérieures.
  • Lorsque F5 teste une application x86 qui utilise la méthode DeploymentManager.Initialize sur un système x64, vérifiez que le framework x64 est installé d’abord en exécutant WindowsAppRuntimeInstall.exe. Sinon, vous rencontrerez une erreur NOT_FOUND en raison du fait que Visual Studio ne déploie pas le framework x64, ce qui se produit normalement par le biais du déploiement via le Store ou du chargement indépendant.

Cycle de vie de l’application

La plupart des fonctionnalités de cycle de vie des applications existent déjà dans la plateforme UWP et ont été introduites dans le SDK d’application Windows pour être utilisées par les types d’applications de bureau, en particulier les applications console non empaquetées, les applications Win32, les applications Windows Forms et les applications WPF. L’implémentation du SDK d’application Windows de ces fonctionnalités ne peut pas être utilisée dans les applications UWP, car il existe des fonctionnalités équivalentes dans la plateforme UWP elle-même.

Les applications non UWP peuvent également être empaquetées dans des packages MSIX. Bien que ces applications puissent utiliser certaines des fonctionnalités de cycle de vie des applications du SDK d’application Windows, elles doivent utiliser l’approche de manifeste lorsqu’elles sont disponibles. Par exemple, elles ne peuvent pas utiliser les API RegisterForXXXActivation du SDK d’application Windows et doivent à la place s’inscrire pour une activation enrichie via le manifeste.

Toutes les contraintes pour les applications empaquetées s’appliquent également aux applications WinUI, qui sont empaquetées, et il existe des considérations supplémentaires, comme décrit ci-dessous.

Considérations importantes :

  • Activation enrichie : GetActivatedEventArgs

  • Inscrire/annuler l’inscription de l’activation enrichie

    • Applications non empaquetées : entièrement utilisables.
    • Applications empaquetées : non utilisables, utilisez le manifeste MSIX de l’application à la place.
    • Pour plus d'informations, voir Rich activation with the app lifecycle API.

  • Instanciation unique/multi-instanciation

    • Applications non empaquetées : entièrement utilisables.
    • Applications empaquetées : entièrement utilisables.
    • Applications WinUI : si une application souhaite détecter d’autres instances et rediriger une activation, elle doit le faire le plus tôt possible, avant d’initialiser des fenêtres, etc. Pour cela, l’application doit définir DISABLE_XAML_GENERATED_MAIN et écrire un Main (C#) ou WinMain (C++) personnalisé où elle peut effectuer la détection et la redirection.
    • RedirectActivationToAsync est un appel asynchrone et vous ne devez pas attendre un appel asynchrone si votre application s’exécute dans une STA. Pour les applications Windows Forms et WinUI C#, vous pouvez déclarer Main comme étant asynchrone, si nécessaire. Pour les applications WinUI C++ et WPF C#, vous ne pouvez pas déclarer Main comme étant asynchrone ; vous devez déplacer l’appel de redirection vers un autre thread pour vous assurer de ne pas bloquer la STA.
    • Pour plus d’informations, consultez Instancier des applications avec l’API de cycle de vie de l’application.

  • Notifications d’alimentation/état

Problème connu :

Les associations de type de fichier encodent incorrectement %1 en %251 lors de la définition du modèle de ligne de commande du gestionnaire Verb, qui bloque les applications Win32 non empaquetées. Vous pouvez modifier manuellement la valeur du Registre pour qu’elle soit %1 à la place, comme solution de contournement partielle. Si le chemin du fichier cible contient une espace, la commande échoue toujours et il n’existe aucune solution de contournement pour ce scénario.

Autres limitations et problèmes connus :

  • La version 1.0 Aperçu 1 et Aperçu 2 contiennent un bogue critique. Si vous avez déjà installé l’un de ces aperçus, consultez comment résoudre le problème. Nous vous recommandons d’utiliser la version 1.0 Aperçu 3 à la place.

  • Cette version présente les modèles d’application vide, empaquetée (WinUI 3 dans Desktop) pour les projets C# et C++. Ces modèles vous permettent de créer votre application dans un package MSIX sans utiliser de projet de package distinct. Ces modèles présentent des problèmes connus dans cette version :

    • Modèle C# pour Visual Studio 2019. Vous rencontrerez l’erreur lorsque vous essayez de générer le projet : « Le projet ne sait pas comment exécuter le nom du projet de profil ». Pour résoudre ce problème, installez l'extension Single-project MSIX Packaging Tools.

    • Modèle C# pour Visual Studio 2019 et Visual Studio 2022. Vous rencontrerez l’erreur suivante quand vous tenterez d’exécuter ou de déboguer votre projet sur l’ordinateur de développement : « Le projet doit être déployé pour que nous puissions effectuer un débogage. Activez Deploy dans Configuration Manager. » Pour résoudre ce problème, activez le déploiement de votre projet dans Configuration Manager. Pour obtenir des instructions, consultez Créer votre premier projet WinUI 3 (SDK d'application Windows).

    • Modèle C++ pour Visual Studio 2019 et Visual Studio 2022. Dans cette version, ces projets sont limités à l’appel du sous-ensemble d’API Win32 qui peuvent être appelées par des applications UWP. Le modèle Application vide, empaquetée avec WAP (WinUI 3 in Desktop) n’est pas affectée par ce problème.

    • Modèle C++ pour Visual Studio 2022 version 17.0 jusqu’à Preview 4. Vous rencontrerez l’erreur suivante la première fois que vous essayez d’exécuter votre projet : « Il y a eu des erreurs de déploiement ». Pour résoudre ce problème, exécuter ou déployer votre projet une deuxième fois. Ce problème sera résolu dans Visual Studio 2022 version 17.0 préversion 5.

  • L’API notifications Push (espace de noms Microsoft.Windows.PushNotifications) est incorrectement incluse dans la version 1.0 Aperçu 2. Il s’agit toujours d’une fonctionnalité expérimentale, et pour vous l’utiliser, vous devez installer la version expérimentale 1.0 à la place. Cette fonctionnalité sera supprimée de la prochaine version 1.0.

  • L’API de cycle de vie des applications (espace de noms Microsoft.Windows.AppLifecycle) inclut incorrectement l’attribut expérimental dans la version 1.0 Aperçu 2. L’attribut expérimental sera supprimé de cette API dans la prochaine version.

  • Aucune prise en charge de configuration de build de processeur : lorsque vous ajoutez le SDK d’application Windows à une application ou un composant .NET existant qui prend en charge n’importe quel processeur, vous devez spécifier l’architecture souhaitée : x86, x64 ou arm64.

  • Les projets C# utilisant la version 1.0 Aperçu 2 doivent utiliser le Kit de développement logiciel (SDK) .NET 6 suivant ou version ultérieure (voir Télécharger .NET et .NET 5 atteindre la fin du support le 10 mai 2022).

  • Une alternative à DispatcherQueue.TryEnqueue (pour reprendre l’exécution sur le thread de file d’attente du répartiteur) consiste à utiliser la fonction d’assistance resume_foreground dans la bibliothèque d’implémentation Windows (WIL) :

    1. Ajoutez une référence à votre projet au package NuGet Microsoft.Windows.ImplementationLibrary .
    2. Ajoutez #include <wil/cppwinrt_helpers.h> à votre pch.h.
    3. Ajoutez #include <winrt/Microsoft.UI.Dispatching.h> à votre pch.h.
    4. Maintenant co_await wil::resume_foreground(your_dispatcherqueue);.

Version 1.0 Aperçu 1 (1.0.0-preview1)

Important

La version 1.0 Aperçu 1 et Aperçu 2 contiennent un bogue critique. Si vous avez déjà installé l’un de ces aperçus, consultez comment résoudre le problème. Nous vous recommandons d’utiliser la version 1.0 Aperçu 3 à la place.

Il s’agit de la première version du canal de préversion pour la version 1.0. Il prend en charge tous les aperçus fonctionnalités du canal.

Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour cette version.

WinUI 3 (1.0.0-preview1)

Cette version de WinUI 3 est axée sur la génération vers la version 1.0 avec des correctifs de bogues.

  • Nouvelles fonctionnalités : aucune nouvelle fonctionnalités dans Aperçu 1.
  • Bogues : pour obtenir la liste complète des bogues résolus dans cette version, consultez notre référentiel GitHub.

Pour plus d’informations ou pour commencer à développer avec WinUI 3, consultez :

Windowing (1.0.0-preview1)

Cette version apporte l’API Windowing que nous avons introduite dans Experimental 1 à un état d’aperçu. Il n’existe aucune nouvelle fonctionnalité majeure dans cette version, car elle se concentre sur les correctifs de bogues, la stabilité et les ajustements de la signature d’API. Les modifications et les ajouts notables sont appelés ci-dessous.

Nouvelles fonctionnalités :

  • DisplayAreaWatcher a été ajouté aux API de fenêtrage. DisplayAreaWatcher permet à un développeur d’observer les modifications apportées à la topologie d’affichage et d’énumérer les DisplayAreas actuellement définies dans le système.
  • AppWindow prend désormais en charge la définition de l’icône de fenêtre via la méthode SetIcon, et AppWindowTitleBar prend désormais en charge la sélection de l’icône afficher/masquer la fenêtre avec le menu système via la propriété IconShowOptions.

Limitations importantes :

  • Cette version de AppWindow est actuellement disponible uniquement pour les applications Win32 (empaquetées et non empaquetées).
  • Le SDK d'application Windows ne fournit pas actuellement de méthodes pour attacher le contenu d'une infrastructure d’interface utilisateur à une AppWindow ; vous êtes limité à l'utilisation des méthodes d'accès interopérables HWND.
  • La personnalisation de la barre de titre de fenêtre fonctionne uniquement sur Windows 11. Utilisez la méthode IsCustomizationSupported pour vérifier la prise en charge des fonctionnalités de personnalisation de la barre de titre. Nous avons l’intention d’apporter cette fonctionnalité de bas niveau.

Pour plus d'informations, voir Gérer les fenêtres d'application (SDK d'application Windows).

Input (1.0.0-preview1)

Cette version apporte de nouvelles fonctionnalités à l’API d’entrée. Les modifications et les ajouts notables sont appelés ci-dessous.

Nouvelles fonctionnalités et mises à jour :

  • PointerPredictor donne aux applications sensibles à la latence d’entrée, telles que les applications d’entrée manuscrites, la possibilité de prédire des emplacements de point d’entrée jusqu’à 15 ms à l’avenir pour obtenir une meilleure latence et une animation fluide.
  • PenDeviceInterop vous permet d’acquérir une référence à Windows.Devices.Input.PenDevice à l’aide de la méthode FromPointerPoint .
  • InputCursor fournit une distinction explicite entre les types de curseur système prédéfinis et les types de curseurs personnalisés en supprimant le type « Personnalisé » présent dans CoreCursor, et en fractionnant l’objet CoreCursor en objets distincts.
  • Mises à jour à API InputCursor.
  • GestureRecognizer a été déplacé hors expérimental vers Microsoft.UI.Input.
  • PointerPoint a quitté l’expérience expérimentale vers Microsoft.UI.Input.
  • Entrée de souris, tactile et stylet entièrement prise en charge pour Le glisser-déplacer WinUI 3.

Limitations importantes :

  • Cette version des API d’entrée présente des problèmes connus avec Windows version 1809.
  • MRT Core n’est pas encore pris en charge par un sous-type d’InputCursor.
  • L’utilisation directe de l’API de SDK de plateforme Windows.UI.Core.CoreDragOperation ne fonctionnera pas avec les applications WinUI.
  • Les propriétés RawPosition et ContactRectRaw de PointerPoint ont été supprimées, car elles faisaient référence à des valeurs non prédites, qui étaient identiques aux valeurs normales dans le système d’exploitation. Utilisez Position et ContactRect à la place. La prédiction de pointeur est désormais gérée avec l’objet d’API Microsoft.UI.Input.PointerPredictor.

MRT Core (1.0.0-preview1)

Depuis la version 1.0 Preview 1, les API MRT Core sont passées de l’espace de noms Microsoft.ApplicationModel.Resources à l’espace de noms Microsoft.Windows.ApplicationModel.Resources .

Autres limitations et problèmes connus :

  • La version 1.0 Aperçu 1 et Aperçu 2 contiennent un bogue critique. Si vous avez déjà installé l’un de ces aperçus, consultez comment résoudre le problème. Nous vous recommandons d’utiliser la version 1.0 Aperçu 3 à la place.

  • Les projets créés à l’aide de l’application vide C++ , empaquetés avec WAP (WinUI 3 in Desktop) rencontrent l’erreur de génération suivante par défaut : fatal error C1083: Cannot open include file: 'winrt/microsoft.ui.dispatching.co_await.h': No such file or directory. Pour résoudre ce problème, supprimez la ligne de code suivante du fichier pch.h . Ce problème sera corrigé dans la prochaine version.

    #include <winrt/microsoft.ui.dispatching.co_await.h>

  • Une alternative à DispatcherQueue.TryEnqueue (pour reprendre l’exécution sur le thread de file d’attente du répartiteur) consiste à utiliser la fonction d’assistance resume_foreground dans la bibliothèque d’implémentation Windows (WIL) :

    1. Ajoutez une référence à votre projet au package NuGet Microsoft.Windows.ImplementationLibrary .
    2. Ajoutez #include <wil/cppwinrt_helpers.h> à votre pch.h.
    3. Ajoutez #include <winrt/Microsoft.UI.Dispatching.h> à votre pch.h.
    4. Maintenant co_await wil::resume_foreground(your_dispatcherqueue);.

  • Aucune prise en charge de toute configuration de build d’UC : le SDK d’application Windows est écrit en code natif et ne prend donc pas en charge les configurations d’UC. Les gabarits WinUI 3 dans Visual Studio autorisent uniquement les versions spécifiques à l’architecture. Lorsque vous ajoutez le SDK d’application Windows à une application ou un composant .NET existant qui prend en charge n’importe quel UC, vous devez spécifier l’architecture souhaitée : x86, x64 ou arm64.

  • Les applications .NET doivent cibler la build 18362 ou ultérieure : votre TFM doit être défini sur net6.0-windows10.0.18362 ou version ultérieure, et la <TargetPlatformVersion> de votre projet d’empaquetage doit être défini sur 18362 ou version ultérieure. Pour plus d’informations, consultez ce problème connu sur GitHub.

  • Les projets C# utilisant la version 1.0 Aperçu 1 doivent utiliser le Kit de développement logiciel (SDK) .NET 6 suivant ou version ultérieure (voir Télécharger .NET et .NET 5 atteindre la fin du support le 10 mai 2022).

  • Applications non empaquetées non prises en charge sur Windows 10 version 1809 : cela doit être résolu dans la prochaine version.