Freigeben über


Paketmetadatenwerte, die die Benutzeroberfläche des PowerShell-Katalogs betreffen

In diesem Artikel wird erläutert, wie die Metadaten in Ihren Paketen vom PowerShell-Katalog verwendet werden. Bei Modulen werden die Metadaten im Modulmanifest gespeichert. Bei Skripts werden die Metadaten mithilfe von kommentarbasierten Schlüsselwörtern gespeichert. Die folgenden Cmdlets werden verwendet, um diese Metadaten zu erstellen oder zu aktualisieren:

Die folgende Liste enthält die Benutzeroberflächenelemente der Paketseiten im PowerShell-Katalog, die vom Modulmanifest gesteuert werden.

  • Titel: Dies ist der Name des Pakets, das im Katalog veröffentlicht wurde.

  • Version: Die angezeigte Version besteht aus der Versionszeichenfolge in den Metadaten und falls angegeben der Vorabversionsbezeichnung. Die angegebene Vorabversionszeichenfolge wird an die ModuleVersion angefügt. Informationen zu Vorabversionszeichenfolgen in Modulen finden Sie unter Vorabmodulversionen.

  • Beschreibung: Dies ist die Beschreibung im Modulmanifest.

  • Akzeptieren der Lizenz als erforderlich festlegen: Ein Modul kann erfordern, dass Benutzer*innen eine Lizenz akzeptieren müssen, indem sie RequireLicenseAcceptance = $true festlegen, einen LicenseURI angeben und eine Datei namens license.txt im Stammverzeichnis des Modulordners bereitstellen. Weitere Informationen finden Sie unter Erforderliche Zustimmung zur Lizenz.

  • Versionshinweise: Diese Informationen stammen aus dem Abschnitt ReleaseNotes unter PSData\PrivateData.

  • Besitzer: Unter „Besitzer“ befindet sich die Liste der Benutzer*innen im PowerShell-Katalog, die ein Paket aktualisieren können. Die Liste der Besitzer*innen ist nicht im Paketmanifest enthalten. Die zusätzliche Dokumentation enthält Informationen zur Verwaltung von Elementbesitzern.

  • Autor: Dieses Element lautet im Modulmanifest Author. Das Feld „Autor“ wird häufig verwendet, um ein Unternehmen oder eine Organisation anzugeben, das bzw. die einem Paket zugeordnet ist.

  • Copyright: Dieses Element ist im Modulmanifest das Feld Copyright.

  • Dateiliste: Die Dateiliste wird erstellt, wenn das Paket im PowerShell-Katalog veröffentlicht wird. Sie kann nicht durch die Manifestinformationen gesteuert werden. Der PowerShell-Katalog erstellt eine .nuspec-Datei, die in der Dateiliste jedes Pakets angezeigt wird. Diese Datei wird nicht zusammen mit dem Paket auf einem System installiert. Sie stellt das NuGet-Paketmanifest für das Paket dar und kann ignoriert werden.

  • Tags:Tags sind im Modulmanifest unter PrivateData\PSData enthalten. Für Tags gelten spezielle Anforderungen und Bedeutungen, die weiter unten im Abschnitt Tagdetails erläutert werden.

  • Cmdlets: Dieses Element wird im Modulmanifest mithilfe von CmdletsToExport angegeben. Es empfiehlt sich, die Cmdletnamen explizit aufzulisten, anstatt den Platzhalter * zu verwenden. Durch eine Liste wird die Leistung beim Laden des Moduls verbessert.

  • Funktionen: Dieses Element wird im Modulmanifest mithilfe von FunctionsToExport angegeben. Es empfiehlt sich, die Cmdletnamen explizit aufzulisten, anstatt den Platzhalter * zu verwenden. Durch eine Liste wird die Leistung beim Laden des Moduls verbessert.

  • DSC-Ressourcen: Dieses Element wird im Manifest mithilfe von DscResourcesToExport angegeben. Dieser Wert wird nur für Module in PowerShell 5.0 und höher unterstützt.

  • Rollenfunktionen: Rollen werden aufgelistet, wenn das Modul über mindestens eine Rollenfunktionsdatei (.psrc) verfügt. Diese Dateien werden von JEA verwendet. Weitere Informationen finden Sie unter Rollenfunktionen.

  • PowerShell-Editionen: Für Module, die für PowerShell 5.0 und früher entwickelt wurden, wird dies mithilfe von Tags gesteuert. Bei Desktop wird das Tag „PSEdition_Desktop“ und bei Core das „Tag PSEdition_Core“ verwendet. Bei Modulen, die für PowerShell 5.1 oder höher entwickelt wurden, ist im Hauptmanifest der Schlüssel CompatiblePSEditions enthalten. Weitere Informationen finden Sie unter Module mit kompatiblen PowerShell-Editionen.

  • Abhängigkeiten: Dieses Element wird im Manifest mithilfe von RequiredModules angegeben.

  • Mindestversion von PowerShell: Dieses Element wird im Manifest mithilfe von PowerShellVersion angegeben.

  • Versionsverlauf: Dieses Element zeigt eine Liste der Versionen des Moduls an, die im Katalog veröffentlicht wurden. Pakete, die mit dem Feature Löschen ausgeblendet wurden, werden nur im Versionsverlauf angezeigt, wenn Sie Paketbesitzer*in sind.

  • Projektwebsite: Die Projektwebsite wird bei Modulen im Abschnitt PrivateData\PSData des Modulmanifests durch Angabe eines ProjectURI bereitgestellt.

  • Lizenz: Ein Lizenzlink wird bei Modulen im Abschnitt PrivateData\PSData des Modulmanifests durch Angabe eines LicenseURI bereitgestellt.

    Wichtig

    Wenn eine Lizenz nicht über den LicenseURI oder innerhalb des Pakets bereitgestellt wird, gelten die Nutzungsbedingungen des PowerShell-Katalogs für das Paket. Weitere Informationen finden Sie in den Nutzungsbedingungen.

  • Symbol: Ein Link wird bei Modulen im Abschnitt PrivateData\PSData des Modulmanifests durch Angabe eines IconURI bereitgestellt. Der URI sollte auf ein Bild der Größe 85 × 85 mit transparentem Hintergrund verweisen. Der URI muss ein direkter Link zu der Bilddatei sein und darf nicht zu einer Website oder einer Datei im Paket für den PowerShell-Katalog führen.

Die folgende Liste enthält die Benutzeroberflächenelemente der Paketseiten im PowerShell-Katalog, die durch kommentarbasierte Metadaten in einer Skriptdatei gesteuert werden.

  • Titel: Dies ist der Name des Pakets, das im Katalog veröffentlicht wurde.

  • Version: Die angezeigte Version besteht aus der Versionszeichenfolge in den Metadaten und falls angegeben der Vorabversionsbezeichnung. Der Wert stammt aus dem Schlüsselwort .VERSION im Kommentarblock der Metadaten. Fügen Sie beim Veröffentlichen eines Vorabversionsskripts die Vorversionszeichenfolge an die Version an. Weitere Informationen zum Angeben von Vorabversionszeichenfolgen in Modulen finden Sie unter Vorabskriptversionen.

  • Beschreibung: Diese Informationen stammen aus dem Schlüsselwort .DESCRIPTION in der kommentarbasierten Hilfe einer Skriptdatei.

  • Lizenzakzeptanz erforderlich : Die Lizenzakzeptanz wird für Skripts nicht unterstützt. Das Szenario, in dem ein Skript von einem Modul abhängt, das die Zustimmung zur Lizenz erfordert, wird jedoch unterstützt. Weitere Informationen finden Sie unter Erforderliche Zustimmung zur Lizenz für Skripts.

  • Versionshinweise: Diese Informationen stammen aus dem Schlüsselwort .RELEASENOTES in den kommentarbasierten Metadaten einer Skriptdatei.

  • Besitzer: Unter „Besitzer“ befindet sich die Liste der Benutzer*innen im PowerShell-Katalog, die ein Paket aktualisieren können. Die Liste der Besitzer*innen ist nicht im Paketmanifest enthalten. Weitere Informationen finden Sie unter Verwalten von Paketbesitzern.

  • Autor: Diese Informationen stammen aus dem Schlüsselwort .AUTHOR in den kommentarbasierten Metadaten einer Skriptdatei. Das Feld „Autor“ wird häufig verwendet, um ein Unternehmen oder eine Organisation anzugeben, das bzw. die einem Paket zugeordnet ist.

  • Copyright: Diese Informationen stammen aus dem Schlüsselwort .COPYRIGHT in den kommentarbasierten Metadaten einer Skriptdatei.

  • Dateiliste: Die Dateiliste wird erstellt, wenn das Paket im PowerShell-Katalog veröffentlicht wird. Sie kann nicht durch die Manifestinformationen gesteuert werden. Der PowerShell-Katalog erstellt eine .nuspec-Datei, die in der Dateiliste jedes Pakets angezeigt wird. Diese Datei wird nicht zusammen mit dem Paket auf einem System installiert. Sie stellt das NuGet-Paketmanifest für das Paket dar und kann ignoriert werden.

  • Tags: Diese Informationen stammen aus dem Schlüsselwort .TAGS in den kommentarbasierten Metadaten einer Skriptdatei. Für Tags gelten spezielle Anforderungen und Bedeutungen, die weiter unten im Abschnitt Tagdetails erläutert werden.

  • PowerShell-Editionen: Für Module, die für PowerShell 5.0 und früher entwickelt wurden, wird dies mithilfe von Tags gesteuert. Bei Desktop wird das Tag „PSEdition_Desktop“ und bei Core das „Tag PSEdition_Core“ verwendet. Bei Modulen, die für PowerShell 5.1 oder höher entwickelt wurden, ist im Hauptmanifest der Schlüssel CompatiblePSEditions enthalten. Weitere Informationen finden Sie unter Module mit kompatiblen PowerShell-Editionen.

  • Versionsverlauf: Dieses Element zeigt eine Liste der Versionen des Moduls an, die im Katalog veröffentlicht wurden. Pakete, die mit dem Feature Löschen ausgeblendet wurden, werden nur im Versionsverlauf angezeigt, wenn Sie Paketbesitzer*in sind.

  • Projektwebsite: Diese Informationen stammen aus dem Schlüsselwort .PROJECTURI in den kommentarbasierten Metadaten einer Skriptdatei.

  • Lizenz: Diese Informationen stammen aus dem Schlüsselwort .LICENSEURI in den kommentarbasierten Metadaten einer Skriptdatei.

    Wichtig

    Wenn eine Lizenz nicht über den .LICENSEURI oder innerhalb des Pakets bereitgestellt wird, gelten die Nutzungsbedingungen des PowerShell-Katalogs für das Paket. Weitere Informationen finden Sie in den Nutzungsbedingungen.

  • Symbol: Diese Informationen stammen aus dem Schlüsselwort .ICONURI in den kommentarbasierten Metadaten einer Skriptdatei. Der URI sollte auf ein Bild der Größe 85 × 85 mit transparentem Hintergrund verweisen. Der URI muss ein direkter Link zu der Bilddatei sein und darf nicht zu einer Website oder einer Datei im Paket für den PowerShell-Katalog führen.

Bearbeiten von Paketdetails

Auf der Seite zur Paketbearbeitung im PowerShell-Katalog können Herausgeber einige der für ein Paket angezeigten Felder ändern. Dies gilt insbesondere für folgende:

  • Titel
  • BESCHREIBUNG
  • Zusammenfassung
  • Symbol-URL
  • URL der Projektstartseite
  • Authors
  • Copyright
  • `Tags`
  • Versionshinweise
  • Lizenz erforderlich

Sie sollten diese Informationen nur im Katalog bearbeiten, um zu korrigieren, was für eine ältere Version eines Moduls angezeigt wird. Benutzer*innen, die das Paket herunterladen, werden erkennen, dass die Metadaten nicht mit dem PowerShell-Katalog übereinstimmen. Wenn Sie Informationen im Katalog ändern, sollten Sie eine neue Version des Pakets mit denselben Änderungen veröffentlichen.

Tagdetails

Tags sind einfache Zeichenfolgen, mit denen Consumer Pakete suchen. Tags sind besonders wertvoll, wenn sie in verwandten Paketen einheitlich verwendet werden. Die Verwendung verschiedener Varianten des gleichen Worts (z. B. „Datenbank“ und „Datenbanken“ oder „Test“ und „Tests“) bietet keinen großen Nutzen. Bei Tags handelt es sich um Zeichenfolgen aus einzelnen Wörtern, bei denen die Groß-/Kleinschreibung nicht berücksichtigt wird und die keine Leerzeichen enthalten dürfen. Ausdrücke, die möglicherweise von Benutzer*innen gesucht werden, können der Paketbeschreibung hinzugefügt werden, damit sie in den Suchergebnissen aufgeführt werden. Verwenden Sie die Pascal-Schreibweise, Bindestriche, Unterstriche oder Punkte, um die Lesbarkeit zu verbessern. Erstellen Sie keine langen, komplizierten oder ungewöhnlichen Tags, da diese falsch geschrieben werden könnten.

Beim PowerShell-Katalog und den PowerShellGet-Cmdlets haben die Tags PSEdition_Desktop und PSEdition_Core eine besondere Bedeutung. Weitere Informationen finden Sie in der vorherigen Diskussion zu PowerShell-Editionen.

Wie bereits erwähnt, bieten Tags den größten Nutzen, wenn sie spezifisch sind und über mehrere Pakete hinweg einheitlich verwendet werden. Um herauszufinden, welche Tags am besten geeignet sind, sollten Herausgeber im PowerShell-Katalog nach den von Ihnen in Betracht gezogenen Tags suchen. Idealerweise werden die Pakete zurückgegeben, die mit der Verwendung dieses Schlüsselworts übereinstimmen.

In der folgenden Tabelle sind einige häufig verwendete Tags aufgeführt. Das bevorzugte Tag sollte zu den besten Suchergebnissen führen.

Bevorzugtes Tag Alternativen und Hinweise
ActiveDirectory „AD“ wird derzeit nicht als eigenständiges Wort verwendet.
Appveyor
Automation
AWS
Azure
AzureAD
AzureAutomation
AzureRm Dieses Element wird in erster Linie bei AzureRM-Modulen verwendet.
Backup
Entwickeln
ChatOps
Cloud
Color
Konfiguration
CrescendoBuilt Dieses Tag wird automatisch von Crescendo hinzugefügt, wenn Sie das Modul exportieren.
Datenbank „Databases“ (Plural) ist nicht das bevorzugte Tag.
DBA
Bereitstellung „Deploy“ wird etwas seltener verwendet.
DevOps
DNS
Docker
DSC DesiredStateConfiguration ist nicht das bevorzugte Tag, da es zu lang ist.
DSCResource
DSCResourceKit
Excel
Exchange
Firewall
GIT
GitHub
Gitlab
Google
HTML
Hyper-V „HyperV“ wird seltener als Tag verwendet.
IaaS
IIS
Json
Linux
Log Dies ist die bevorzugte Verwendung eines Protokolls als Objekt.
Protokollierung Dies ist die bevorzugte Verwendung von Protokollierung als Aktion.
MacOS
Überwachung
MSI
Netzwerk „Networking“ weist Ähnlichkeiten auf, wird jedoch seltener verwendet.
Office365 „Office“ sollte vorzugsweise ausgeschrieben werden. „O365“ ist zwar kürzer, wird jedoch seltener verwendet.
PackageManagement
Pester
PoshBot
Bericht „Report“ bezeichnet ein Objekt.
Berichterstellung „Reporting“ bezieht sich auf eine Aktion, während „Report“ ein Objekt bezeichnet.
ResourceManager „Arm“ dient zur Beschreibung einer Prozessorgruppe und sollte nicht im Zusammenhang mit Azure Resource Manager verwendet werden.
REST
Sicherheit „Defense“ ist nicht präzise genug.
SharePoint
SQL
SQLServer
Storage
Test „Tests“ ist nicht das bevorzugte Tag.
VersionControl „Version“ ist nicht präzise genug, obwohl es häufiger verwendet wird.
VSTS
Windows
WinRM
WMI
Zip