Häufig gestellte Fragen zum PowerShell-Katalog

Ein PowerShell-Modul ist ein wiederverwendbares Paket, das einige PowerShell-Funktionen enthält. In PowerShell kann alles (Funktionen, Variablen, DSC-Ressourcen usw.) in Module verpackt werden. Üblicherweise sind Module Ordner, die bestimmte Dateitypen in einem bestimmten Pfad enthalten. Es gibt verschiedene Typen von PowerShell-Modulen.

Ein PowerShell-Skript ist eine Reihe von Befehlen, die in einer PS1-Datei gespeichert sind, um die Wiederverwendung und Freigabe zu ermöglichen. PowerShell-Workflows sind auch PowerShell-Skripts, die eine Reihe von Aufgaben zeigen und Sequenzierungen für diese Aufgaben bereitstellen. Weitere Informationen finden Sie unter Einführung in Windows PowerShell Workflow.

In der Regel sind Module besser für das Teilen, aber wir ermöglichen die Skriptfreigabe, damit Sie Workflows und Skripts leichter zur Community beitragen können. Weitere Informationen finden Sie auf den folgenden Blogs:

• Schreiben Sie keine Skripts, schreiben Sie PowerShell-Module (in englischer Sprache)
• Grundlegendes zu PowerShell-Modulen (in englischer Sprache)

Sie müssen ein Konto im PowerShell-Katalog erstellen, bevor Sie Pakete im Katalog veröffentlichen können. Das liegt daran, dass zum Veröffentlichen von Paketen NuGetApiKey erforderlich ist. Der entsprechende Wert wird bei der Registrierung bereitgestellt. Verwenden Sie zum Registrieren und Anmelden im PowerShell-Katalog Ihr persönliches, Geschäfts- oder Schulkonto. Ein einmaliger Registrierungsprozess ist erforderlich, wenn Sie sich zum ersten Mal anmelden. Danach ist der NuGet API-Schlüssel auf Ihrer Profilseite verfügbar.

Verwenden Sie, wenn Sie sich im Katalog registriert haben, den Cmdlet Publish-Module oder Publish-Script, um Ihr Paket im Katalog zu veröffentlichen. Weitere Informationen zum Ausführen dieser Cmdlets finden Sie auf der Registerkarte „Veröffentlichen“, oder lesen Sie die Dokumentation zu Publish-Module und Publish-Script.

Sie müssen sich zum Installieren oder Speichern von Paketen nicht im Katalog registrieren oder anmelden.

Die vollständige Fehlermeldung lautet: „Fehler beim Verarbeiten der Anforderung“. „Der angegebene API-Schlüssel ist ungültig oder verfügt nicht über die Berechtigung zum Zugriff auf das angegebene Paket.“. Der Remoteserver hat einen Fehler zurückgegeben: (403) Forbidden.“

Dieser Fehler kann aus den folgenden Gründe auftreten:

• Der angegebene API-Schlüssel ist ungültig. Stellen Sie sicher, dass Sie den gültigen API-Schlüssel Ihres Konto angegeben haben. Den API-Schlüssel finden Sie auf Ihrer Profilseite.
• Der angegebene Paketname gehört Ihnen nicht. Wenn Sie Ihren API-Schlüssel überprüft haben und er korrekt ist, existiert möglicherweise bereits ein Paket mit dem gleichen Namen wie der, den Sie verwenden möchten. Möglicherweise hat der Besitzer festgelegt, dass das Paket nicht aufgelistet wird. In diesem Fall wird es in keinen Suchergebnissen angezeigt. Öffnen Sie einen Browser, und navigieren Sie zur Seite „Paketdetails“, um festzustellen, ob bereits ein Paket mit dem gleichen Namen vorhanden ist: https://www.powershellgallery.com/packages/<packageName>. Navigieren Sie z.B. direkt zu https://www.powershellgallery.com/packages/pester, gelangen Sie zur Detailseite des Pester-Moduls, unabhängig davon, ob es aufgeführt ist oder nicht. Wenn bereits ein Paket mit einem einen Konflikt verursachenden Namen vorhanden ist und nicht aufgelistet wird, haben Sie die folgenden Optionen:
  • Einen anderen Namen für das Paket auswählen
  • Die Besitzer des vorhandenen Pakets kontaktieren

Bitte bedenken Sie, dass Ihr Katalog-Konto keine Änderungen an Ihrem primären E-Mail-Alias übernimmt. Weitere Informationen finden Sie im Microsoft Verwalten von Aliasen für Ihr Microsoft-Konto.

Wenn Sie ein Kontrollkästchen unter „Kategorie“ auswählen, werden alle Pakete in dieser Kategorie angezeigt. Dies gilt allerdings nur für die Pakete in den Kategorien, die Sie ausgewählt haben. Um alle Pakete in allen Kategorien anzuzeigen, müssen Sie alle Kontrollkästchen unter „Kategorie“ auswählen. Einige Pakete im Katalog gehören jedoch nicht zu den aufgeführten Kategorien und werden folglich nicht in den Ergebnissen angezeigt. Deaktivieren Sie zum Anzeigen aller Pakete im Katalog alle „Kategorien“, oder wählen Sie die Registerkarte „Pakete“ erneut aus.

Jede Art von PowerShell-Modul (Skriptmodule, binäre Module oder Manifestmodule) können im Katalog veröffentlicht werden. PowerShellGet benötigt zum Veröffentlichen einige Informationen über das Modul, wie z.B. Version, Beschreibung, Autor und Lizenzierung. Diese Informationen werden im Rahmen des Veröffentlichungsprozesses in der Modulmanifest-Datei (.psd1) oder aus dem Wert des LicenseUri-Parameter des Cmdlets Publish-Module gelesen. Alle im Katalog veröffentlichten Module müssen über Modulmanifeste verfügen. Jedes Modul, das die folgenden Informationen in seinem Manifest enthält, kann im Katalog veröffentlicht werden:

• Version
• Beschreibung
• Autor
• Ein URI zu den Lizenzbedingungen des Moduls, entweder als Teil des PrivateData-Abschnitts des Manifests oder im LicenseUri-Parameter des Cmdlets Publish-Module.

Die einfachste Möglichkeit, ein Modulmanifest zu erstellen, ist die Ausführung des Cmdlets New-ModuleManifest. In PowerShell 5.0 oder höher, generiert New-ModuleManifest eine korrekt formatiertes Modulmanifest mit leeren Feldern für nützliche Metadaten wie ProjectUri, LicenseUri und Tags. Tragen Sie einfach etwas in die leeren Felder ein, oder verwenden Sie das generierte Manifest als Beispiel für die richtige Formatierung.

Verwenden Sie das Cmdlet Test-ModuleManifest, um zu überprüfen, ob alle erforderlichen Metadatenfelder ordnungsgemäß ausgefüllt wurden.

Verwenden Sie das Cmdlet Update-ModuleManifest, um die Felder der Modulmanifestdatei zu aktualisieren.

Jede Art von PowerShell-Skript (Skripts oder Workflows) kann im Katalog veröffentlicht werden. PowerShellGet benötigt zum Veröffentlichen einige Informationen über das Skript, wie z.B. Version, Beschreibung, Autor und Lizenzierung. Diese Informationen werden im Rahmen des Veröffentlichungsprozesses aus dem Abschnitt PSScriptInfo der Skriptdatei oder aus dem Wert des LicenseUri-Parameters des Cmdlets Publish-Script gelesen. Alle im Katalog veröffentlichten Skripts müssen Metadateninformationen besitzen. Jedes Skript, das die folgenden Informationen im Abschnitt „PSScriptInfo“ enthält, kann im Katalog veröffentlicht werden:

• Version
• Beschreibung
• Autor
• Ein URI zu den Lizenzbedingungen des Skripts, entweder als Teil des Abschnitts PSScriptInfo des Skripts oder im LicenseUri-Parameter des Cmdlets Publish-Script.

Geben Sie das gesuchte Thema in das Textfeld ein. Wenn Sie z.B. Module im Zusammenhang mit Azure SQL suchen, geben Sie einfach „Azure SQL“ ein. Die Suchmaschine sucht dann in allen veröffentlichten Paketen nach diesen Schlüsselwörtern, einschließlich Titel und Beschreibungen, sowie in allen Metadaten. Anschließend werden auf Grundlage einer gewichteten Qualitätsbewertung die besten Ergebnisse angezeigt. Sie können auch nach bestimmten Feldern der folgenden Feldtypen suchen, indem Sie die Syntax „Feld:"Wert"“ in der Suchabfrage verwenden:

• `Tags`
• Functions
• Cmdlets
• DscResources
• PowerShellVersion

Wenn Sie beispielsweise nach „PowerShellVersion:"2.0"“ suchen, werden die Ergebnisse angezeigt, die (basierend auf dem Modul-/Skriptmanifest) mit PowerShell Version 2.0 kompatibel sind.

Am einfachste Weg, eine korrekt formatierte Skriptdatei zu erstellen, ist das Cmdlet New-ScriptFileInfo auszuführen. In PowerShell 5.0 generiert New-ScriptFileInfo eine korrekt formatierte Skriptdatei mit leeren Feldern für nützliche Metadaten wie ProjectUri, LicenseUri und Tags. Tragen Sie einfach etwas in die leeren Felder ein, oder verwenden Sie das generierte Skript als Beispiel für die richtige Formatierung.

Verwenden Sie das Cmdlet Test-ScriptFileInfo, um zu überprüfen, ob alle erforderlichen Metadatenfelder ordnungsgemäß ausgefüllt wurden.

Verwenden Sie das Cmdlet Update-ScriptFileInfo, um die Metadatenfelder des Skripts zu aktualisieren.

Der Begriff „PowerShell-Modul“ bezieht sich auch auf die Dateien, die die eigentliche Funktionalität implementieren. Skriptmoduldateien (.psm1) enthalten PowerShell-Code. Binäre Moduldateien (.dll) enthalten kompilierten Code.

Sie können sich dies wie folgt vorstellen: Der Ordner, der das Modul kapselt, ist der Modulordner. Die Modulordner kann ein Modulmanifest (.psd1) enthalten, das den Inhalt des Ordners beschreibt. Die Dateien, die die eigentliche Arbeit ausführen, sind die Skriptmoduldateien (.psm1) und die binären Moduldateien (.dll). Die DSC-Ressourcen befinden sich in einem bestimmten Unterordner und werden als Skriptmoduldateien oder binäre Moduldateien implementiert.

Alle Module im Katalog enthalten Modulmanifeste, und die meisten dieser Module enthalten Skriptmoduldateien oder binäre Moduldateien. Der Begriff „Modul“ kann aufgrund dieser verschiedenen Bedeutungen verwirren. Alle Verwendungen des Worts „Modul“ auf dieser Seite beziehen sich auf den Modulordner mit diesen Dateien, es sei denn, es wird explizit eine andere Bedeutung angegeben.

PackageManagement ist eine allgemeine Schnittstelle für die Arbeit mit einem beliebigen Paket-Manager. Unabhängig davon, ob Sie mit PowerShell-Modulen, MSIs, RubyGems, NuGet-Paketen oder Perl-Modulen arbeiten, sollten Sie PackageManagement-Befehle (Find-Package und Install-Package) verwenden können, um sie suchen und installieren zu können. PackageManagement regelt dies mithilfe eines eigenen Paketanbieters für jeden Paket-Manager, der an PackageManagement eingebunden ist. Anbieter verrichten die eigentliche Arbeit: Sie rufen Inhalte aus Repositorys ab und installieren die Inhalte lokal. Häufig umschließen Paketanbieter einfach die vorhandenen Paket-Manager-Tools für einen gegebenen Paket.

PowerShellGet ist der Paket-Manager für PowerShell-Pakete. Es gibt einen Anbieter von PSModule-Paketen, der die PowerShellGet-Funktionalität über PackageManagement verfügbar macht. Sie können daher entweder Install-Module oder Install-Package -Provider PSModule ausführen, um ein Modul aus dem PowerShell-Katalog zu installieren. Auf bestimmte PowerShellGet-Funktionen, einschließlich Update-Module und Publish-Module, kann nicht über PackageManagement-Befehle zugegriffen werden.

Alles in allem bietet PowerShellGet eine erstklassige Schnittstelle zur Paketverwaltung für PowerShell-Inhalte. PackageManagement dient der Bereitstellung aller Schnittstellungen zur Paketverwaltung mithilfe einiger allgemeiner Tools. Wenn Ihnen diese Antwort nicht geholfen hat, finden Sie eine ausführlichere Hilfestellung am Ende dieses Texts im Abschnitt Wie beziehen sich PackageManagement und PowerShellGet tatsächlich aufeinander?.

Weitere Informationen finden Sie auf der Projektseite zu PackageManagement.

Der PowerShell-Katalog ist eine geänderte Version des NuGet-Katalogs. PowerShellGet verwendet den NuGet-Anbieter, um mit NuGet-basierten Repositorys wie dem PowerShell-Katalog zu arbeiten.

Sie können PowerShellGet für jedes gültige NuGet-Repository oder jede gültige NuGet-Dateifreigabe verwenden. Hierzu müssen Sie das Repository einfach mithilfe des Cmdlets Register-PSRepository hinzufügen.

Ja.

PowerShellGet nutzt im Hintergrund stark die PackageManagement-Infrastruktur.

Auf der Ebene der PowerShell-Cmdlets ist Install-Module ein einfacher Wrapper um Install-Package -Provider PSModule.

Auf der Ebene des PackageManagement-Paketanbieters ruft der PSModule-Paketanbieter andere PackageManagement-Paketanbieter auf. Wenn Sie beispielsweise mit NuGet-basierten Katalogen arbeiten(z.B. dem PowerShell-Katalog), verwendet der PSModule-Paketanbieter den NuGet-Paketanbieter, um mit dem Repository zu arbeiten.

Abbildung 1: PowerShellGet-Architektur

Im Allgemeinen wird empfohlen, die neueste Version des PowerShellGet-Moduls auszuwählen (beachten Sie, dass .NET Version 4.5 notwendig ist).

Für das PowerShellGet-Modul ist PowerShell 3.0 oder neuer erforderlich.

Aus diesem Grund erfordert PowerShellGet eines der folgenden Betriebssysteme:

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

Für PowerShellGet ist außerdem .NET Framework 4.5 oder höher erforderlich. Weitere Informationen finden Sie unter Installieren von .NET Framework für Entwickler.

Es ist nicht möglich, Paketnamen zu reservieren. Wenn Sie der Meinung sind, dass ein vorhandenes Paket einen Namen trägt, der besser zu Ihrem Paket passt, wenden Sie sich an den Besitzer des Pakets. Wenn Sie innerhalb einiger Wochen keine Antwort erhalten, können Sie den Support kontaktieren, und das Team für den PowerShell-Katalog prüft die Angelegenheit.

Weitere Informationen finden Sie unter Verwalten von Paketbesitzern auf PowerShellGallery.com.

Wir möchten die Zusammenarbeit in der PowerShell-Community fördern, um Streitigkeiten beizulegen, die ggf. zwischen Paketbesitzern auftreten. Wir haben einen Prozess zur Beilegung von Streitigkeiten entworfen, und bitten Sie, diesen zu befolgen, bevor die Administratoren von PowerShellGallery.com eingeschaltet werden.