Mode serveur

Le mode serveur MTP permet à un éditeur, à l’IDE ou à un autre outil de test de lancer une application de test et de générer la découverte et l’exécution via JSON-RPC. Utilisez le mode serveur lorsque vous générez des outils autour de MTP. Pour les exécutions de ligne de commande et ci normales, exécutez l’application de test directement ou utilisez dotnet test.

Démarrez le serveur JSON-RPC public avec --server ou --server jsonrpc.

Important

Le sdk .NET utilise un protocole binaire interne distinct via --server dotnettestcli. Ne transmettez pas cette valeur vous-même. dotnet test configure les arguments de transport et de protocole.

Utiliser le client source uniquement

MTP 2.4 fournit un client de JSON-RPC canonique. Ajoutez le package Microsoft.Testing.Platform.ServerMode.Client.Sources. Le package injecte la source C# dans votre projet au lieu d’ajouter un assembly runtime.

La conception basée uniquement sur le code source comprend :

  • Aucune DLL d’exécution ni dépendance de déploiement supplémentaire.
  • Sérialisation native, compatible AOT et sans réflexion.
  • Types de protocole et code de sérialisation à partir du même référentiel que le serveur MTP.

Les types injectés MtpServerClient, IMtpServerClient et de protocole peuvent initialiser une connexion, découvrir des tests, exécuter des tests, demander l’arrêt du serveur et signaler des mises à jour des nœuds de test. Tous les types injectés restent internal pour l’assembly qui les consomme.

Répondre aux exigences du client

Utilisez C# 12 ou version ultérieure. Le package logiciel respecte le paramètre de version du langage de votre projet. Si votre framework cible est défini par défaut sur une version C# antérieure, définissez LangVersion sur 12.0 ou une version ultérieure. Le package fournit également des types de compatibilité internes pour .NET Framework 4.6.2 et netstandard2.0.

Supprimez toute copie écrite manuellement du client MTP avant d’ajouter le paquet afin d’éviter les doublons de types internes.

Choisir un modèle de lancement

Pour démarrer l’application de test en tant que processus externe, utilisez MtpServerClient.LaunchAsync. Le client est responsable de ce processus enfant et le termine pendant la phase de nettoyage, si nécessaire.

Pour un hôte incorporé ou un environnement de thread d’interface utilisateur qui ne peut pas utiliser Process.Start, utilisez MtpServerClient.LaunchInProcessAsync. La méthode exécute l’application de test via un rappel asynchrone dans le processus actuel. Ne bloquez pas le thread de lancement, car le rappel et le client partagent le processus.

Les deux modèles au lancement utilisent un transport TCP en boucle locale. WebAssembly dans le navigateur ne peut pas créer le listener requis, donc le lancement dans le processus génère PlatformNotSupportedException. Le lancement in-process ne fournit pas de transport WebAssembly alternatif.

Arrêter le client

Pour arrêter le client et l’application lancée sans bloquer le thread appelant, appelez IMtpServerClient.ShutdownAsync(). La méthode asynchrone évite la réactivité des threads d’interface utilisateur et les problèmes de blocage dans les hôtes incorporés.

Pour un hôte dans le processus, MtpServerClientOptions.ServerShutdownTimeout contrôle le temps d’attente de la phase de démontage une fois que le client a fermé le transport. La valeur par défaut est 30 secondes. Lisez ServerExitCode après l’arrêt pour obtenir le code de retour du callback. La valeur reste null pendant l’exécution de l’application ou lorsque l’application échoue au lieu de retourner un code de sortie.

Déclarer le caractère avec état du client

À compter de MTP 2.4.1, définissez l’option nullable MtpServerClientOptions.IsStateful pour décrire la façon dont le client consomme les mises à jour de nœud de test :

Value Déclaration
true Le client conserve un ensemble adressable de nœuds de test pour la session et conserve l’état connu de chaque nœud jusqu’à ce qu’une autre mise à jour le modifie, comme pourrait le faire un explorateur de tests d’IDE.
false Le client consomme des mises à jour sans conserver cet état de nœud de test.
null (valeur par défaut) Le client ne déclare pas la capacité. La négociation d’initialisation omet le champ.

Le client envoie une valeur booléenne explicite via la capacité du protocole expérimental capabilities.testing.isStateful. Le caractère avec état est indépendant de la durée de vie de la connexion et de la capacité du serveur MultiRequestSupport. Un client n’acquiert pas d’état simplement parce qu’il envoie plusieurs requêtes sur la même connexion.

MTP 2.4.0 utilise une option booléenne non nullable avec une valeur par défaut false. Pour conserver une fonctionnalité non déclarée, utilisez MTP 2.4.1 ou version ultérieure.

À l’intérieur d’un framework ou d’une extension, utilisez le service expérimental IClientInfoservice pour inspecter la déclaration. Lisez clientInfo.Capabilities.IsStateful pour un résultat booléen conservateur, c’est-à-dire false lorsque la fonctionnalité n’est pas déclarée. Dans MTP 2.4.1 ou version ultérieure, ClientCapabilitiesExtensions.GetIsStateful() conserve la distinction entre les clients non déclarés, explicitement sans état et avec état.

Négocier la compatibilité des protocoles

À compter de MTP 2.4, la négociation de protocole en mode serveur est indépendante de la version du package NuGet MTP. Un client déclare les versions de protocole qu’il prend en charge, et le serveur sélectionne une version commune. Lorsqu’aucune version prise en charge commune n’existe, l’application de test s’arrête avec le code de sortie ProtocolError (12) au lieu de continuer avec un contrat de communication incompatible.

Utilisez le schéma JSON server-mode 1.0 versionné pour valider les messages. Les sérialiseurs System.Text.Json et Jsonite suivent le même schéma et l’enveloppe d’erreur.

Voir aussi

  • Dernière mise à jour :