Introduction

Les actions winget de Level s'exécutent en tant que SYSTEM et appliquent la portée machine sur toutes les opérations. La plupart des échecs d'installation et de mise à niveau remontent à l'une de ces deux contraintes. Les comprendre d'avance résout 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 compte SYSTEM, et non en tant qu'utilisateur connecté ou session d'administrateur standard. Tout comportement de paquet qui dépend du contexte utilisateur ne fonctionnera pas de la même manière.
Applique la portée machine: Level ajoute --scope machine à toutes les opérations winget. Seuls les paquets ayant une portée machine définie dans leur manifeste peuvent être installés ou mis à jour via Level.

Ces deux contraintes expliquent presque tous les rapports « ç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 a un environnement et un registre différents d'un utilisateur connecté. La plupart du temps, cela apparaît comme un problème de permission ou un chemin de profil utilisateur manquant.

Il n'y a pas de solution de contournement pour les paquets qui nécessitent fondamentalement une session utilisateur. Pour ceux-ci, envisagez une approche basée sur des scripts avec PsExec ou une tâche planifiée s'exécutant sous un contexte utilisateur spécifique.

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

Level applique la portée machine. Un paquet peut s'installer correctement en tant qu'admin sans --scope machine mais échouer quand 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 d'administrateur, le paquet ne fournit pas d'installateur de portée machine. Level ne peut pas l'installer via l'action winget. Les seules options sont de trouver un ID de paquet alternatif qui supporte la portée machine, ou de l'installer via une action Run Script avec un installateur différent.

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

Level ajoute --scope machine aux analyses de mise à niveau, donc 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 exact. 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

C'est rare. Cela se produit lorsque l'installateur 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'y a pas de solution de contournement pour cela — le problème vient de l'installateur 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

Le Paquet de mise à jour Winget a un champ intégré Paquet(s) exclu(s). Entrez un ou plusieurs ID de paquets là et ces paquets sont ignorés lors de l'exécution de la mise à niveau — aucun épinglage ou solution de contournement en ligne de commande nécessaire.

Vérifier si un paquet supporte la portée machine

La vérification définitive est le manifeste du paquet dans le dépôt winget-pkgs. Cherchez 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 winget install --scope machine ci-dessus dans une session PowerShell d'administrateur. Si elle réussit là, elle fonctionnera dans Level.

FAQ

Level utilise-t-il le winget Microsoft standard ou sa propre version ? Level installe et gère sa propre implémentation de winget. Le Installer Winget (ou toute autre action winget, qui l'installe automatiquement) configure la version gérée de Level. Cela garantit un comportement cohérent sur vos appareils, quel que soit la version winget (le cas échéant) qui était déjà présente.
Je ne trouve pas d'ID de paquet. Où chercher ? Recherchez 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 ce qui va dans l'action Level.
Puis-je exécuter des commandes winget directement depuis le terminal de Level ? Oui. Le terminal d'arrière-plan de Level s'exécute en tant que SYSTEM, donc les contraintes de portée machine et de contexte SYSTEM s'appliquent là aussi. Testez d'abord les commandes dans le terminal 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 légèrement accuser du retard par rapport au dépôt communautaire. Si un paquet très récent n'apparaît pas, vérifiez si le --scope machine est défini dans le manifeste.

Dépannage Winget