Les actions winget de Level s'exécutent en tant qu' SYSTEM et impose la portée machine sur 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 packages 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 distincte Installer Winget installe l'outil winget.exe en ligne de commande.

Deux choses sont toujours vraies pour chaque action de package winget de Level :

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

Si vous pouvez installer un package en tant qu'utilisateur actuellement connecté, mais que l'action Level échoue, la différence tient au 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 sous la forme d'un problème de permission ou d'un chemin de profil utilisateur manquant.

Il n'existe aucune solution de contournement pour les packages qui nécessitent fondamentalement une session utilisateur. Pour ceux-là, envisagez une approche par 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 package 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 administrateur, le package 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 ID de package alternatif prenant en charge la portée machine, ou de l'installer via une action Exécuter un script avec un autre programme d'installation.

Level utilise la portée machine pour les analyses de mise à niveau ; seules les installations à portée machine apparaissent donc 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 qu'affiche Level, Level est exact. Les packages installés dans 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 de package 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 sans interface en tant que SYSTEM.

Examinez la sortie de l'action pour identifier un 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 package expire de façon répétée, ajoutez son ID de package à Package(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.

L'action Mettre à niveau le package Winget dispose d'un champ Package(s) exclus . Saisissez un ou plusieurs ID de package et ces packages seront ignorés lors de l'exécution de la mise à niveau, sans nécessiter d'épinglage ni de solutions de contournement en ligne de commande.

La vérification définitive est le manifeste du package 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 ci-dessus dans une session PowerShell administrateur. Si cela réussit, cela fonctionnera dans Level.