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:
Vom Modulmanifest gesteuerte Elemente von PowerShell-Katalogfeatures
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 namenslicense.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.
Durch Skriptmetadaten gesteuerte Elemente der PowerShell-Katalogfeatures
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 | |
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 |
PowerShell Gallery