Partager via


Valeurs de métadonnées de package qui ont un impact sur l’interface utilisateur de la galerie PowerShell

Cet article explique comment les métadonnées de vos packages sont utilisées par la galerie PowerShell. Pour les modules, les métadonnées sont stockées dans le manifeste du module. Pour les scripts, les métadonnées sont stockées à l’aide de mots-clés basés sur des commentaires. Les applets de commande suivantes sont utilisées pour créer ou mettre à jour ces métadonnées :

La liste suivante présente les éléments de l’interface utilisateur de la page de package de la galerie PowerShell qui sont contrôlés par le manifeste du module.

  • Titre : nom du package publié dans la galerie.

  • Version : la version affichée est la chaîne de version dans les métadonnées et une étiquette de préversion si elle est spécifiée. La chaîne de préversion spécifiée est ajoutée à ModuleVersion. Pour plus d’informations sur les chaînes de préversion dans les modules, consultez Versions des modules de préversion.

  • Description : il s’agit de la description dans le manifeste du module.

  • Exiger l’acceptation de la licence : un module peut exiger que l’utilisateur accepte une licence, en définissant RequireLicenseAcceptance = $true, en fournissant un LicenseURI et en fournissant un license.txt fichier à la racine du dossier du module. Pour plus d’informations, consultez Exiger l’acceptation de la licence.

  • Notes de mise à jour - Ces informations proviennent de la section Notes de publication , sous PSData\PrivateData.

  • Propriétaires : les propriétaires sont la liste des utilisateurs de la galerie PowerShell qui peuvent mettre à jour un package. La liste des propriétaires n’est pas incluse dans le manifeste du package. Des documents supplémentaires décrivent comment gérer les propriétaires d’éléments.

  • Auteur : il est inclus dans le manifeste du module en tant qu’auteur. Le champ Auteur est souvent utilisé pour spécifier une société ou une organisation associée à un package.

  • Copyright - Il s’agit du champ Copyright dans le manifeste du module.

  • FileList : la liste de fichiers est créée lorsque le package est publié dans la galerie PowerShell. Il n’est pas contrôlable par les informations du manifeste. La galerie PowerShell crée .nuspec un fichier qui apparaît dans la liste des fichiers de chaque package. Ce fichier n’est pas installé avec le package sur un système. Il s’agit du manifeste du package NuGet pour le package et peut être ignoré.

  • Étiquettes - Les balises sont incluses dans PrivateData\PSData le manifeste du module. Les balises ont des exigences et des significations spécifiques qui sont décrites dans la section Détails de la balise .

  • Applets de commande : elles sont fournies dans le manifeste du module à l’aide de CmdletsToExport. Il est recommandé de répertorier explicitement les noms des applets de commande plutôt que d’utiliser le caractère générique *. Le fait d’avoir une liste améliore les performances du module de chargement.

  • Fonctions : elles sont fournies dans le manifeste du module à l’aide de FunctionsToExport. Il est recommandé de répertorier explicitement les noms des applets de commande plutôt que d’utiliser le caractère générique *. Le fait d’avoir une liste améliore les performances du module de chargement.

  • Ressources DSC : elles sont fournies dans le manifeste à l’aide de DscResourcesToExport. Cette valeur n’est prise en charge que pour les modules dans PowerShell 5.0 et versions ultérieures.

  • Fonctionnalités de rôle : les rôles sont répertoriés lorsque le module dispose d’un ou plusieurs fichiers de capacité de rôle (.psrc). Ces fichiers sont utilisés par JEA. Pour plus d’informations, consultez Fonctionnalités de rôle.

  • Éditions PowerShell : pour les modules conçus pour PowerShell 5.0 et versions antérieures, cela est contrôlé à l’aide de balises. Pour le bureau, utilisez la balise PSEdition_Desktop, et pour le noyau, utilisez la balise PSEdition_Core. Pour les modules conçus pour PowerShell 5.1 et versions ultérieures, il existe une clé CompatiblePSEditions dans le manifeste. Pour plus d’informations, consultez Prise en charge de PSEdition pour les modules.

  • Dépendances : elles sont fournies dans le manifeste à l’aide de RequiredModules.

  • Version minimale de PowerShell : elle est fournie dans le manifeste à l’aide de PowerShellVersion.

  • Historique des versions : affiche la liste des versions du module qui ont été publiées dans la galerie. Les packages masqués à l’aide de la fonctionnalité Supprimer ne sont pas affichés dans l’historique des versions, sauf si vous êtes propriétaire d’un package.

  • Site de projet : le site de projet est fourni pour les modules dans la PrivateData\PSData section du manifeste du module en spécifiant un ProjectURI.

  • Licence : un lien de licence est fourni pour les modules dans la PrivateData\PSData section du manifeste du module en spécifiant un LicenseURI.

    Important

    Si aucune licence n’est fournie via l’URI de licence ou dans le package, les conditions d’utilisation de la galerie PowerShell s’appliquent au package. Pour plus d’informations, consultez les Conditions d’utilisation.

  • Icon : un lien est fourni pour les modules dans la PrivateData\PSData section du manifeste du module en spécifiant un IconURI. L’URI doit pointer vers une image de 85 x 85 avec un arrière-plan transparent. L’URI doit être un lien direct vers le fichier image et ne doit pas accéder à une page web ou à un fichier dans le package PowerShell Gallery.

La liste suivante montre les éléments de l’interface utilisateur de la page de package de la galerie PowerShell qui sont contrôlés par les métadonnées basées sur les commentaires dans un fichier de script.

  • Titre : il s’agit du nom du package publié dans la galerie.

  • Version : la version affichée est la chaîne de version dans les métadonnées et une étiquette de préversion si elle est spécifiée. La valeur provient du .VERSION mot-clé dans le bloc de commentaire de métadonnées. Lors de la publication d’une préversion d’un script, ajoutez la chaîne de préversion à la version. Pour plus d’informations sur la spécification de chaînes de préversion dans les modules, consultez Versions préliminaires de scripts.

  • Description : ces informations proviennent du mot-clé de l’aide .DESCRIPTION basée sur les commentaires d’un fichier de script.

  • Exiger l’acceptation de la licence : l’acceptation de la licence n’est pas prise en charge pour les scripts. Toutefois, le scénario dans lequel un script dépend d’un module qui nécessite l’acceptation d’une licence est pris en charge. Pour plus d’informations, consultez Exiger l’acceptation d’une licence pour les scripts.

  • Notes de mise à jour : ces informations proviennent du .RELEASENOTES mot-clé dans les métadonnées basées sur les commentaires d’un fichier de script.

  • Propriétaires : les propriétaires sont la liste des utilisateurs de la galerie PowerShell qui peuvent mettre à jour un package. La liste des propriétaires n’est pas incluse dans le manifeste du package. Pour plus d’informations, voir Gérer les propriétaires d’éléments.

  • Auteur : ces informations proviennent du .AUTHOR mot-clé dans les métadonnées basées sur les commentaires d’un fichier de script. Le champ Auteur est souvent utilisé pour spécifier une société ou une organisation associée à un package.

  • Droits d’auteur : ces informations proviennent du .COPYRIGHT mot-clé dans les métadonnées basées sur les commentaires d’un fichier de script.

  • FileList : la liste de fichiers est créée lorsque le package est publié dans la galerie PowerShell. Il n’est pas contrôlable par les informations du manifeste. La galerie PowerShell crée .nuspec un fichier qui apparaît dans la liste des fichiers de chaque package. Ce fichier n’est pas installé avec le package sur un système. Il s’agit du manifeste du package NuGet pour le package et peut être ignoré.

  • Balises - *Cette information provient du .TAGS mot-clé dans les métadonnées basées sur les commentaires d’un fichier de script. Les balises ont des exigences et des significations spécifiques qui sont décrites dans la section Détails de la balise .

  • Éditions PowerShell : pour les modules conçus pour PowerShell 5.0 et versions antérieures, cela est contrôlé à l’aide de balises. Pour le bureau, utilisez la balise PSEdition_Desktop, et pour le noyau, utilisez la balise PSEdition_Core. Pour les modules conçus pour PowerShell 5.1 et versions ultérieures, il existe une clé CompatiblePSEditions dans le manifeste. Pour plus d’informations, consultez Prise en charge de PSEdition pour les modules.

  • Historique des versions : affiche la liste des versions du module qui ont été publiées dans la galerie. Les packages masqués à l’aide de la fonctionnalité Supprimer ne sont pas affichés dans l’historique des versions, sauf si vous êtes propriétaire d’un package.

  • Site du projet : ces informations proviennent du .PROJECTURI mot-clé dans les métadonnées basées sur les commentaires d’un fichier de script.

  • Licence : ces informations proviennent du .LICENSEURI mot-clé dans les métadonnées basées sur les commentaires d’un fichier de script.

    Important

    Si aucune licence n’est fournie via le .LICENSEURI package ou dans celui-ci, les conditions d’utilisation de PowerShell Gallery s’appliquent au package. Pour plus d’informations, consultez les Conditions d’utilisation.

  • Icône : ces informations proviennent du .ICONURI mot-clé dans les métadonnées basées sur les commentaires d’un fichier de script. L’URI doit pointer vers une image de 85 x 85 avec un arrière-plan transparent. L’URI doit être un lien direct vers le fichier image et ne doit pas accéder à une page web ou à un fichier dans le package PowerShell Gallery.

Modification des détails du package

La page Modifier le package de la galerie PowerShell permet aux éditeurs de modifier plusieurs champs affichés pour un package, en particulier :

  • Titre
  • Descriptif
  • Résumé
  • URL de l'icône
  • URL de la page d’accueil du projet
  • des auteurs
  • Copyright
  • Étiquettes
  • Notes de publication
  • Licence requise

Vous ne devez modifier ces informations dans la galerie que pour corriger ce qui s’affiche pour une version plus ancienne d’un module. Les utilisateurs qui téléchargent le package verront que les métadonnées ne correspondent pas à la galerie PowerShell. Chaque fois que vous modifiez des informations dans la galerie, vous devez publier une nouvelle version du paquet avec les mêmes modifications.

Détails de l’étiquette

Les balises sont de simples chaînes que les consommateurs utilisent pour trouver des packages. Les balises sont plus précieuses lorsqu’elles sont utilisées de manière cohérente dans des packages associés. L’utilisation de variantes du même mot, par exemple base de données et bases de données ou test et test, offre peu d’avantages. Les balises sont des chaînes insensibles à la casse et ne peuvent pas inclure de blancs. S’il y a une expression que vous pensez que les utilisateurs rechercheront, ajoutez-la à la description du package afin qu’elle puisse être trouvée dans les résultats de recherche. Utilisez des casses, des traits d’union, des traits de soulignement ou des points Pascal pour améliorer la lisibilité. Soyez prudent lorsque vous créez des balises longues, complexes et inhabituelles qui sont facilement mal orthographiées.

Les applets de commande PowerShell Gallery et PowerShellGet ont des significations spéciales pour les PSEdition_Desktop balises et PSEdition_Core . Consultez la discussion précédente sur les éditions PowerShell.

Comme indiqué précédemment, les balises offrent le plus de valeur lorsqu’elles sont spécifiques et utilisées de manière cohérente dans de nombreux packages. En tant qu’éditeur essayant de trouver les meilleures balises à utiliser, l’approche la plus simple consiste à rechercher les balises que vous envisagez dans la galerie PowerShell. Idéalement, les packages renvoyés correspondent à votre utilisation de ce mot-clé.

Le tableau suivant présente quelques-unes des balises les plus couramment utilisées. La balise préférée doit renvoyer les meilleurs résultats de recherche.

Balise préférée Alternatives et notes
Active Directory AD n’est actuellement pas utilisé seul
Appveyor
Automation
AWS
Azur
AzureAD
AzureAutomation
AzureRm Utilisé principalement pour les modules AzureRM
Backup (Sauvegarder)
Construire
ChatOps
Cloud
Color
Paramétrage
CrescendoConstruit Cette balise est ajoutée automatiquement par Crescendo lorsque vous exportez le module
Base de données Les bases de données (au pluriel) sont moins souhaitables
DBA
Déploiement Deploy est un peu moins utilisé
DevOps
DNS
Docker
DSC DesiredStateConfiguration est moins souhaitable, il est trop long
DSCResource
DSCResourceKit
Excel
Échange
Firewall
GIT
GitHub
Gitlab
Google
HTML
Hyper-V HyperV est moins courant en tant que balise
IaaS
IIS
Json
Linux
Log Utilisation préférée de Log en tant qu’objet
Logging Utilisation préférée de la journalisation en tant qu’action
MacOS
Supervision
MSI
Réseau Le réseautage est similaire, moins souvent utilisé
Bureau365 Il est préférable d’épeler Office. O365 est moins couramment utilisé, bien que plus court
Gestion des paquets
Emmerder
PoshBot
Rapport Le rapport, c’est une chose
Rapports Le signalement est une action, le signalement est une chose
ResourceManager « Arm » est utilisé pour décrire un groupe de processeurs et ne doit pas être utilisé pour Azure Resource Manager
REST
Security La défense est moins précise
SharePoint
SQL
SQLServer
Storage
Test Les tests sont moins souhaitables
VersionControl La version est moins précise, bien qu’utilisée plus fréquemment
VSTS
Fenêtres
WinRM
WMI
Code postal