API Windows Runtime non prises en charge dans les applications de bureau

  • Article

Bien que vous puissiez utiliser la plupart des API Windows Runtime (WinRT) (voir espaces de noms Windows UWP) dans votre application de bureau C# ou C++, il existe deux ensembles principaux d’API WinRT qui ne sont pas pris en charge dans des 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 par le biais d’interfaces COM WinRT qui sont disponibles dans le SDK Windows.

Notes

Les applications utilisant .NET peuvent utiliser les implémentations de classes fournies pour certaines des interfaces COM WinRT listé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.

Cet article sera mis à jour à mesure que des solutions de contournement seront trouvées et que des remplacements seront effectués. Si vous rencontrez un problème avec une API qui n’est pas listée ici, signalez un problème dans le dépôt microsoft-ui-xaml avec le nom de l’API et les détails sur l’usage que vous souhaitez en faire.

Les API qui ont des dépendances à des fonctionnalités de l’interface utilisateur pour UWP uniquement

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.

Principales classes non prises en charge

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

Classe Autres API
ApplicationView Aucun
CoreApplicationView Utilisez à la place la classe Window qui est fournie par WinUI 3.
CoreApplicationViewTitleBar À la place de la propriété ExtendViewIntoTitleBar, utilisez la propriété Window.ExtendsContentIntoTitleBar qui est fournie par WinUI 3.
CoreDispatcher Utilisez plutôt la propriété Microsoft.UI.Xaml.Window.DispatcherQueue qui est fournie par WinUI 3.

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 qui est fournie par WinUI 3.

Au lieu de la propriété PointerCursor, utilisez la propriété UIElement.ProtectedCursor qui est fournie par WinUI 3. 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 retourneront null, mais elles lèveront également des exceptions.

Notes

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 changements apportés à l’événement XamlRoot.Changed (la propriété XamlRoot.RasterizationScale est fournie dans WinUI 3).

Et, à la place de la propriété RawPixelsPerViewPixel, vous avez le choix d’utiliser la propriété XamlRoot.RasterizationScale qui est fournie par WinUI 3.
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 Aucun
BrightnessOverride Aucun
ConnectedAnimationService Aucun
CoreInputView Aucun
CoreWindowResizeManager Aucun
DisplayEnhancementOverride Aucun
EdgeGesture Aucun
GazeInputSourcePreview Aucun
HdmiDisplayInformation Aucun
HolographicKeyboardPlacementOverridePreview Aucun
KeyboardDeliveryInterceptor Aucun
LockApplicationHost Aucun
MouseDevice Aucun
PointerVisualizationSettings Aucun
ProtectionPolicyManager Aucun
SearchPane Aucun
SettingsPane Aucun
SystemNavigationManager Aucun
SystemNavigationManagerPreview Aucun
WebAuthenticationBroker Aucune. Pour plus d’informations, consultez le problème GitHub WebAuthenticationBroker.AuthenticateAsync lève 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, qui est en général utilisé pour afficher une IU. 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 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
AccessibilitySettings 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 modèle 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.

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.