Déploiement de l’hôte de test

Ces extensions contrôlent comment et où MTP déploie et démarre l’hôte de test. Ils utilisent le point d’extension expérimental ITestHostLauncher pour contrôler le déploiement et le démarrage de l’hôte de test.

Tip

Lorsque vous utilisez Microsoft. Testing.Platform.MSBuild, installez le package NuGet d'une extension pour inscrire automatiquement l'extension. Les exécuteurs MSTest, NUnit et xUnit incluent transitivement Microsoft.Testing.Platform.MSBuild . Si vous désactivez le point d’entrée généré, appelez AddSelfRegisteredExtensions pour inscrire les packages que MSBuild contribue.

Déploiement d’applications empaquetées

L’extension Microsoft.Testing.Extensions.PackagedApp enregistre un hôte de test Windows empaqueté à partir de son arborescence de sortie de build et l’active à l’aide de son ID de modèle utilisateur d’application (AUMID).

Le package a été introduit dans MTP 2.3. À partir de MTP 2.5, il prend en charge de bout en bout les hôtes empaquetés de pleine confiance et AppContainer, notamment :

• Applications WinUI 3 de confiance totale empaquetées.
• Applications UWP modernes qui utilisent UseUwp.
• Applications UWP classiques qui ciblent uap10.0.
• Hôtes WinUI 3 packagedClassicApp qui définissent TrustLevel="appContainer".

MSTest.Sdk 4.5 ou version ultérieure configure automatiquement cette extension ainsi que le composant side-car requis du modèle d’application à confiance totale. Pour connaître la configuration et l’exécution des commandes d’application, consultez Tester les applications UWP et WinUI 3 avec MSTest et MTP.

Avertissement

À compter de MTP 2.4, Microsoft.Testing.Extensions.PackagedApp suit la version de publication MTP et son API d’inscription publique n’est plus expérimentale. Le point d’extension générique ITestHostLauncher reste expérimental et peut changer dans une version ultérieure.

Répondre aux exigences

Respectez ces exigences avant d’utiliser l’extension :

• Cibler la version de plateforme Windows 10.0.19041.0 ou ultérieure pour une application WinUI 3 empaquetée.
• Pour inscrire une disposition de sortie de build non signée, activez le mode développeur ou configurez le chargement indépendant.
• Pour UWP, utilisez MSBuild de bureau à partir de Visual Studio avec la charge de travail UWP et le KIT de développement logiciel (SDK) Windows requis.
• Exécutez les hôtes de test AppContainer à partir d’un processus de contrôleur non élevé.

Comprendre l’activation de package

Pour une application empaquetée, le lanceur :

1. Repère le AppxManifest.xml qui décrit le fichier exécutable de test.
2. Inscrit la disposition de sortie de build pour l’utilisateur actuel.
3. Résout l’AUMID de l’application manifeste sélectionnée.
4. Active l’application et la connecte au contrôleur MTP.

Pour packagedClassicApp et win32App les hôtes, Windows fournit des arguments MTP via le tableau d’arguments de processus normal. Ce comportement s’applique également à un packagedClassicApp qui utilise AppContainer.

Pour un UWPwindowsApp, Windows fournit une chaîne d’activation opaque via LaunchActivatedEventArgs.Arguments. Dans OnLaunched, appelez PackagedAppExtensions.GetTestApplicationArguments avant de créer le générateur MTP.

Connectez un hôte AppContainer

Un jeton AppContainer inclut un SID de package restreint. Un canal nommé qui autorise uniquement l’utilisateur actuel rejette le processus AppContainer même s’il appartient au même utilisateur connecté.

Dans MTP 2.5 ou version ultérieure, le lanceur d’applications empaquetées dérive le SID de package exact de l’application sélectionnée et demande à MTP d’accorder à ce SID les droits clients minimaux sur le contrôleur et les canaux d’extension. L’extension n’accorde pas ALL APPLICATION PACKAGES, n’abaisse pas le niveau d’intégrité du tube et ne nécessite pas d’exception de bouclage réseau.

Le sidecar transfère les métadonnées du contrôleur via le package LocalState. Il copie également les artefacts TRX, de vidage, de diagnostic et de relance depuis l’espace de stockage du package vers le répertoire de résultats spécifié une fois l’hôte en mode sandbox arrêté.

Contrôler l’activation automatique

Par défaut, le lanceur s’active uniquement lorsqu’il trouve un manifeste de package qui décrit l’application de test. Une application winUI 3 non empaquetée ou une application de test de console ordinaire reste sur le chemin de démarrage direct.

Utilisez TESTINGPLATFORM_PACKAGEDAPP_LAUNCHER pour remplacer la détection de paquet :

Valeur	Behavior
auto ou non défini	Activez uniquement pour une disposition empaquetée.
always	Activez pour n’importe quelle disposition, y compris une disposition libre que vous souhaitez déployer avant le démarrage.
never	Désactivez le lanceur d’applications empaquetées.

Utiliser TESTINGPLATFORM_PACKAGEDAPP_PIPEAUTHORIZATION pour outrepasser l’autorisation package-SID :

Valeur	Behavior
auto ou non défini	Autorisez le SID de package uniquement lorsque le manifeste déclare une application AppContainer.
always	Demandez l’autorisation package-SID pour n’importe quelle configuration empaquetée.
never	Conservez l’autorisation du pipe réservée à l’utilisateur actuel uniquement.

Inscrire l’extension manuellement

Si vous n’utilisez pas l’inscription MSBuild automatique, inscrivez l’extension dans votre générateur MTP :

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddPackagedAppDeployment();

N’appelez AddPackagedAppDeployment pas si l’application appelle AddSelfRegisteredExtensions et référence déjà le package. Une exécution MTP ne peut inscrire qu’un seul lanceur d’hôtes de test.