Prise en charge des API Windows Runtime dans les applications de bureau

Bien que vous puissiez utiliser la plupart des API Windows Runtime (WinRT) (voir Windows Runtime (WinRT) espaces de noms) dans votre application de bureau C# ou C++, il existe deux ensembles principaux d'API WinRT qui ne sont pas pris en charge dans les applications de bureau, ou qui ont des restrictions :

  • API qui ont des dépendances sur les fonctionnalités d’interface utilisateur conçues pour une utilisation uniquement dans une application Plateforme Windows universelle (UWP).
  • API qui nécessitent une identité de package (voir Fonctionnalités qui nécessitent une identité de package). Ces API sont uniquement prises en charge dans les applications de bureau packagées à l’aide de MSIX.

Cet article fournit des détails sur ces deux ensembles d’API WinRT. Le cas échéant, cet article suggère d’autres API qui permettent d’obtenir les mêmes fonctionnalités que les API non prises en charge sur des applications de bureau. La plupart des AUTRES API sont disponibles dans WinUI 3 ou via des interfaces COM WinRT disponibles dans le Kit de développement logiciel (SDK) Windows.

Note

Les applications qui utilisent .NET peuvent utiliser des implémentations de classes fournies pour certaines interfaces COM WinRT répertoriées dans cet article. Ces classes sont plus faciles à utiliser que les interfaces COM WinRT en mode direct. Pour plus d’informations sur les implémentations de classes disponibles, consultez Appeler des API d’interopérabilité à partir d’une application .NET. Notez que ces classes nécessitent le SDK .NET 6 ou ultérieur.

Les API qui dépendent uniquement de fonctionnalités de l'interface utilisateur UWP.

Certaines API WinRT ont été conçues spécifiquement pour des scénarios d’interface utilisateur d’une application UWP. Ces API ne se comportent pas correctement dans les applications de bureau en raison des modèles de thread et d’autres différences de plateforme. Ces API, ainsi que d’autres API WinRT qui ont des dépendances, ne peuvent pas être utilisées dans les applications de bureau.

Classes fondamentales non prises en charge

Ces classes WinRT ne sont pas prises en charge dans les applications de bureau :

Classe Autres API
ApplicationView None
CoreApplicationView Utilisez plutôt la classe Window fournie par WinUI.
CoreApplicationViewTitleBar Au lieu de la propriété ExtendViewIntoTitleBar , utilisez la propriété Window.ExtendsContentIntoTitleBar fournie par WinUI.
CoreDispatcher Utilisez la propriété Microsoft.UI.Xaml.Window.DispatcherQueue fournie par WinUI à la place.

Notez que les propriétés Windows.UI.Xaml.Window.Dispatcher et Windows.UI.Xaml.DependencyObject.Dispatcher retournent null dans les applications de bureau.
CoreWindow Consultez également la section Classes qui implémentent IInitializeWithWindow ci-dessous.

Au lieu de la méthode GetKeyState , utilisez la méthode InputKeyboardSource.GetKeyStateForCurrentThread fournie par WinUI.

Au lieu de la propriété PointerCursor , utilisez la propriété UIElement.ProtectedCursor fournie par WinUI. Vous devez disposer d’une sous-classe de UIElement pour accéder à cette propriété.
UserActivity Utilisez l’interface COM IUserActivitySourceHostInterop à la place (dans useractivityinterop.h).

Pour les autres API WinRT qui ne sont pas prises en charge dans les applications de bureau, consultez Membres non pris en charge plus loin dans cette rubrique.

Classes avec une méthode XxxForCurrentView

De nombreuses classes WinRT ont une méthode GetForCurrentView ou CreateForCurrentView statique, comme UIViewSettings.GetForCurrentView. Ces méthodes XxxForCurrentView ont une dépendance implicite au type ApplicationView, qui n’est pas prise en charge dans les applications de bureau. Comme ApplicationView n’est pas prise en charge dans les applications de bureau, aucune des méthodes XxxForCurrentView n’est prise en charge. Certaines méthodes XxxForCurrentView non prises en charge ne retournent pas seulement null, mais lèvent aussi des exceptions.

Note

CoreInputView.GetForCurrentViewest pris en charge dans des applications de bureau et peut être utilisé même sans CoreWindow. Vous pouvez utiliser cette méthode pour obtenir un objet CoreInputView dans n’importe quel thread. Si ce thread a une fenêtre de premier plan, l’objet produira des événements.

Les classes suivantes sont prises en charge dans les applications de bureau. Toutefois, pour récupérer une instance dans une application de bureau, vous utilisez un mécanisme différent des méthodes GetForCurrentView ou CreateForCurrentView. Pour les classes suivantes qui disposent d’une interface COM comme API de rechange, les développeurs C# peuvent aussi consommer ces interfaces COM WinRT COM (consultez Appeler des API interop depuis une application .NET). Il est possible que cette liste ne soit pas exhaustive.

Classe Autres API
AccountsSettingsPane Utilisez l’interface COM IAccountsSettingsPaneInterop à la place (dans accountssettingspaneinterop.h).
CoreDragDropManager Utilisez l’interface COM IDragDropManagerInterop à la place (dans dragdropinterop.h).
CoreTextServicesManager Cette classe est prise en charge par les applications de bureau uniquement dans les versions d’évaluation de Windows Insider.
DataTransferManager Utilisez l’interface COM IDataTransferManagerInterop à la place (dans shobjidl_core.h).
DisplayInformation Pour récupérer une instance de DisplayInformation, utilisez l’interface IDisplayInformationStaticsInterop.

Sinon, au lieu de la propriété LogicalDpi , vous pouvez utiliser la propriété XamlRoot.RasterizationScale et écouter les modifications via l’événement XamlRoot.Changed (la propriété XamlRoot.RasterizationScale est fournie dans WinUI).

Et, au lieu de la propriété RawPixelsPerViewPixel , vous avez la possibilité d’utiliser la propriété XamlRoot.RasterizationScale fournie par WinUI.
InputPane Utilisez l’interface COM IInputPaneInterop à la place (dans inputpaneinterop.h).
PlayToManager Utilisez l’interface COM IPlayToManagerInterop à la place (dans playtomanagerinterop.h).
Print3DManager Utilisez l’interface COM IPrinting3DManagerInterop à la place (dans print3dmanagerinterop.h).
PrintManager Utilisez l’interface COM IPrintManagerInterop à la place (dans printmanagerinterop.h).
RadialController Utilisez l’interface COM IRadialControllerInterop à la place (dans radialcontrollerinterop.h).
RadialControllerConfiguration Utilisez l’interface COM IRadialControllerConfigurationInterop à la place (dans radialcontrollerinterop.h).
ResourceContext Voir Migration de MRT vers MRT Core.
ResourceLoader Voir Migration de MRT vers MRT Core.
SpatialInteractionManager Utilisez l’interface COM ISpatialInteractionManagerInterop à la place (dans spatialinteractionmanagerinterop.h).
SystemMediaTransportControls Utilisez l’interface COM ISystemMediaTransportControlsInterop à la place (dans systemmediatransportcontrolsinterop.h).
UserActivityRequestManager Utilisez l’interface COM IUserActivityRequestManagerInterop à la place (dans useractivityinterop.h).
UIViewSettings Utilisez l’interface COM IUIViewSettingsInterop à la place (dans uiviewsettingsinterop.h).

Les classes suivantes ne sont pas prises en charge dans les applications de bureau, car les API ne fournissent pas d’alternative à la méthode GetForCurrentView ou CreateForCurrentView. Il est possible que cette liste ne soit pas exhaustive.

Classe Autres API
AppCapture None
BrightnessOverride None
ConnectedAnimationService None
CoreInputView None
CoreWindowResizeManager None
DisplayEnhancementOverride None
EdgeGesture None
GazeInputSourcePreview None
HdmiDisplayInformation None
HolographicKeyboardPlacementOverridePreview None
KeyboardDeliveryInterceptor None
LockApplicationHost None
MouseDevice None
PointerVisualizationSettings None
ProtectionPolicyManager None
SearchPane None
SettingsPane None
SystemNavigationManager None
SystemNavigationManagerPreview None
WebAuthenticationBroker Aucun. Pour plus d’informations, consultez le problème GitHub WebAuthenticationBroker.AuthenticateAsync génère COMException.

Classes qui implémentent IInitializeWithWindow

Certains sélecteurs, fenêtres contextuelles, boîtes de dialogue et autres objets Windows Runtime (WinRT) dépendent d’un CoreWindow ; généralement pour afficher une interface utilisateur. CoreWindow n’est pas pris en charge dans les applications de bureau (voir Principales classes non prises en charge ci-dessus), mais vous pouvez toujours utiliser un grand nombre de ces classes WinRT dans votre application de bureau en ajoutant quelques lignes de code d’interopérabilité.

Pour plus d’informations (y compris une liste des types concernés) et obtenir des exemples de code, consultez Afficher les objets d’interface utilisateur WinRT qui dépendent de CoreWindow.

Membres non pris en charge

Cette section liste (ou décrit, lorsqu’il n’est pas possible de fournir une liste complète) les membres spécifiques de classes WinRT qui ne sont pas pris en charge dans les applications de bureau. Sauf indication contraire, hormis ces membres, les autres classes sont prises en charge par les applications de bureau.

Événements

Les classes suivantes sont prises en charge dans les applications de bureau, à l’exception des événements spécifiés.

Classe Événements non pris en charge
UISettings ColorValuesChanged
Paramètresd'accessibilité HighContrastChanged

Méthodes

Les classes suivantes sont prises en charge dans les applications de bureau, à l’exception des méthodes spécifiées.

Classe Méthodes non prises en charge
DeviceInformationPairing PairAsync

Méthodes qui utilisent le schéma de nommage Request

La plupart des méthodes qui suivent le modèle de nommage Request, comme AppCapability.RequestAccessAsync et StoreContext.RequestPurchaseAsync, ne sont pas prises en charge dans les applications de bureau. En interne, ces méthodes utilisent la classe Windows.UI.Popups. Cette classe exige que le thread ait un objet CoreWindow, qui n’est pas pris en charge dans les applications de bureau.

La liste complète des méthodes qui suivent le modèle de nommage Request est trop longue pour être mentionnée en entier dans cet article.

API nécessitant l’identité du package

Les classes WinRT suivantes nécessitent une identité de package (voir Fonctionnalités qui nécessitent une identité de package). Ces API sont prises en charge uniquement dans les applications de bureau qui sont packagées (autrement dit, qui ont une identité de package au moment de l’exécution). Il est possible que cette liste ne soit pas exhaustive.

Windows. ApplicationModel...

Windows.Data...

Windows. Dispositifs...

Windows. Fondation...

Windows. Mondialisation...

Windows.Graphics...

Windows.Management...

Windows.Media

Windows. Mise en réseau...

Windows.Services.Maps...

Important

API de plateforme Cartes Windows (Windows. Services.Maps.*) sont déconseillés et peuvent ne pas être disponibles dans les versions ultérieures de Windows. Pour plus d’informations, consultez Ressources pour les fonctionnalités déconseillées.

Windows.Services.Store...

Windows. Stockage...

Windows. Système...

Windows.UI...

En outre, lorsqu’elles sont appelées à partir d’une application de bureau qui n’a pas d’identité de package, les méthodes AdaptiveMediaSource.CreateFromUriAsync ne prennent pas en charge les formats d’URI ms-appx et ms-resource.

  • Last updated on