Notes de publication du canal d'aperçu pour le SDK d'application Windows
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.
Ce canal fournit une préversion de la prochaine version stable. Il peut y avoir des changements d’API cassants entre une version de canal en préversion donnée et la prochaine version stable. Les versions préliminaires du canal n’incluent pas d’API expérimentales.
Liens importants :
- Si vous souhaitez mettre à niveau une application existante d’une version antérieure du SDK d’application Windows vers une version plus récente, consultez Mettre à jour des projets existants vers la dernière version du SDK d’application Windows.
- Pour obtenir de la documentation sur l’utilisation de la préversion, consultez Installer des outils pour un aperçu et les canaux expérimentaux du SDK d'application Windows.
Version 1.5 en préversion 1 (1.5.0-preview1)
Il s'agit de la dernière version du canal de préversions pour la version 1.5.
Dans une application existante du SDK d'application Windows 1.4 (à partir du canal stable), vous pouvez mettre à jour votre package NuGet vers 1.5.0-preview1 (voir la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de package NuGet).
Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.
Mises à jour du runtime et de l'arrêt de XAML Islands
- Il existe une différence de comportement entre WinAppSDK 1.4 et WinAppSDK 1.5 pour les applications basées sur XAML Islands lorsque la dernière fenêtre XAML de n'importe quel thread est fermée.
- Dans WinAppSDK 1.4, le runtime XAML quitte toujours la boucle d'événements du thread lorsque la dernière fenêtre XAML d'un thread est fermée.
- Dans WinAppSDK 1.5 :
- Dans le cas d'une application de bureau WinUI, le comportement par défaut reste le même que dans WinAppSDK 1.4.
- Si vous utilisez XAML pour l'API DesktopWindowXamlSource (« XAML Islands »), le comportement par défaut est désormais que XAML ne quitte pas automatiquement la boucle d'événements du thread.
- Dans les deux modes, vous pouvez modifier ce comportement en établissant la propriété
Application.DispatcherShutdownMode
.
- Pour en savoir plus, veuillez consulter la documentation relative à la propriété
Application.DispatcherShutdownMode
lorsqu'elle est disponible.
- Il existe une différence de comportement entre WinAppSDK 1.4 et WinAppSDK 1.5 pour les applications basées sur XAML Islands en ce qui concerne la durée de vie du runtime XMAL :
- Dans WinAppSDK 1.4, le runtime XAML s'arrête sur un thread si tous les objets
WindowsXamlManager
etDesktopWindowXamlSource
d'un thread donné sont fermés ou arrêtés, ou si l'exécution deDispatcherQueue
sur ce thread est arrêtée (le runtime XAML s'arrête pendant la phaseDispatcherQueue.FrameworkShutdownStarting
). - Dans WinAppSDK 1.5, le runtime XAML ne s'arrête sur un thread que si l'exécution de DispatcherQueue sur ce thread est arrêtée (le runtime XAML s'arrête pendant la phase
DispatcherQueue.FrameworkShutdownStarting
). - Pour en savoir plus, veuillez consulter la documentation relative à la classe
WindowsXamlManager
lorsqu'elle est disponible.
- Dans WinAppSDK 1.4, le runtime XAML s'arrête sur un thread si tous les objets
Contrôle WinUI Maps
La version initiale du contrôle WinUI Maps
est désormais disponible ! Ce contrôle est alimenté par WebView2 et Azure Maps, et fournit les fonctionnalités suivantes :
- Mouvement panoramique et zoom avec les boutons de la carte ou par interaction tactile.
- Modification du style de la carte (satellite, relief ou affichage de la rue).
- Ajout par programmation d'épingles interactives avec des icônes personnalisables par le développeur à la carte.
- Personnalisation par les développeurs de l'endroit où la carte est centrée lors du chargement initial.
- Contrôle par les développeurs du masquage ou de l'affichage des boutons de mouvement panoramique, zoom et styles de carte.
Remarque
Pour utiliser le contrôle Maps
, vous aurez besoin d'une clé Azure Maps. Pour créer la clé, consultez la page de documentation Azure Maps sur la création d'une application web.
Le contrôle Maps
est entièrement nouveau et nous vous invitons à nous faire part de vos commentaires pour évaluer sa future orientation !
Autres nouvelles fonctionnalités de WinAppSDK
- Ajout de la prise en charge du modèle de déploiement PublishSingleFile. Pour en savoir plus sur PublishSingleFile, veuillez consulter la documentation relative au déploiement à fichier unique.
Résolution des bogues
- Résolution d'un problème survenu dans la version 1.5-experimental2, dans laquelle la DLL de projection n'était pas générée. Pour plus d’informations, veuillez consulter la section GitHub #4152.
- Résolution d'un problème qui faisait que le bouton représentant des points de suspension dans la fenêtre pop-up de mise en forme du texte du
RichEditBox
n'affichait pas correctement la liste des actions. Pour plus d’informations, veuillez consulter la section GitHub #9140. - Résolution d'un problème qui faisait que
ListView
ne gérait pas correctement les raccourcis clavier. Pour plus d’informations, veuillez consulter la section GitHub #8063. - Résolution d'un problème de violation d'accès lors de l'utilisation de
AccessKey
pour fermer une fenêtre. Pour plus d’informations, veuillez consulter la section GitHub #8648. - Résolution d'un problème affectant l'alignement du texte dans une
MenuFlyoutItem
au sein d'unMenuBar
. Pour plus d’informations, veuillez consulter la section GitHub #8755. - Résolution d'un problème qui faisait qu'un texte mis en surbrillance ne le restait pas lors d'un clic droit. Pour plus d’informations, veuillez consulter la section GitHub #1801.
- Résolution d'un problème qui faisait que les fenêtres inactives entraînaient le plantage de l'application lorsqu'elles étaient fermées. Pour plus d’informations, veuillez consulter la section GitHub #8913.
- Résolution d'un problème qui pouvait entraîner le blocage des applications en cas de défilement avec le bouton du milieu de la souris suivi d'un clic gauche immédiatement après. Pour plus d’informations, veuillez consulter la section GitHub #9233.
Nouvelles API dans 1.5.0-preview1
La version 1.5-preview1 inclut les nouvelles API suivantes par rapport à la version stable 1.4 :
Microsoft.Graphics.DirectX
DirectXPixelFormat
A4B4G4R4
Microsoft.UI.Input
FocusNavigationReason
FocusNavigationRequest
FocusNavigationRequestEventArgs
FocusNavigationResult
InputFocusController
DepartFocus
NavigateFocusRequested
InputFocusNavigationHost
Microsoft.UI.Xaml
Application
DispatcherShutdownMode
DebugSettings
LayoutCycleDebugBreakLevel
LayoutCycleTracingLevel
DispatcherShutdownMode
LayoutCycleDebugBreakLevel
LayoutCycleTracingLevel
Microsoft.UI.Xaml.Controls
MapControl
MapControlMapServiceErrorOccurredEventArgs
MapElement
MapElementClickEventArgs
MapElementsLayer
MapIcon
MapLayer
SelectorBar
SelectorBarItem
SelectorBarSelectionChangedEventArgs
WebView2
EnsureCoreWebView2Async
EnsureCoreWebView2Async
Microsoft.UI.Xaml.Hosting
WindowsXamlManager
GetForCurrentThread
XamlShutdownCompletedOnThread
XamlShutdownCompletedOnThreadEventArgs
Microsoft.Web.WebView2.Core
CoreWebView2
FrameId
CoreWebView2AcceleratorKeyPressedEventArgs
IsBrowserAcceleratorKeyEnabled
CoreWebView2BrowserExtension
CoreWebView2BrowsingDataKinds
ServiceWorkers
CoreWebView2CustomSchemeRegistration
CoreWebView2CustomSchemeRegistration (String)
AllowedOrigins
SchemeName
CoreWebView2Environment
GetProcessExtendedInfosAsync
CoreWebView2EnvironmentOptions
AreBrowserExtensionsEnabled
CustomSchemeRegistrations
CoreWebView2Frame
FrameId
CoreWebView2FrameInfo
FrameId
FrameKind
ParentFrameInfo
CoreWebView2FrameKind
CoreWebView2MouseEventKind
NonClientRightButtonDown
NonClientRightButtonUp
CoreWebView2NavigationKind
CoreWebView2NavigationStartingEventArgs
NavigationKind
CoreWebView2NewWindowRequestedEventArgs
OriginalSourceFrameInfo
CoreWebView2ProcessExtendedInfo
CoreWebView2Profile
AddBrowserExtensionAsync
Delete
Deleted
Microsoft.Windows.Management.Deployment
AddPackageOptions
EnsureReadyOptions
PackageDeploymentContract
PackageDeploymentManager
PackageDeploymentProgress
PackageDeploymentProgressStatus
PackageDeploymentResult
PackageDeploymentStatus
PackageRuntimeManager
PackageSet
PackageSetItem
PackageSetItemRuntimeDisposition
PackageSetRuntimeDisposition
PackageVolume
ProvisionPackageOptions
RegisterPackageOptions
RemovePackageOptions
StagePackageOptions
StubPackageOption
Microsoft.Windows.Widgets.Feeds.Providers
CustomQueryParametersRequestedArgs
CustomQueryParametersUpdateOptions
FeedDisabledArgs
FeedEnabledArgs
FeedManager
FeedProviderDisabledArgs
FeedProviderEnabledArgs
FeedProviderInfo
IFeedManager
IFeedProvider
Version 1.4 Aperçu 2 (1.4.0-preview2)
Il s’agit de la dernière version de l’aperçu du canal pour la version 1.4.
Dans une application existante utilisant SDK d'application Windows 1.3 (à partir du canal stable), vous pouvez mettre à jour votre package Nuget vers 1.4.0-preview2 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de packages NuGet).
Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.
XAML Islands n’est plus expérimental
XAML Islands et la plateforme ContentIslands sous-jacente ne sont plus expérimentaux.
- Actuellement, XAML Islands est testé uniquement pour les applications C++. Cette version n’a aucun élément de wrapper pratique pouvant être utilisé dans WPF ou WinForms.
DesktopWindowXamlSource
et les types associés ont été ajoutés dans l’espace de noms Microsoft.UI.Xaml.Hosting pour XAML Islands.XamlRoot.ContentIslandEnvironment
a été ajouté pour vous aider à accéder aux informations Island sous-jacentes d’un élément.- De nombreux nouveaux types ont été introduits dans l’espace de noms Microsoft.UI.Content et l’espace de noms Microsoft.UI.Input pour la prise en charge sous-jacente de XAML Islands ou pour utiliser cette fonctionnalité ContentIslands sans XAML.
- Un nouveau
DragDropManager
(plus les types associés) a été ajouté dans l’espace de noms Microsoft.UI.Input.DragDrop pour les scénarios Island.
Mises à jour ItemsView
La nouvelle ItemsView
classe introduite dans la version 1.4-preview1 a été considérablement mise à jour avec de nouvelles propriétés et une nouvelle classe de prise en charge.
- Le nouveau contrôle
ItemsView
affiche une collection de données.ItemsView
est similaire aux contrôlesListView
etGridView
, mais est généré à partir des composantsItemsRepeater
,ScrollView
,ItemContainer
etItemCollectionTransitionProvider
. Il offre la possibilité unique de se connecter à des implémentations deLayout
ouItemCollectionTransitionProvider
personnalisées. Un autre avantage clé est la possibilité de changer la disposition à la volée tout en préservant la sélection des éléments. Le contrôle interneScrollView
offre également des fonctionnalités non disponibles dans le contrôleScrollViewer
deListView
/GridView
, comme la possibilité de contrôler l’animation pendant les défilements programmatiques.- Une nouvelle propriété
ItemTransitionProvider
surItemsRepeater
(et le nouveau contrôleItemsView
) vous permet de spécifier un objetItemCollectionTransitionProvider
pour contrôler les animations de transition sur ce contrôle. Une méthodeCreateDefaultItemTransitionProvider
a également été ajoutée àLayout
, ce qui permet à un objet de disposition de fournir une transition de secours pour l’accompagner si vous n’en fournissez pas explicitement sur le contrôleItemsView
. - Nouvelle propriété
IndexBasedLayoutOrientation
surLayout
où l’orientation de la disposition, le cas échéant, des éléments est basée sur leur index dans la collection source. La valeur par défaut estIndexBasedLayoutOrientation.None
. Les dispositions personnalisées définissent cette propriété en appelant la nouvelle méthode (protégée)SetIndexBasedLayoutOrientation
. - Une nouvelle propriété
VisibleRect
surVirtualizingLayoutContext
obtient le rectangle visible de la fenêtre d’affichage dans leFrameworkElement
associé àLayout
. La méthode virtuelleVirtualizingLayoutContext.VisibleRectCore
protégée peut être remplacée pour fournir la valeur que la propriétéVisibleRect
doit renvoyer.
- Une nouvelle propriété
- La nouvelle classe
LinedFlowLayout
est généralement utilisée pour mettre en place les éléments du contrôle de collectionItemsView
. Elle est particulièrement utile pour afficher une collection d’images. Elle le fait en les disposant de gauche à droite et de haut en bas, en lignes de hauteur égale. Les images remplissent une ligne horizontale, puis passent à la ligne suivante. Les images peuvent être rognées à gauche et à droite pour s’adapter à une ligne. Elles peuvent également être développées horizontalement, et rognées en haut et en bas pour remplir une ligne quand le mode d’étirement est utilisé.
Nouvelles fonctionnalités de WinAppSDK
Popup/FlyoutBase.IsConstrainedToRootBounds = false
est désormais pris en charge, ce qui permet à une fenêtre contextuelle/un contrôle suspendu de s’étendre en dehors des limites de la fenêtre parente. Une propriétéSystemBackdrop
a été ajoutée à ces types pour prendre en charge l’acrylique dans ces fenêtres contextuelles non contraintes. Les menus par défaut utilisent cette option pour avoir l’acrylique.Closed
,FrameworkClosed
etIsClosed
ont été ajoutés àDesktopAcrylicController
etMicaController
pour améliorer la gestion pendant l’arrêt de l’objet/du thread.DesktopAcrylicController.Kind
peut maintenant être défini pour choisir des apparences acryliques standard.DispatcherQueue
a de nouveaux événements et applications auxiliaires pour permettre une meilleure organisation de l’arrêt et pour que les applications utilisant Islands puissent exécuter facilement une boucle d’événements prise en charge standard.InputNonClientPointerSource
dans l’espace de noms Microsoft.UI.Input peut être utilisé dans les scénarios de barre de titre personnalisé pour définir des régions de zone non cliente. Le code peut s’inscrire à des événements correspondants, comme les événements de pointage et de clic sur ces régions.AppWindow
a des nouvelles applications auxiliaires qu’il peut obtenir et associer à unDispatcherQueue
.- Le nouvel événement
TreeView.SelectionChanged
permet aux développeurs de répondre quand l’utilisateur ou le code-behind change l’ensemble des nœuds sélectionnés dans le contrôleTreeView
. - Le nouveau contrôle
ScrollView
offre une nouvelle alternative àScrollViewer
. Ce nouveau contrôle est hautement aligné en matière de comportement et d’API sur le contrôle existantScrollViewer
, mais est basé surInteractionTracker
, a de nouvelles fonctionnalités comme les changements de vue pilotés par l’animation, et est également conçu pour garantir une fonctionnalité complète deItemsRepeater
. Consultez Un ScrollViewer plus flexible · Problème n° 108 · microsoft/microsoft-ui-xaml (github.com) pour plus d’informations. Différents nouveaux types, y comprisScrollPresenter
, font partie du modèleScrollView
général. - Le nouveau contrôle
AnnotatedScrollBar
étend les fonctionnalités d’une barre de défilement classique en fournissant un moyen simple de parcourir une grande collection d’éléments. Le résultat est obtenu en utilisant une barre cliquable avec des étiquettes qui servent de marqueurs. Il permet également une compréhension plus granulaire du contenu de défilement en affichant une info-bulle quand vous pointez sur la barre cliquable.
Nouvelles API dans la version 1.4.0-preview2
La version 1.4-preview2 inclut les nouvelles API suivantes par rapport à la version 1.4-preview1 précédente :
Microsoft.UI
ClosableNotifierHandler
IClosableNotifier
Microsoft.UI.Composition.SystemBackdrops
DesktopAcrylicController
Closed
FrameworkClosed
IsClosed
Kind
DesktopAcrylicKind
MicaController
Closed
FrameworkClosed
IsClosed
Microsoft.UI.Content
ContentCoordinateConverter
ContentCoordinateRoundingMode
ContentDeferral
ContentEnvironmentSettingChangedEventArgs
ContentEnvironmentStateChangedEventArgs
ContentIsland
ContentIslandAutomationProviderRequestedEventArgs
ContentIslandEnvironment
ContentIslandStateChangedEventArgs
ContentLayoutDirection
ContentSite
ContentSiteEnvironment
ContentSiteEnvironmentView
ContentSiteRequestedStateChangedEventArgs
ContentSiteView
ContentSizePolicy
DesktopChildSiteBridge
DesktopSiteBridge
IContentSiteBridge
Microsoft.UI.Dispatching
DispatcherExitDeferral
DispatcherQueue
EnqueueEventLoopExit
EnsureSystemDispatcherQueue
FrameworkShutdownCompleted
FrameworkShutdownStarting
RunEventLoop
RunEventLoop
DispatcherQueueController
ShutdownQueue
DispatcherRunOptions
Microsoft.UI.Input
CharacterReceivedEventArgs
ContextMenuKeyEventArgs
FocusChangedEventArgs
InputActivationListener
GetForIsland
InputFocusChangedEventArgs
InputFocusController
InputKeyboardSource
CharacterReceived
ContextMenuKey
GetCurrentKeyState
GetForIsland
GetKeyState
KeyDown
KeyUp
SystemKeyDown
SystemKeyUp
InputNonClientPointerSource
InputPointerSource
GetForIsland
InputPreTranslateKeyboardSource
KeyEventArgs
NonClientCaptionTappedEventArgs
NonClientPointerEventArgs
NonClientRegionKind
NonClientRegionsChangedEventArgs
PhysicalKeyStatus
VirtualKeyStates
Microsoft.UI.Input.DragDrop
DragDropManager
DragDropModifiers
DragInfo
DragOperation
DragUIContentMode
DragUIOverride
DropOperationTargetRequestedEventArgs
IDropOperationTarget
Microsoft.UI.Windowing
AppWindow
AssociateWithDispatcherQueue
Create
DispatcherQueue
Microsoft.UI.Xaml
XamlRoot
ContentIslandEnvironment
Microsoft.UI.Xaml.Automation.Peers
ItemsViewAutomationPeer
Microsoft.UI.Xaml.Controls
AnnotatedScrollBar
AnnotatedScrollBarDetailLabelRequestedEventArgs
AnnotatedScrollBarLabel
AnnotatedScrollBarScrollingEventArgs
AnnotatedScrollBarScrollingEventKind
IndexBasedLayoutOrientation
ItemCollectionTransition
ItemCollectionTransitionCompletedEventArgs
ItemCollectionTransitionOperation
ItemCollectionTransitionProgress
ItemCollectionTransitionProvider
ItemCollectionTransitionTriggers
ItemsRepeater
ItemTransitionProvider
ItemTransitionProviderProperty
ItemsView
ItemsViewItemInvokedEventArgs
ItemsViewSelectionChangedEventArgs
ItemsViewSelectionMode
Layout
CreateDefaultItemTransitionProvider
IndexBasedLayoutOrientation
SetIndexBasedLayoutOrientation
LinedFlowLayout
LinedFlowLayoutItemCollectionTransitionProvider
LinedFlowLayoutItemsInfoRequestedEventArgs
LinedFlowLayoutItemsJustification
LinedFlowLayoutItemsStretch
ScrollingAnchorRequestedEventArgs
ScrollingAnimationMode
ScrollingBringingIntoViewEventArgs
ScrollingChainMode
ScrollingContentOrientation
ScrollingInputKinds
ScrollingInteractionState
ScrollingRailMode
ScrollingScrollAnimationStartingEventArgs
ScrollingScrollBarVisibility
ScrollingScrollCompletedEventArgs
ScrollingScrollMode
ScrollingScrollOptions
ScrollingSnapPointsMode
ScrollingZoomAnimationStartingEventArgs
ScrollingZoomCompletedEventArgs
ScrollingZoomMode
ScrollingZoomOptions
ScrollView
TreeView
SelectionChanged
TreeViewSelectionChangedEventArgs
VirtualizingLayoutContext
VisibleRect
VisibleRectCore
Microsoft.UI.Xaml.Controls.Primitives
FlyoutBase
SystemBackdrop
SystemBackdropProperty
IScrollController
IScrollControllerPanningInfo
Popup
SystemBackdrop
SystemBackdropProperty
RepeatedScrollSnapPoint
RepeatedZoomSnapPoint
ScrollControllerAddScrollVelocityRequestedEventArgs
ScrollControllerPanRequestedEventArgs
ScrollControllerScrollByRequestedEventArgs
ScrollControllerScrollToRequestedEventArgs
ScrollPresenter
ScrollSnapPoint
ScrollSnapPointBase
ScrollSnapPointsAlignment
SnapPointBase
ZoomSnapPoint
ZoomSnapPointBase
Microsoft.UI.Xaml.Hosting
DesktopWindowXamlSource
DesktopWindowXamlSourceGotFocusEventArgs
DesktopWindowXamlSourceTakeFocusRequestedEventArgs
WindowsXamlManager
XamlSourceFocusNavigationReason
XamlSourceFocusNavigationRequest
XamlSourceFocusNavigationResult
Version 1.4 Aperçu 1 (1.4.0-preview1)
Il s’agit de la dernière version de l’aperçu du canal pour la version 1.4.
Dans une application existante utilisant SDK d'application Windows 1.3 (à partir du canal stable), vous pouvez mettre à jour votre package Nuget vers 1.4.0-preview1 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de packages NuGet).
Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.
Mises à jour des widgets
Trois nouvelles interfaces ont été ajoutées pour les fournisseurs de widgets : IWidgetProvider2
, IWidgetProviderAnalytics
et IWidgetProviderErrors
. IWidgetProvider2
permet aux fournisseurs de répondre à l’action Personnaliser appelée par l’utilisateur, comme pour les widgets internes. Les interfaces IWidgetProviderAnalytics
et IWidgetProviderErrors
sont utilisées par les fournisseurs afin de collecter des données de télémétrie pour leurs widgets ; les événements d’analyse et d’échec sur les widgets sont communiqués aux fournisseurs de widgets respectifs. Les classes WidgetCustomizationRequestedArgs
, WidgetAnalyticsInfoReportedArgs
et WidgetErrorInfoReportedArgs
sont utilisées afin de communiquer des informations pertinentes pour prendre en charge les nouvelles fonctionnalités.
Nouvelles fonctionnalités de WinAppSDK
- Nouvelle classe
ThemeSettings
qui permet aux applications WinRT Win32 de détecter quand le paramètre Contraste élevé du système a changé, comme la classe AccessibilitySettingsUWP. Consultez la Spécification de l’API ThemeSettings sur GitHub pour plus d’informations. Popup/FlyoutBase.ShouldConstrainToRootBounds
est désormais pris en charge pour autoriser les info-bulles, les menus et d’autres fenêtres contextuelles à étendre en dehors des limites de la fenêtre principale. La préversion 1 ne prend pas encore entièrement en charge l’acrylique ou d’autres SystemBackdrops sur une fenêtre contextuelle/menu volant ; Des API et une implémentation supplémentaires seront incluses dans la prochaine version 1.4.AccessKeyManager.EnterDisplayMode
est une nouvelle méthode qui affiche les clés d’accès pour l’élément actuel d’une racine fournie ayant le focus. Les touches d’accès sont en « mode d’affichage » quand elles affichent un conseil de touche pour appeler une commande, par exemple, quand vous appuyez sur la touche Alt dans Paint pour afficher les touches qui correspondent aux contrôles. Cette méthode permet d’entrer le mode d’affichage programmatiquement.Application.ResourceManagerRequested
fournit un mécanisme pour avoir un autreIResourceManager
qui résout les URI de ressource dans les scénarios où leResourceManager
par défaut ne fonctionne pas. Pour plus d’informations, consultez la Spécification de l’API Application.ResourceManagerRequested sur GitHub.- Nous introduisons un nouveau contrôle de liste appelé
ItemsView
et la classe concrèteItemContainer
correspondante.ItemContainer
est un conteneur léger avec des états de sélection et des visuels intégrés, qui peut facilement encapsuler le contenu souhaité et être utilisé avecItemsView
dans un scénario de contrôle de collection.ItemsView
est toujours marqué expérimental dans l’aperçu 1, mais sera inclus dans la prochaine version 1.4. - Le SDK WebView2 a été mis à jour de la version 1661.34 à la version 1823.32.
Nouvelles API dans la version 1.4.0-preview1
La version 1.4-preview1 inclut les nouvelles API suivantes par rapport à la version stable 1.3 :
Microsoft.UI.System
ThemeSettings
Microsoft.UI.Xaml
Application
ResourceManagerRequested
ResourceManagerRequestedEventArgs
Microsoft.UI.Xaml.Automation.Peers
ItemContainerAutomationPeer
Microsoft.UI.Xaml.Controls
ItemContainer
Microsoft.UI.Xaml.Controls.Primitives
CommandBarFlyoutCommandBar
SystemBackdrop
SystemBackdropProperty
Microsoft.UI.Xaml.Input
AccessKeyManager
EnterDisplayMode
Microsoft.Web.WebView2.Core
CoreWebView2
LaunchingExternalUriScheme
MemoryUsageTargetLevel
CoreWebView2File
CoreWebView2LaunchingExternalUriSchemeEventArgs
CoreWebView2MemoryUsageTargetLevel
CoreWebView2PermissionKind
WindowManagement
CoreWebView2Profile
CookieManager
IsGeneralAutofillEnabled
IsPasswordAutosaveEnabled
CoreWebView2Settings
IsReputationCheckingRequired
CoreWebView2WebMessageReceivedEventArgs
AdditionalObjects
Microsoft.Windows.Widgets.Providers
IWidgetProvider2
IWidgetProviderAnalytics
IWidgetProviderErrors
WidgetAnalyticsInfoReportedArgs
WidgetCustomizationRequestedArgs
WidgetErrorInfoReportedArgs
Version 1.3 Aperçu 1 (1.3.0-preview1)
Il s’agit de la dernière version de l’aperçu du canal pour la version 1.3. Cette version inclut des préversions pour les nouvelles fonctionnalités dans WinAppSDK et plusieurs correctifs de bogues de sécurité, de sécurité, d’accessibilité et de fiabilité.
Dans une application existante utilisant SDK d'application Windows 1.2 (à partir du canal stable), vous pouvez mettre à jour votre package Nuget vers 1.3.0-preview1 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de packages NuGet).
Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.
API de toile de fond XAML
Avec les propriétés intégrées à la fenêtre XAML, les toiles de fond Mica et arrière-plan Acrylic sont désormais plus faciles à utiliser dans votre application WinUI 3. Pour plus d’informations sur la propriété Window.SystemBackdrop, consultez la spécification de l’API de toile de fond Xaml sur GitHub.
public MainWindow()
{
this.InitializeComponent();
this.SystemBackdrop = new MicaBackdrop();
}
Window.AppWindow
En remplaçant plusieurs lignes de code réutilisable, vous pouvez maintenant utiliser les API AppWindow directement à partir d’une fenêtre via Window.AppWindow
. Consultez la spécification de l’API Window.AppWindow sur GitHub pour obtenir des informations supplémentaires sur l’arrière-plan et l’utilisation.
Nouvelles fonctionnalités de WinAppSDK
ApplicationModel.DynamicDependency
:PackageDependency.PackageGraphRevisionId
qui remplace le MddGetGenerationId déprécié.- Gestionnaire d’environnement :
EnvironmentManager.AreChangesTracked
pour vous informer si les modifications apportées au gestionnaire d’environnement peuvent être suivies dans votre application. Pour plus d’informations, consultez la spécification de l’API Gestion de l’environnement sur GitHub. - MRT Core : un nouvel événement,
Application.ResourceManagerInitializing
, permet à votre application de fournir sa propre implémentation de l’interfaceIResourceManager
et vous donne accès à ResourceManager que WinUI utilise pour résoudre les URI de ressource. Pour plus d’informations, consultez la spécification de l’API Gestion de l’environnement sur GitHub. - Avec la dernière version expérimentale de VSIX, vous pouvez désormais convertir votre application entre les formats non empaqueté et empaqueté via le menu Visual Studio au lieu d’avoir à passer par votre fichier projet.
- Un nouvel événement,
DebugSettings.XamlResourceReferenceFailed
, est maintenant déclenché lorsqu’une recherche Static/ThemeResource référencée ne peut pas être résolue. Cet événement donne accès à une trace qui détaille l’emplacement où le cadre a recherché cette clé afin de mieux vous permettre de déboguer les échecs de recherche de Static et ThemeResource. Pour plus d’informations, consultez les spécifications API et problèmes 4972, 2350, et 6073 sur GitHub. - Déploiement : Pour gérer et réparer Windows App Runtime,
DeploymentRepairOptions
il est désormais disponible dans le cadre duDeploymentManager
. Consultez la Spécification de l’API ThemeSettings sur GitHub pour plus d’informations.
Problèmes connus
- Le contrôle pivot provoque un incident d’exécution avec une erreur d’analyse XAML. Pour plus d’informations, consultez le problème 8160 sur GitHub.
- Lorsque le menu volant DatePicker ou TimePicker est ouvert, l’application se bloque.
- Les
WindowsAppRuntime.ReleaseInfo
API introduitesWindowsAppRuntime.RuntimeInfo
dans les versions 1.3 ne sont pas encore prises en charge, car elles contiennent un bogue critique.
Version 1.2 Aperçu 2 (1.2.0-preview2)
Il s’agit de la dernière version de l’aperçu du canal pour la version 1.2.
Dans une application existante utilisant SDK d'application Windows 1.0 (à partir du canal stable), vous pouvez mettre à jour votre package Nuget vers 1.2.0-preview2 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de packages NuGet).
Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.
Important
Visual Studio 2019 et .NET 5 ne sont plus pris en charge pour la création d’applications C# (voir Passage du SDK d’application Windows 1.2 à C# WinRT 2.0). Vous aurez besoin de Visual Studio 2022 et de l’une des versions suivantes du SDK .NET : 6.0.401 (ou version ultérieure), 6.0.304 ou 6.0.109.
Pour mettre à jour votre version du SDK .NET, installez la dernière version de Visual Studio 2022 ou visitez les Téléchargements .NET. Lors de la mise à jour de votre package NuGet sans la version requise du SDK .NET, vous verrez une erreur comme : « Cette version de WindowsAppSDK nécessite .NET 6+ et WinRT.Runtime.dll version 2.0 ou ultérieure ». Pour mettre à jour le projet de .NET 5.0 vers .NET 6.0, ouvrez le fichier projet et remplacez « TargetFramework » par net6.0
et « Target OS version » par la valeur appropriée (par exemple net6.0-windows10.0.19041.0
).
Widgets tiers dans Windows
Le tableau de widgets a été introduit pour la première fois dans Windows 11 et se limitait à l’affichage des widgets intégrés. Les widgets sont de petits conteneurs d’IU qui affichent du texte et des graphiques sur le tableau de widgets, associés à une application installée sur l’appareil. Avec le SDK d'application Windows, en tant que développeurs tiers, vous pouvez désormais créer des widgets pour vos applications Win32 empaquetées et les tester localement sur le tableau de widgets Windows 11.
Pour plus d’informations sur les widgets, consultez Vue d’ensemble des widgets.
Pour commencer à développer des widgets pour votre application, consultez les documents de développement pour les fournisseurs de services de widget et les principes de base de conception de widgets pour les prérequis, des conseils et les meilleures pratiques.
Les prérequis pour cette version comprennent les suivants :
- Mode développeur activé sur l’ordinateur de développement.
- L’ordinateur de développement doit exécuter une version de Windows du canal de développement de Windows Insider Preview (WIP) avec le tableau de widgets version 521.20060.1205.0 ou ultérieure.
Limitations connues lors du développement de widgets
- Les widgets tiers ne peuvent être testés localement que sur les appareils inscrits dans WIP pour cette préversion. Dans le SDK d'application Windows 1.2.0, les utilisateurs sur les versions commerciales de Windows peuvent commencer à acquérir des widgets 3P via les versions fournies par le Microsoft Store de votre application.
- Les widgets ne peuvent être créés que pour les applications Win32 empaquetées. Les widgets pour les applications web progressives (PWA) devraient être pris en charge dans le cadre de Microsoft Edge 108.
Découpage pour les applications développées avec .NET
Les développeurs .NET peuvent désormais publier des applications WinAppSDK découpées. Avec CsWinRT 2.0, les projections C#/WinRT distribuées dans WinAppSDK sont désormais modifiables. La publication de votre application découpée peut réduire l’empreinte disque de votre application en supprimant tout code inutilisé des fichiers binaires découpables. Les applications peuvent également ainsi voir une amélioration des performances au démarrage. Avec une application Hello World de base, nous avons constaté une amélioration de l’empreinte disque d’environ 80 % et une amélioration des performances au démarrage d’environ 7 % lors de la publication de la version découpée. Avec la galerie WinUI, nous avons constaté une amélioration de l’empreinte disque d’environ 45 %.
Pour plus d’informations sur la façon d’activer le découpage, les limitations du découpage (comme la réflexion sur les types pouvant être découpés) et les avertissements de découpage, consultez Couper les déploiements et exécutables autonomes. Les développeurs doivent tester minutieusement leurs applications après le découpage pour s’assurer que tout fonctionne comme prévu. Pour plus d’informations, consultez le problème 2478 sur GitHub.
DisplayInformation
Les applications de bureau Windows peuvent désormais prendre en charge la plage dynamique étendue (HDR) via la classe DisplayInformation dans WinAppSDK. La classe DisplayInformation vous permet de surveiller les informations relatives à l’affichage d’une vue d’application. Cela inclut les événements permettant aux clients de surveiller les modifications apportées à la vue de l’application affectant les affichages sur lesquels réside la vue, ainsi que les modifications apportées aux affichages qui peuvent affecter la vue de l’application.
Correction des problèmes dans WinUI 3
- La toile de fond Acrylic avec DesktopAcrylicController est désormais prise en charge dans les applications Windows 10. Pour plus d’informations, consultez le problème 7112 sur GitHub.
- Correction du problème à l’origine de l’échec de l’acheminement d’App.UnhandledException vers l’application. Pour plus d’informations, consultez le problème 5221 sur GitHub.
- Correction d’un problème entraînant la régression et la modification des styles ListView à partir de WinAppSDK 1.1. Pour plus d’informations, consultez le problème 7666 sur GitHub.
Autres limitations et problèmes connus
Important
Lorsque vous référencez WinAppSDK 1.2 à partir d’un projet, vous pourriez voir une erreur semblable à : « Rétrogradation de package détectée : Microsoft.Windows.SDK.BuildTools de 10.0.22621.1 à 10.0.22000.194 », qui est provoquée par des références incompatibles au package du projet d’application et du package WinAppSDK. Pour résoudre ce problème, vous pouvez mettre à jour la référence dans le projet vers une version plus récente et compatible de Microsoft.Windows.SDK.BuildTools. Si vous la supprimez de votre projet, une version compatible est implicitement référencée par le package WinAppSDK.
- La construction avec Visual Studio Arm64 n'est pas prise en charge pour l’instant.
- Les valeurs par défaut de l’initialiseur automatique WinRT RegFree et Bootstrapper RegFree sont (maintenant) définies uniquement pour les projets qui produisent un exécutable (OutputType=Exe ou WinExe). Cela empêche l’ajout d’initialiseurs automatiques dans des DLL de bibliothèques de classes et d’autres fichiers non exécutables par défaut.
- Si vous avez besoin d’un initialiseur automatique dans un non-exécutable (par exemple, une DLL de test chargée par un exécutable générique qui n’initialise pas le Bootstrapper), vous pouvez activer explicitement un initialiseur automatique dans votre projet via
<WindowsAppSdkBootstrapInitialize>true</WindowsAppSdkBootstrapInitialize>
ou<WindowsAppSdkUndockedRegFreeWinRTInitialize>true</WindowsAppSdkUndockedRegFreeWinRTInitialize>
.
- Si vous avez besoin d’un initialiseur automatique dans un non-exécutable (par exemple, une DLL de test chargée par un exécutable générique qui n’initialise pas le Bootstrapper), vous pouvez activer explicitement un initialiseur automatique dans votre projet via
- Les API d’informations de version (ReleaseInfo et RuntimeInfo) peuvent être appelées, mais renvoyer la version 0 (et non les informations de version réelles).
Version 1.2 Aperçu 1 (1.2.0-preview1)
Dans une application existante utilisant SDK d'application Windows 1.0 (à partir du canal stable), vous pouvez mettre à jour votre package Nuget vers 1.2.0-preview1 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de packages NuGet).
Pour le runtime et les MSIX à jour, consultez Téléchargements pour le SDK d’application Windows.
WinUI 3
Les applications WinUI 3 peuvent lire de l’audio et de la vidéo avec les contrôles de lecture multimédia MediaPlayerElement et MediaTransportControls. Pour plus d’informations sur l’utilisation et le moment auquel utiliser des contrôles multimédias, consultez Lecteurs multimédias.
WinUI 3 a été mis à jour avec les derniers contrôles, styles et comportements de WinUI 2.8. Ces mises à jour incluent l’ajout du contrôle InfoBadge, des améliorations de l’accessibilité et du mode de contraste élevé, ainsi que des correctifs de bogues à travers les contrôles. Pour plus d’informations, consultez les notes de publication pour WinUI 2.7 et WinUI 2.8.
Problème connu
Les styles ListView ont régressé et modifiés à partir de WinAppSDK 1.1.
Notifications
AppNotificationBuilder a été introduit comme alternative à la charge utile XML pour la création et la définition de notifications d’application.
Pour plus d’informations sur son utilisation, consultez la spécification AppNotificationBuilder sur GitHub.
Consultez également Démarrage rapide : Notifications d’application dans le SDK d’application Windows pour obtenir un exemple de création d’une application Windows de bureau qui envoie et reçoit des notifications d’application locale.
Modification critique
Pour les notifications push, lors d’un appel de requête de canal, les applications doivent utiliser l’ID d’objet Azure au lieu de l’ID d’application Azure. Pour plus d’informations sur la recherche de votre ID d’objet Azure, consultez Démarrage rapide : Notification push dans le SDK d’application Windows.
Problème résolu
PushNotificationManager.IsSupported vérifie l’utilisation du mode avec élévation de privilèges. Elle retourne false
si l’application a des privilèges élevés.
Limitations connues (notifications)
- Dans AppNotificationScenario,
Urgent
est uniquement pris en charge pour les builds Windows 19041 et ultérieures. Vous pouvez utiliser AppNotificationBuilder.IsUrgentScenarioSupported pour vérifier si la fonctionnalité est disponible au moment de l’exécution. - Dans AppNotificationButton,
hint-toolTip
ethint-buttonStyle
sont uniquement pris en charge pour les builds 19041 et ultérieures. Vous pouvez utiliser IsButtonStyleSupported et IsToolTipSupported pour vérifier si la fonctionnalité est disponible au moment de l’exécution. - Dans MediaPlayerElement, lorsqu’elle est utilisée dans le balisage XAML pour une application non empaquetée, la propriété Source ne peut pas être définie avec un URI ms-appx ou ms-resource. Vous pouvez également définir la source à l’aide d’un URI de fichier ou à partir du code.
Fenêtrage
La personnalisation complète de la barre de titre est désormais disponible sur Windows 10, version 1809 et versions ultérieures via la classe AppWindowTitleBar. Vous pouvez définir AppWindowTitleBar.ExtendsContentIntoTitleBar sur true
pour étendre le contenu dans la zone de barre de titre, et SetDragRectangles pour définir des régions de glissement (en plus d’autres options de personnalisation).
Si vous avez utilisé la propriété AppWindowTitleBar.IsCustomizationSupported pour vérifier si vous pouvez appeler les API AppWindowTitleBar, elle retourne désormais true
sur les versions du SDK d’application Windows pour Windows 10 prises en charge (1809 et versions ultérieures).
Limitations connues (fenêtrage)
Les personnalisations de base de la barre de titre ne sont pas prises en charge sur Windows 10. Cela comprend BackgroundColor, InactiveBackgroundColor, ForegroundColor, InactiveForegroundColor et IconShowOptions. Si vous appelez ces propriétés, elles seront ignorées sans avertissement. Toutes les autres API AppWindowTitleBar fonctionnent dans Windows 10, version 1809 et versions ultérieures. Pour les API de couleur de bouton de légende (entre autres) et Height, ExtendsContentIntoTitleBar doit avoir la valeur true
, sinon ces valeurs seront également ignorées sans avertissement.
Contrôle d’accès
Introduction de security.accesscontrol.h avec la fonction GetSecurityDescriptorForAppContainerNames pour faciliter et simplifier le partage d’objets nommés entre les processus empaquetés et les API Win32 générales. Cette méthode prend une liste de noms de famille de packages (PFN) et de masques d’accès, puis retourne un descripteur de sécurité. Pour plus d’informations, consultez la spécification GetSecurityDescriptorForAppContainerNames sur GitHub.
Autres limitations et problèmes connus
- PublishSingleFile .NET n’est pas pris en charge.
Version 1.1 Aperçu 3 (1.1.0-preview3)
Il s’agit de la dernière version de l’aperçu du canal pour la version 1.1. Il prend en charge tous les aperçus fonctionnalités du canal (consultez Fonctionnalités disponibles par canal de publication).
Dans une application existante utilisant SDK d'application Windows 1.0, vous pouvez mettre à jour votre package Nuget vers 1.1.0-preview3 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de packages NuGet). De plus, consultez Téléchargements pour le SDK d’application Windows pour le runtime mis à jour et MSIX.
Remarque
Pour les développeurs C#, l’une des versions suivantes du SDK .NET est requise : 6.0.202, 6.0.104, 5.0.407, 5.0.213 (ou version ultérieure). Pour mettre à jour votre version du SDK .NET, consultez Téléchargements .NET ou mettez à jour vers la dernière version de Visual Studio. Sans la version requise du SDK .NET, lors de la mise à jour de votre package NuGet, vous verrez une erreur du type : « Cette version de WindowsAppSDK nécessite WinRT.Runtime.dll version 1.6 ou ultérieure ».
En plus de toutes les fonctionnalités de l'aperçu 2, les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour cette version.
WinUI 3
Mica et Acrylic sont désormais disponibles pour les applications WinUI 3.
Pour plus d’informations sur ces matériaux, consultez Matériaux dans Windows 11. Consultez notre exemple de code pour l’application de Mica dans les applications C++ à la page Utilisation de SystemBackdropController avec WinUI 3 XAML et dans les applications C# sur GitHub dans le cadre de la Galerie WinUI 3.
Notifications
Problèmes résolus :
- Dans la version 1.1.0-preview1 et 1.1.0-preview2, certaines applications non empaquetées ont vu leurs icônes d’application correctement copiées dans AppData\LocalMicrosoftWindowsAppSDK. Pour cette version, ils seront copiés vers AppData\Local\Microsoft\WindowsAppSDK à la place. Pour éviter les fuites d’icônes, vous devez supprimer manuellement l’icône de l’application sur le chemin incorrect après la mise à jour vers la version 1.1.0-preview3.
- L’icône d’application et la récupération du nom d’affichage de l’application pour les notifications d’application via les raccourcis sont désormais pris en charge. Cette icône d’application sera hiérarchisée par rapport à n’importe quelle icône spécifiée dans les fichiers de ressources.
- La prise en charge des notifications Push pour les applications non empaquetées a été restaurée (voir Limitations pour l’exception notée). Nous avons introduit l’API PushNotificationManager ::IsSupported pour case activée si votre application prend en charge les notifications Push.
Limitations :
- Les notifications pour une application élevée non empaquetée ne sont pas prises en charge. PushNotificationManager.IsSupported vérifie l’utilisation du mode avec élévation de privilèges. Toutefois, nous travaillons à la prise en charge de cette version ultérieure.
Création de packages MSIX
Nous avons amélioré MSIX en ajoutant de nouvelles fonctionnalités existantes et en étendant les fonctionnalités existantes via les catégories d’extensions :
- windows.appExecutionAlias
- windows.customDesktopEventLog
- windows.dataShortcuts
- windows.fileTypeAssociation
- windows.fileTypeAssociation.iconHandler
- windows.folder
- windows.shortcut
Celles-ci nécessitent l’installation du package de framework du SDK d’application Windows. Consultez Téléchargements pour le SDK d’application Windows pour installer le runtime.
Responsable environnement
Ensemble d’API qui permet aux développeurs d’ajouter, de supprimer et de modifier des variables d’environnement sans avoir à utiliser directement l’API de Registre.
Clarification de la version 1.1 Preview 1 : suppression automatique de toutes les modifications de variable d’environnement lorsqu’une application qui a utilisé le gestionnaire d’environnement est désinstallée est disponible uniquement pour les applications empaquetées. En outre, la restauration des modifications des variables d’environnement nécessite l’installation du package d’infrastructure du Kit de développement logiciel (SDK) d’application Windows, consultez Téléchargements pour le Kit de développement logiciel (SDK) d’application Windows pour le runtime.
Autres limitations connues
Régressions de la version 1.1 Aperçu 2 :
- Pour les applications .NET utilisant des API MRT Core et des applications WinUI qui ne sont pas déployées avec MSIX à projet unique :
- Les fichiers RESW et image ajoutés au projet en tant qu’éléments existants et précédemment inclus automatiquement dans les groupes d’éléments PRIResource et Content ItemGroups, respectivement, ne seront pas inclus dans ces ItemGroups. Par conséquent, ces ressources ne seront pas indexées pendant la génération IRP. Elles ne seront donc pas disponibles pendant l’exécution.
- Solution de contournement : incluez manuellement les ressources dans le fichier projet et supprimez-les du ItemGroup None.
- Solution de contournement alternative : quand elle est disponible, mettez à niveau le Kit de développement logiciel (SDK) .NET de vos applications vers la version 6.0.300. Pour plus d’informations, consultez la configuration requise pour le Kit de développement logiciel (SDK) .NET.
- Les fichiers RESW et image ajoutés au projet en tant qu’éléments existants et précédemment inclus automatiquement dans les groupes d’éléments PRIResource et Content ItemGroups, respectivement, ne seront pas inclus dans ces ItemGroups. Par conséquent, ces ressources ne seront pas indexées pendant la génération IRP. Elles ne seront donc pas disponibles pendant l’exécution.
- Pour les applications .NET qui ne sont pas déployées avec MSIX à projet unique :
- Si un fichier est ajouté au Content ItemGroup deux fois ou plus, une erreur de build s’affiche.
- Solution de contournement : supprimez l’inclusion/s dupliquée ou définissez EnableDefaultContentItems sur false dans le fichier projet.
- Si un fichier est ajouté au Content ItemGroup deux fois ou plus, une erreur de build s’affiche.
Les deux régressions seront restaurées dans la prochaine version stable.
Version 1.1 Aperçu 2 (1.1.0-preview2)
Il s’agit de la deuxième version du canal de préversion pour la version 1.1. Il prend en charge tous les aperçus fonctionnalités du canal (consultez Fonctionnalités disponibles par canal de publication).
Dans une application existante utilisant SDK d'application Windows 1.0, vous pouvez mettre à jour votre package Nuget vers 1.1.0-preview2 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de packages NuGet). De plus, consultez Téléchargements pour le SDK d’application Windows pour le runtime mis à jour et MSIX.
Remarque
Pour les développeurs C#, l’une des versions suivantes du SDK .NET est requise : 6.0.202, 6.0.104, 5.0.407, 5.0.213 (ou version ultérieure). Pour mettre à jour votre version du SDK .NET, consultez Téléchargements .NET ou mettez à jour vers la dernière version de Visual Studio. Sans la version requise du SDK .NET, lors de la mise à jour de votre package NuGet, vous verrez une erreur du type : « Cette version de WindowsAppSDK nécessite WinRT.Runtime.dll version 1.6 ou ultérieure ».
En plus de toutes les fonctionnalités de l'aperçu 1, les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour cette version.
Notifications
Problèmes résolus :
- Une application sans identité de package qui envoie des notifications voit désormais son icône d’application dans la notification si l’icône fait partie de la ressource de l’application. Si la ressource d’application n’a pas d’icône, l’icône d’application par défaut Windows est utilisée.
- Une application WinUI 3 qui n’est pas en cours d’exécution peut désormais être activée en arrière-plan via une notification.
Régression de la version 1.1 Preview 1 : prise en charge des notifications Push pour les applications non empaquetées. On s’attend à ce qu’elle soit restaurée dans la prochaine version.
Limitations connues :
- Nous avons introduit l’API PushNotificationManager ::IsSupported pour case activée si les applications autonomes prennent en charge les notifications Push. Toutefois, cette API ne fonctionne pas encore comme prévu. Gardez donc un œil dans la prochaine préversion pour obtenir une prise en charge complète de l’API IsSupported.
- Certaines applications non empaquetées verront leurs icônes d’application copiées incorrectement dans AppData\LocalMicrosoftWindowsAppSDK. Pour la prochaine version, ils seront copiés vers AppData\Local\Microsoft\WindowsAppSDK à la place. Pour éviter les fuites d’icônes, le développeur doit supprimer manuellement son icône d’application au chemin incorrect après la mise à niveau vers la prochaine version.
- L’icône d’application et la récupération du nom d’affichage de l’application pour les notifications via les raccourcis n’est pas prise en charge. Mais nous travaillons à la prise en charge de cela dans une prochaine version.
Déploiement
Nouvelles fonctionnalités :
- Les applications empaquetées peuvent désormais forcer le déploiement des packages d’exécution du Kit de développement logiciel (SDK) d’application Windows à l’aide de l’API DeploymentManager.Initialize.
- L’API Bootstrapper requise pour les applications qui ne se déploient pas avec MSIX inclut de nouvelles options pour améliorer la facilité d’utilisation et la résolution des problèmes. Pour plus d’informations, consultez Utiliser le runtime du SDK d'application Windows pour les applications empaquetées avec un emplacement externe ou non empaquetées et riches informations sur la défaillance de l'initalisation de l’amorçage.
Limitations connues :
- Le déploiement autonome est pris en charge uniquement sur Windows 10, 1903 et versions ultérieures.
Fenêtrage
Pour faciliter la programmation de l’accès aux fonctionnalités implémentées dans USER32.dll
(consultez Fenêtres et messages), cette version fait apparaître une plus grande partie de ces fonctionnalités dans AppWindow lui-même.
Nouvelles fonctionnalités :
- Les applications avec des fenêtres existantes ont plus de contrôle sur la façon dont une fenêtre est affichée, en appelant AppWindow.ShowOnceWithRequestedStartupState, l’équivalent de
ShowWindow(SW_SHOWDEFAULT)
. - Les applications peuvent afficher, réduire ou restaurer une fenêtre tout en spécifiant si la fenêtre doit être activée ou non au moment où l’appel est effectué.
- Les applications peuvent désormais définir la taille de la zone cliente d’une fenêtre dans les coordonnées Win32.
- Nous avons ajouté des API pour prendre en charge la gestion z-order des fenêtres.
- Les applications dessinant des barres de titre personnalisées avec AppWindowTitleBar.ExtendsContentIntoTitleBar peuvent définir une option PreferredTitleBarHeight. Vous avez le choix entre une barre de titre de hauteur standard et une barre de titre haute qui laisse plus de place au contenu interactif. Consultez Barre de titre dans les instructions de conception Fluent pour obtenir des conseils sur l’utilisation d’une barre de titre haute.
Limitations connues :
- La prise en charge de la barre de titre de grande taille est disponible uniquement sur Windows 11. Nous travaillons à réduire ce niveau avec d’autres API de barre de titres personnalisées.
WinUI 3
Problèmes résolus :
- Résolution d’un problème entraînant le blocage des applications C# avec WebView2 au lancement lorsque le runtime C/C++ (CRT) n’était pas installé en mettant à niveau le SDK WebView2 de la version 1020.46 vers la version 1185.39.
- Correction d’un problème entraînant l’affichage d’un dégradé dans certains coins arrondis alors qu’ils devaient être de couleur unie. Pour plus d’informations, consultez les problèmes 6076 et problèmes 6194 sur GitHub.
- Correction d’un problème où les styles mis à jour étaient manquants dans generic.xaml.
- Correction d’un problème de cycle de disposition provoquant le blocage d’une application lors du défilement jusqu’à la fin d’un contrôle ListView. Pour plus d’informations, consultez le problème 6218 sur GitHub.
Performances
Les applications C# ont plusieurs améliorations de performances. Pour plus d’informations, consultez les notes de publication C#/WinRT 1.6.1.
Version 1.1 Aperçu 1 (1.1.0-preview1)
Il s’agit de la première version du canal de préversion pour la version 1.1. Il prend en charge tous les aperçus fonctionnalités du canal (consultez Fonctionnalités disponibles par canal de publication).
Dans une application existante utilisant SDK d'application Windows 1.0, vous pouvez mettre à jour votre package Nuget vers 1.1.0-preview1 (consultez la section Mettre à jour un package dans Installer et gérer des packages dans Visual Studio à l'aide du gestionnaire de packages NuGet). De plus, consultez Téléchargements pour le SDK d’application Windows pour le runtime mis à jour et MSIX.
Les sections suivantes décrivent les fonctionnalités nouvelles et mises à jour, les limitations et les problèmes connus pour cette version.
WinUI 3
Problème connu : les utilisateurs ne parviennent pas à déposer un élément lorsque la fonction « glisser-déposer » est activée.
Prise en charge élevée (administrateur)
À l’aide du Kit de développement logiciel (SDK) d’application Windows 1.1 Preview 1, les applications (y compris WinUI 3) peuvent s’exécuter avec des privilèges élevés.
Limitations importantes
- Disponible uniquement sur Windows 11 Mais nous évaluons la mise en place de cette prise en charge dans une version ultérieure.
Problèmes connus
- Les applications WinUI 3 avec élévation de privilèges se bloquent lors du glissement d’un élément lors d’une interaction glisser-déplacer.
Déploiement autonome
Le Kit de développement logiciel (SDK) d’application Windows 1.1 introduit la prise en charge du déploiement autonome. Consultez la Vue d’ensemble du déploiement du SDK d’application Windows pour connaître les différences entre le déploiement autonome et dépendant du framework, et découvrir comment commencer.
Problèmes connus :
Une application C++ empaquetée doit ajouter les éléments ci-dessous au bas de son fichier projet pour contourner un bogue dans le fichier autonome
.targets
qui supprime les références d’infrastructure à VCLibs :<PropertyGroup> <IncludeGetResolvedSDKReferences>true</IncludeGetResolvedSDKReferences> </PropertyGroup> <Target Name="_RemoveFrameworkReferences" BeforeTargets="_ConvertItems;_CalculateInputsForGenerateCurrentProjectAppxManifest"> <ItemGroup> <FrameworkSdkReference Remove="@(FrameworkSdkReference)" Condition="'%(FrameworkSdkReference.SDKName)' == 'Microsoft.WindowsAppRuntime.1.1-preview1'" /> </ItemGroup> </Target>
Pris en charge uniquement sur Windows 10, 1903 et les versions ultérieures.
Notifications
Les développeurs d’applications empaquetées (y compris empaquetées avec un emplacement externe) et non empaquetées peuvent désormais envoyer des notifications Windows.
Nouvelles fonctionnalités :
- Prise en charge des notifications d’application pour les applications empaquetées et non empaquetées. Détails complets sur GitHub
- Les développeurs peuvent envoyer des notifications d’application, également appelées notifications toast, localement ou à partir de leur propre service cloud.
- Prise en charge des notifications push pour les applications empaquetées et non empaquetées. Détails complets sur GitHub
- Les développeurs peuvent envoyer des notifications brutes et des notifications d’application à partir de leur propre service cloud.
Limitations :
- Les applications publiées en tant qu’autonomes peuvent ne pas prendre en charge les notifications Push. Gardez un œil dans la prochaine préversion d’une API IsSupported pour case activée pour la prise en charge des notifications Push.
- Les applications qui ne sont pas empaquetées envoyant des notifications d’application ne voient pas leur icône d’application dans la notification de l’application, sauf si elles sont des applications console. Les applications console qui ne sont pas empaquetées doivent suivre les modèles indiqués dans l’exemple ToastNotificationsDemoApp.
- Le runtime du Kit de développement logiciel (SDK) d’application Windows doit être installé pour prendre en charge les notifications Push, consultez Téléchargements pour le Kit de développement logiciel (SDK) d’application Windows pour le programme d’installation.
- Une application WinUI 3 qui n’est pas en cours d’exécution ne peut pas être activée en arrière-plan via une notification. Mais nous travaillons à la prise en charge de cela dans une prochaine version.
Responsable environnement
Ensemble d’API qui permet aux développeurs d’ajouter, de supprimer et de modifier des variables d’environnement sans avoir à utiliser directement l’API de Registre.
Nouvelles fonctionnalités
- Fournit la suppression automatique de toutes les variables d’environnement modifiées lorsqu’une application qui a utilisé le gestionnaire d’environnement est désinstallée.
Limitations
- Actuellement indisponible dans les applications C#. Mais nous évaluons l’ajout de cette fonctionnalité aux applications C# dans une version ultérieure.
Autres limitations et problèmes connus
- Si vous utilisez C# avec la version 1.1.0 Preview 1, vous devez utiliser l’une des versions suivantes du SDK .NET au minimum : .NET SDK 6.0.201, 6.0.103, 5.0.212 ou 5.0.406. Pour mettre à jour votre version du SDK .NET, consultez Téléchargements .NET ou mettez à jour vers la dernière version de Visual Studio.
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. Consultez Téléchargements pour le 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
Nous prenons désormais en charge le déploiement d’applications WinUI 3 sans empaquetage MSIX. Consultez Créer votre premier projet WinUI 3 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 :
- ApplicationData
- StorageFile.GetFileFromApplicationUriAsync
- ApiInformation (non pris en charge sur Windows 10)
- Package.Current
- 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.
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
ouarm64
.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) :
- Ajoutez une référence à votre projet au package NuGet Microsoft.Windows.ImplementationLibrary .
- Ajoutez
#include <wil/cppwinrt_helpers.h>
à votrepch.h
. - Ajoutez
#include <winrt/Microsoft.UI.Dispatching.h>
à votrepch.h
. - 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 :
- SDK d'application Windows 1.0 Aperçu 1 (1.0.0-preview1)
- SDK d'application Windows 1.0 Aperçu 2 (1.0.0-preview2)
Atténuation
Pour ramener votre machine dans un bon état, procédez comme suit :
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 }
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).
Désinstallez les packages Windows App SDK 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
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 :
Fenêtrage
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 maintenantvoid
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, consultez Gérer les fenêtres d’application.
Input
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
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 :
- Windows App SDK 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
- Applications non empaquetées : entièrement utilisables.
- Applications empaquetées : utilisables, mais ces applications peuvent également utiliser la plateforme
GetActivatedEventArgs
. Notez que la plateforme définit Windows.ApplicationModel.AppInstance tandis que le SDK d’application Windows définit Microsoft.Windows.AppLifecycle.AppInstance. Et bien que les applications UWP puissent utiliser les classesActivatedEventArgs
, commeFileActivatedEventArgs
etLaunchActivatedEventArgs
, les applications qui utilisent la fonctionnalité AppLifecycle du SDK d’application Windows doivent utiliser les interfaces et non les classes (par exempleIFileActivatedEventArgs
,ILaunchActivatedEventArgs
, et ainsi de suite). - Applications WinUi : App.OnLaunched de WinUI reçoit Microsoft.UI.Xaml.LaunchActivatedEventArgs, tandis que la plateforme
GetActivatedEventArgs
renvoie Windows.ApplicationModel.IActivatedEventArgs et queGetActivatedEventArgs
de WindowsAppSDK renvoie un objet Microsoft.Windows.AppLifecycle.AppActivationArguments qui peut représenterLaunchActivatedEventArgs
pour une plateforme. - Pour plus d’informations, consultez Activation enrichie.
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, consultez Activation enrichie.
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, voir Instanciation d’application.
Notifications d’alimentation/état
- Applications non empaquetées : entièrement utilisables.
- Applications empaquetées : entièrement utilisables.
- Pour plus d’informations, consultez Gestion de l’alimentation.
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.
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
ouarm64
.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) :
- Ajoutez une référence à votre projet au package NuGet Microsoft.Windows.ImplementationLibrary .
- Ajoutez
#include <wil/cppwinrt_helpers.h>
à votrepch.h
. - Ajoutez
#include <winrt/Microsoft.UI.Dispatching.h>
à votrepch.h
. - 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
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 :
Fenêtrage
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, consultez Gérer les fenêtres d’application.
Input
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’objetCoreCursor
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
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) :
- Ajoutez une référence à votre projet au package NuGet Microsoft.Windows.ImplementationLibrary .
- Ajoutez
#include <wil/cppwinrt_helpers.h>
à votrepch.h
. - Ajoutez
#include <winrt/Microsoft.UI.Dispatching.h>
à votrepch.h
. - 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
ouarm64
.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.
Rubriques connexes
Windows developer
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : tout au long de 2024, nous allons éliminer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d'informations, consultez :Envoyer et afficher des commentaires pour