Les actions winget de Level s'exécutent en tant qu' SYSTEM et impose la portée machine pour toutes les opérations. La plupart des échecs d'installation et de mise à niveau sont liés à l'une de ces deux contraintes. Les comprendre dès le départ permet de résoudre la majorité des problèmes signalés.

Les actions d'installation, de mise à niveau et de désinstallation de paquets de Level utilisent l'API Windows Package Manager de Microsoft. Elles ne dépendent pas d'une session PowerShell interactive ni de la configuration winget de l'utilisateur connecté. L'action Installer Winget installe l'outil winget.exe en ligne de commande.

Deux conditions sont toujours vérifiées pour chaque action de paquet winget de Level :

Ces deux contraintes expliquent presque tous les rapports du type « ça fonctionne dans PowerShell mais pas dans Level ».

Si vous pouvez installer un paquet en tant qu'utilisateur actuellement connecté mais que l'action Level échoue, la différence réside dans le contexte utilisateur. Level s'exécute en tant que SYSTEM, qui dispose d'un environnement et d'un registre différents de ceux d'un utilisateur connecté. La plupart du temps, cela se manifeste par un problème de permission ou un chemin de profil utilisateur manquant.

Il n'existe pas de contournement pour les paquets qui nécessitent fondamentalement une session utilisateur. Pour ceux-là, envisagez une approche basée sur un script avec PsExec ou une tâche planifiée s'exécutant dans un contexte utilisateur spécifique.

Level impose la portée machine. Un paquet peut s'installer correctement en tant qu'administrateur sans --scope machine mais échouent lorsque la portée machine est requise.

Testez-le directement pour confirmer :

Si cela échoue dans une session PowerShell en mode administrateur, le paquet ne fournit pas de programme d'installation à portée machine. Level ne peut pas l'installer via l'action winget. Les seules options sont de trouver un identifiant de paquet alternatif prenant en charge la portée machine, ou de l'installer via une action Exécuter un script avec un programme d'installation différent.

Level utilise la portée machine pour les analyses de mise à niveau, de sorte que seules les installations à portée machine apparaissent dans la liste des mises à niveau.

Vous pouvez vérifier en exécutant vous-même la commande équivalente :

Si les résultats correspondent à ce que Level affiche, Level est exact. Les paquets installés sous une portée utilisateur n'apparaîtront pas.

Si la sortie de l'action indique operation timed out, Windows Package Manager n'a pas terminé l'opération sur le paquet dans un délai d'environ 30 minutes. Cela se produit généralement lorsqu'un programme d'installation se bloque ou attend une interaction utilisateur qui ne peut pas être fournie pendant que Level s'exécute en mode sans interface en tant que SYSTEM.

Examinez la sortie de l'action pour identifier un nom de processus bloqué ou un message indiquant que l'application est en cours d'utilisation. Fermez l'application et réessayez lorsque cela est possible. Si le même paquet expire à plusieurs reprises, ajoutez son identifiant de paquet à Paquet(s) exclus dans une action Tout mettre à niveau et déployez-le avec le programme d'installation silencieux pris en charge par le fournisseur ou une action Exécuter un script à la place.

L'action Mettre à niveau un paquet Winget dispose d'un champ intégré Paquet(s) exclus . Saisissez-y un ou plusieurs identifiants de paquets et ces paquets seront ignorés lors de l'exécution de la mise à niveau, sans qu'il soit nécessaire d'utiliser des épingles ou des contournements en ligne de commande.

La vérification définitive consiste à consulter le manifeste du paquet dans le dépôt winget-pkgs. Recherchez InstallerScope: machine dans le manifeste. S'il est absent ou défini sur user, l'action winget de Level ne pourra pas l'installer.

Le raccourci pratique : exécutez la commande winget install --scope machine dans une session PowerShell en mode administrateur. Si cela réussit, cela fonctionnera dans Level.