Questions fréquentes sur PowerShell Gallery

Un module PowerShell est un package réutilisable contenant des fonctionnalités PowerShell. Tous les éléments de PowerShell (fonctions, variables, ressources DSC, etc.) peuvent être empaquetés dans des modules. En règle générale, les modules sont des dossiers qui contiennent des types spécifiques de fichiers stockés dans un chemin spécifique. Il existe différents types de modules PowerShell.

Un script PowerShell est une série de commandes qui sont stockées dans un fichier .ps1 pour permettre la réutilisation et le partage. Les workflows PowerShell sont également des scripts PowerShell, qui présentent une série de tâches et donnent le séquencement de ces tâches. Pour plus d’informations, visitez le site Présentation du workflow Windows PowerShell.

Les modules conviennent généralement mieux pour le partage, mais nous allons permettre le partage de scripts pour que vous puissiez facilement fournir des workflows et des scripts à la communauté. Pour plus d’informations, voir les blogs suivants :

• Don't Write Scripts, Write PowerShell Modules
• Understanding PowerShell Modules

Vous devez inscrire un compte dans PowerShell Gallery avant de pouvoir y publier des packages. En effet, la publication de packages nécessite un NuGetApiKey, qui est fourni lors de l’inscription. Pour vous inscrire, utilisez votre compte personnel, professionnel ou scolaire pour vous connecter à PowerShell Gallery. Un processus d’inscription à usage unique est nécessaire quand vous vous connectez pour la première fois. Votre NuGetApiKey est ensuite disponible dans la page de votre profil.

Une fois que vous êtes inscrit dans PowerShell Gallery, utilisez les applets de commande Publish-Module ou Publish-Script pour y publier votre package. Pour plus d’informations sur l’exécution de ces applets de commande, examinez l’onglet Publier ou lisez la documentation sur Publish-Module et Publish-Script.

Il est inutile de s’inscrire ou de se connecter à PowerShell Gallery pour installer ou enregistrer des packages.

Le message d’erreur complet est : « Échec du traitement de la demande ». « La clé d’API spécifiée n’est pas valide ou n’est pas autorisée à accéder au package spécifié. » Le serveur distant a retourné une erreur de type : (403) Refusé.

Cette erreur peut se produire pour les raisons suivantes :

• La clé API spécifiée n’est pas valide. Vérifiez que vous avez spécifié la clé API valide à partir de votre compte. Pour obtenir votre clé API, examinez la page de votre profil.
• Le nom du package spécifié ne vous appartient pas. Si vous avez vérifié que votre clé API est correcte, il existe peut-être déjà un package portant le même nom que celui que vous essayez d’utiliser. Le package peut avoir été retiré de la liste par le propriétaire, auquel cas il n’apparaît dans aucun résultat de recherche. Pour déterminer si un package portant le même nom existe déjà, ouvrez un navigateur et accédez à la page de détails du package : https://www.powershellgallery.com/packages/<packageName>. Par exemple, un accès direct à https://www.powershellgallery.com/packages/pester vous dirige vers la page de détails du module Pester, qu’il soit répertorié ou non. Si un package avec un nom en conflit existe déjà et n’est pas répertorié, vous pouvez :
  • sélectionner un autre nom pour votre package ;
  • contacter les propriétaires du package existant.

Gardez à l’esprit que votre compte de galerie n’intègre pas les modifications apportées à votre alias d’e-mail principal. Pour plus d’informations, voir Gérer les alias liés à votre compte Microsoft.

En cochant une case Catégorie, vous indiquez « J’aimerais voir tous les packages de cette catégorie ». Seuls les packages des catégories sélectionnées seront affichés. De même, en cochant toutes les cases à cocher Catégorie, vous indiquez « J’aimerais voir tous les packages de n’importe quelle catégorie ». Cependant, certains packages de la galerie n’appartiennent à aucune des catégories listées : ils n’apparaissent donc pas dans les résultats. Pour afficher tous les packages de la galerie, décochez toutes les catégories, ou sélectionnez à nouveau l’onglet Packages.

Tout type de module PowerShell (modules de script, modules binaires ou modules de manifeste) peut être publié dans la galerie. Pour publier un module, PowerShellGet doit connaître quelques détails le concernant : version, description, auteur et mode de licence. Ces informations sont lues lors du processus de publication à partir du fichier manifeste de module (.psd1) ou de la valeur du paramètre LicenseUri de l’applet de commande Publish-Module. Tous les modules publiés dans PowerShell Gallery doivent avoir des manifestes de module. Tout module qui inclut les informations suivantes dans son manifeste peut être publié dans PowerShell Gallery :

• Version
• Description
• Auteur
• URI vers les termes du contrat de licence du module, dans le cadre de la section PrivateData du manifeste ou dans le paramètre LicenseUri de l’applet de commande Publish-Module.

La façon la plus simple de créer un manifeste de module consiste à exécuter l’applet de commande New-ModuleManifest. Dans PowerShell 5.0 ou version ultérieure, New-ModuleManifest génère un manifeste de module correctement mis en forme avec des champs vides pour les métadonnées utiles comme ProjectUri, LicenseUri et Tags. Il suffit de remplir les champs vides ou d’utiliser le manifeste généré comme un exemple de mise en forme correcte.

Pour vérifier que tous les champs de métadonnées obligatoires ont été correctement remplis, utilisez l’applet de commande Test-ModuleManifest.

Pour mettre à jour les champs de fichier manifeste de module, utilisez l’applet de commande Update-ModuleManifest.

Tout type de script PowerShell (scripts ou workflows) peut être publié dans la galerie. Pour publier un script, PowerShellGet doit connaître quelques détails le concernant : version, description, auteur et mode de licence. Ces informations sont lues lors du processus de publication à partir de la section PSScriptInfo du fichier de script ou de la valeur du paramètre LicenseUri de l’applet de commande Publish-Script. Tous les scripts publiés dans PowerShell Gallery doivent avoir des informations de métadonnées. Tout script qui inclut les informations suivantes dans sa section PSScriptInfo peut être publié dans PowerShell Gallery :

• Version
• Description
• Auteur
• URI vers les termes du contrat de licence du script, dans la section PSScriptInfo du script ou dans le paramètre LicenseUri de l’applet de commande Publish-Script.

Tapez ce que vous recherchez dans la zone de texte. Par exemple, si vous souhaitez rechercher les modules qui sont liés à SQL Azure, tapez simplement « sql azure ». Notre moteur de recherche recherche ces mots clés dans tous les packages publiés, dont les titres, les descriptions et les métadonnées. Ensuite, selon un score de qualité pondéré, il affiche les correspondances les plus proches. Vous pouvez également effectuer des recherches par champ spécifique à l’aide de la syntaxe field:"value" dans la requête de recherche pour les champs suivants :

• Étiquettes
• Fonctions
• Applets de commande
• DscResources
• PowerShellVersion

Ainsi, par exemple, quand vous recherchez PowerShellVersion:"2.0", seuls les résultats qui sont compatibles avec PowerShellVersion 2.0 (selon leur manifeste de module/script) sont affichés.

La façon la plus simple de créer un fichier de script correctement mis en forme consiste à exécuter l’applet de commande New-ScriptFileInfo. Dans PowerShell 5.0, New-ScriptFileInfo génère un fichier de script correctement mis en forme avec des champs vides pour les métadonnées utiles comme ProjectUri, LicenseUri et Tags. Il suffit de remplir les champs vides ou d’utiliser le fichier de script généré comme un exemple de mise en forme correcte.

Pour vérifier que tous les champs de métadonnées obligatoires ont été correctement remplis, utilisez l’applet de commande Test-ScriptFileInfo.

Pour mettre à jour les champs de métadonnées de script, utilisez l’applet de commande Update-ScriptFileInfo.

Le terme module PowerShell fait également référence aux fichiers qui implémentent les fonctionnalités réelles. Les fichiers de module de script (.psm1) contiennent du code PowerShell. Les fichiers de module binaire (.dll) contiennent du code compilé.

Voici une illustration possible : le dossier qui encapsule le module est le dossier du module. Le dossier de module peut contenir un manifeste de module (.psd1) qui décrit le contenu du dossier. Les fichiers qui sont en réalité mis à contribution sont les fichiers de module de script (.psm1) et les fichiers de module binaire (.dll). Les ressources DSC sont situées dans un sous-dossier spécifique et sont implémentées en tant que fichiers de module de script ou fichiers de module binaire.

Tous les modules dans PowerShell Gallery contiennent des manifestes de module, et la plupart de ces modules contiennent des fichiers de module de script ou des fichiers de module binaire. Le terme module peut prêter à confusion en raison de ces différentes significations. Sauf spécification contraire, toutes les utilisations du mot module dans cette page font référence au dossier du module contenant ces fichiers.

PackageManagement est une interface commune permettant de travailler avec n’importe quel gestionnaire de package. Finalement, qu’il s’agisse de modules PowerShell, de MSI, de RubyGems, de packages NuGet ou de modules Perl, vous devez pouvoir utiliser des commandes de PackageManagement (Find-Package et Install-Package) pour les rechercher et les installer. Pour cela, PackageManagement dispose d’un fournisseur de package pour chaque gestionnaire de package qui s’intègre à PackageManagement. Les fournisseurs effectuent l’intégralité du travail réel ; ils extraient le contenu des référentiels et l’installent en local. Souvent, les fournisseurs de package enveloppent simplement les outils du gestionnaire de package existants pour un type de package donné.

PowerShellGet est le gestionnaire de package pour les packages PowerShell. Il existe un fournisseur de package PSModule qui expose les fonctionnalités PowerShellGet via PackageManagement. Pour cette raison, vous pouvez exécuter Install-Module ou Install-Package -Provider PSModule pour installer un module à partir de PowerShell Gallery. Certaines fonctionnalités PowerShellGet, dont Update-Module et Publish-Module, ne sont pas accessibles via les commandes PackageManagement.

En résumé, PowerShellGet a pour unique objectif de réussir une expérience de gestion des packages pour le contenu PowerShell. PackageManagement se concentre sur l’exposition de toutes les expériences de gestion des packages via un ensemble général d’outils. Si cette réponse ne vous satisfait pas, vous en trouverez une plus détaillée à la fin de ce document, dans la section Quelle est la relation réelle entre PackageManagement et PowerShellGet ?.

Pour plus d’informations, visitez la page de projet PackageManagement.

PowerShell Gallery est une version modifiée de la galerie NuGet. PowerShellGet emploie le fournisseur NuGet pour utiliser les référentiels NuGet, comme PowerShell Gallery.

Vous pouvez utiliser PowerShellGet sur n’importe quel partage de fichiers ou référentiel NuGet valide. Vous devez simplement ajouter le référentiel en exécutant l’applet de commande Register-PSRepository.

Oui.

Du point de vue de l’implémentation, PowerShellGet exploite intensément l’infrastructure PackageManagement.

Dans la couche d’applet de commande PowerShell, Install-Module est en fait un simple wrapper autour de Install-Package -Provider PSModule.

Dans la couche de fournisseur de package PackageManagement, le fournisseur de package PSModule appelle en fait d’autres fournisseurs de package PackageManagement. Par exemple, quand vous utilisez des galeries NuGet (telles que PowerShell Gallery), le fournisseur de package PSModule utilise le fournisseur de package NuGet pour travailler avec le référentiel.

Figure 1 : Architecture PowerShellGet

En général, nous recommandons de choisir la dernière version du module PowerShellGet (notez qu’il requiert .NET 4.5).

Le module PowerShellGet nécessite PowerShell 3.0 ou ultérieur.

Par conséquent, PowerShellGet nécessite l’un des systèmes d’exploitation suivants :

• Windows 10
• Windows 8.1 Professionnel
• Windows 8.1 Enterprise
• Windows 7 SP1
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2008 R2 SP1

PowerShellGet nécessite également .NET Framework 4.5 ou ultérieur. Pour plus d'informations, voir Installation de .NET Framework pour les développeurs.

Il n’est pas possible de réserver des noms de packages. Si vous pensez qu’un package existant a pris le nom qui convient mieux à votre package, essayez de contacter le propriétaire du package. Si vous n’obtenez pas de réponse au bout de quelques semaines, vous pouvez contacter le support technique et l’équipe PowerShell Gallery examinera la question.

Pour plus d’informations, consultez Gestion des propriétaires de packages sur PowerShellGallery.com.

Nous encourageons la communauté PowerShell à collaborer pour résoudre les conflits pouvant survenir entre les propriétaires de tous les packages. Nous avons élaboré une procédure de résolution des litiges que nous vous demandons de suivre avant toute intervention des administrateurs de PowerShellGallery.com.