Introduction

Les actions winget de Level s'exécutent en tant qu' SYSTEM utilisateur et applique la portée machine à 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.

Comment Level exécute Winget

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

S'exécute en tant que SYSTEM: Level exécute winget sous le SYSTEM compte, et non en tant qu'utilisateur connecté ou session administrateur standard. Tout comportement de paquet dépendant du contexte utilisateur ne fonctionnera pas de la même façon.
Applique la portée machine: Level ajoute --scope machine à toutes les opérations winget. Seuls les paquets disposant d'une portée machine définie dans leur manifeste peuvent être installés ou mis à niveau via Level.

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

Problèmes courants

Le paquet s'installe via PowerShell mais pas via Level

Si vous pouvez installer un paquet en tant qu'utilisateur actuellement connecté mais que l'action Level échoue, la différence est 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 permissions ou un chemin de profil utilisateur manquant.

Il n'existe pas de solution 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.

Le paquet s'installe en tant qu'administrateur mais pas via Level

Level applique 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 :

winget install --scope machine -e --id PACKAGE_ID

Si cela échoue dans une session PowerShell 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 ID 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.

L'action de mise à niveau affiche moins de paquets que prévu

Level ajoute --scope machine aux 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 :

winget upgrade --scope machine --all

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

L'installation du paquet expire dans Level mais fonctionne via PowerShell administrateur

Cela est rare. Cela se produit lorsque le programme d'installation du paquet ne gère pas correctement le mode silencieux/discret et attend une interaction utilisateur qui ne peut jamais arriver, car Level s'exécute en tant que SYSTEM sans interface utilisateur. Il n'existe pas de solution de contournement pour cela — le problème vient du programme d'installation lui-même. Vérifiez les problèmes ouverts du paquet dans le dépôt winget-pkgs.

Exclure un paquet des mises à jour automatiques

L'action Mettre à niveau le paquet Winget dispose d'un champ Paquet(s) exclu(s) champ. Saisissez un ou plusieurs ID de paquets et ces paquets seront ignorés lors de l'exécution de la mise à niveau — aucune épingle ni solution de contournement en ligne de commande n'est nécessaire.

Vérifier si un paquet prend en charge la portée machine

La vérification définitive consiste à consulter le manifeste du paquet dans le dépôt winget-pkgs. Recherchez InstallerScope: machine dans le manifeste. Si elle est absente ou définie 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.

FAQ

Level utilise-t-il le winget standard de Microsoft ou sa propre version ? Level installe et gère sa propre implémentation de winget. L'action Installer Winget (ou toute autre action winget, qui l'installe automatiquement) configure la version gérée par Level. Cela garantit un comportement cohérent sur tous vos appareils, quelle que soit la version de winget (le cas échéant) déjà présente.
Je n'arrive pas à trouver un ID de paquet. Où chercher ? Recherchez dans le dépôt winget-pkgs ou exécutez winget search <name> dans une session PowerShell sur un appareil où le winget de Level est installé. L'ID que vous trouvez est celui à utiliser dans l'action Level.
Puis-je exécuter des commandes winget directement depuis le terminal de Level ? Oui. Le terminal en arrière-plan de Level s'exécute en tant que SYSTEM, donc les contraintes de portée machine et de contexte SYSTEM s'y appliquent également. Testez les commandes dans le terminal d'abord avant de les intégrer dans une automatisation.
Un paquet a été récemment ajouté à winget-pkgs mais Level ne l'affiche pas comme disponible. L'implémentation winget de Level peut être légèrement en retard par rapport au dépôt communautaire. Si un paquet très récent n'apparaît pas, vérifiez si la --scope machine portée est définie dans le manifeste pour le moment.

Dépannage Winget