Adam der Automator

Die Arbeit mit PowerShell-Modulen ist ein wichtiger Bestandteil der PowerShell-Automatisierung. Wenn Sie mit dem Erlernen der PowerShell beginnen, sind die ersten Schritte in der Regel die Verwendung einzelner Befehle. Dies führt zur Erstellung von Skripts, die dann zur Erstellung von Funktionen führen.

Durch die Verwendung von Funktionen können Sie Ihre Skripts modularer gestalten. So können Sie denselben Code an vielen Stellen verwenden, ohne ihn überall kopieren und einfügen zu müssen. Durch die Verwendung von Funktionen müssen Sie weniger Zeit aufwenden, um denselben Code überall zu bearbeiten, wo er verwendet wird. Stattdessen können Sie Ihren Code an einer einzigen Stelle verbessern.

Um Funktionen auf die nächste Stufe zu heben, können Sie diese Funktionen in einem Modul zusammenfassen.

Ein Modul ist eine Sammlung von Funktionen in einer Textdatei mit der Erweiterung psm1. Es gibt einige optionale Zusätze, wie ein Modulmanifest und eine kommentargestützte oder externe Hilfe, die ebenfalls enthalten sein können. Diese werden später behandelt.

Voraussetzungen

In diesem Artikel werde ich Windows PowerShell 5.1 verwenden. Wenn Sie eine ältere Version oder PowerShell Core verwenden, können die Ergebnisse unterschiedlich ausfallen.

Interaktion mit Modulen

Wenn Sie zum ersten Mal eine PowerShell-Sitzung öffnen, werden Sie mit zwei Modulen beginnen. Das erste ist Microsoft.PowerShell.Utility, das viele grundlegende PowerShell-Funktionen enthält, die Sie bereits verwenden. Das andere Modul ist PSReadline. Sie können diese Startmodule mit dem Befehl Get-Module anzeigen.

Das ist jedoch keine vollständige Liste aller verfügbaren Module. Seit PowerShell 3 werden die installierten Module bei Bedarf importiert. Wenn Sie eine ältere Version von PowerShell verwenden, müssen Sie den Befehl Import-Module verwenden, um das Modul zuerst zu importieren, bevor Sie einen der Befehle verwenden können.

Es gibt Fälle, in denen Sie Import-Module auch in späteren Versionen noch verwenden möchten. Wenn Sie ein Modul importieren möchten, nachdem es bereits installiert ist, können Sie Import-Module wie folgt verwenden:

Während Get-Module alle importierten Module anzeigt, sehen Sie keine Module, die noch nicht importiert wurden. Sie können dann den Parameter ListAvailable verwenden, um alle anderen verfügbaren Module anzuzeigen.

Standardmäßig werden nicht alle Befehle angezeigt

Die Eigenschaft ExportedCommands enthält eine Liste aller verfügbaren Befehle, die aus dem Modul exportiert werden. Diese Liste unterscheidet sich möglicherweise von der in der Moduldatei enthaltenen Liste. Exportierte Befehle ist eine in das Modulmanifest integrierte Funktion, die es dem Autor ermöglicht, eine Funktion als verborgen zu kennzeichnen. Modulautoren können auch das Cmdlet Export-ModuleMember verwenden, aber das liegt außerhalb des Rahmens dieses Artikels.

Modulautoren möchten möglicherweise eine Funktion ausblenden, weil sie andere Funktionen unterstützen soll und nicht für den Benutzer sichtbar ist. Um eine Funktion auszublenden, würde der Autor sie aus dem FunctionsToExport Array im Manifest ausschließen. Hier sehen Sie eine erweiterte Ansicht der ExportedCommands-Eigenschaft.

Importieren von Modulen

Es gibt viele Möglichkeiten, Module zu verwenden. Sie können das Modul manuell importieren, indem Sie den Pfad zu den Moduldateien angeben. Dadurch können Sie das Modul testen und aktualisieren, ohne viel Arbeit zu haben. Allerdings ist die Portabilität nicht sehr groß, da Sie den genauen Pfad zum Modul verwenden müssen. PowerShell importiert auch keine Module automatisch, die nicht in der $env:PSModulePath-Variable enthalten sind.

Selektives Importieren von Befehlen

Mit dem Parameter Function können Sie Import-Module verwenden, um nur bestimmte Funktionen statt des gesamten Moduls zu importieren. Dies kann beim Importieren von Modulen aus Remote-Systemen, wie z. B. den Office 365-Modulen, Zeit sparen.

Alle Benutzermodule

Module, die für alle Benutzer installiert werden, werden in C:\Programme\WindowsPowerShell\Module abgelegt. Dieses Verzeichnis enthält viele vorab hinzugefügte Module, einschließlich aller Module, die mit Install-Module unter Verwendung des Standardbereichs AllUsers installiert wurden.

Aktuelle Benutzermodule

Wenn Sie ein Modul installieren, es aber nur von einem einzigen Benutzer verwendet werden soll, gibt es einen CurrentUser-Bereich. Dadurch werden die Moduldateien in Ihrem Dokumentenordner unter C:\Benutzer\<Benutzername>\Dokumente\WindowsPowerShell\Module abgelegt. Dies kann in einer Umgebung nützlich sein, in der Sie eine Ordnerumleitung mit dem Ordner „Dokumente“ verwenden.

In diesem Fall können Sie ein Modul auf einem Computer installieren und es auf einem anderen Computer verwenden, da beide denselben Dokumentenordner verwenden.

Systemmodule

Der Vollständigkeit halber gibt es auch ein Modulverzeichnis unter C:\Windows\System32\WindowsPowerShell\1.0\Modules. Technisch gesehen würde ein Modul, das sich in diesem Pfad befindet, wie einer der anderen Pfade importiert werden, aber es wird nicht empfohlen, da dieser Pfad für Microsofts Systemmodule reserviert ist.

Die Benennung ist wichtig

Sie können Ihr Modul manuell in einem dieser Pfade ablegen, um es standardmäßig mit einer neuen Sitzung verfügbar zu machen, aber Sie müssen sicherstellen, dass Sie die erforderliche Benennung für Module befolgen. Der Ordner, in dem die Moduldateien abgelegt werden, muss denselben Namen tragen wie die psm1-Moduldatei und das psd1-Modulmanifest, falls vorhanden.

Die Verwendung von Get-Module -ListAvailable, die wir bereits erwähnt hatten, verweist auf diese Pfade. Sie können alle Modulpfade mit $env:PSModulePath -Split ';' sehen. Möglicherweise sehen Sie in der Liste andere Pfade als die hier gezeigten. Viele Programme fügen ihre eigenen Modulpfade hinzu, wenn sie installiert werden. Ein Beispiel dafür ist SQL, das seine eigenen Module in eigenen Modulpfaden enthält.

Es gibt auch einige Module, die Sie mit einem anderen Prozess installieren würden. Eines der wichtigsten Beispiele dafür ist das ActiveDirectory-Modul. Von Windows 7 bis Windows 10 1803 installieren Sie es mit dem Installationsprogramm der Remote Server Administration Tools (RSAT).

Bei neueren Versionen von Windows 10 (1809+) ist es nur noch über die Features On Demand verfügbar. Durch die Installation von RSAT werden die ActiveDirectory-Module und viele andere Module installiert, die Sie zur Verwaltung anderer Windows-Rollen verwenden würden. Auf Windows-Server-Betriebssystemen werden diese Module über den Server Manager installiert.

Importieren von Remote-Modulen (Implizites Remoting)

Es gibt einige Fälle, in denen es nicht praktisch ist, ein Modul lokal auszuführen. Stattdessen ist es besser, eine Verbindung zu einem entfernten Gerät herzustellen und ein darauf installiertes Modul zu importieren. In diesem Fall werden die Befehle tatsächlich auf dem entfernten Rechner ausgeführt. Dies wird häufig bei den Office 365-Modulen von Microsoft verwendet. Viele von ihnen stellen eine Verbindung zu einem Office 365-Server her, der dann ein Modul importiert. Wenn Sie einen der Befehle ausführen, werden sie auf dem Remoteserver ausgeführt und die Ausgabe wird dann an Ihre Sitzung zurückgesendet.

Eine andere Verwendung des Imports von Remote-Modulen ist, wenn Sie das Modul nicht lokal installiert haben. So sieht es aus, wenn Sie das ActiveDirectory-Modul nicht installiert haben, aber versuchen, es zu importieren.

Um ein Remote-Modul zu importieren, müssen Sie zunächst eine PSSession erstellen. Sie können New-PSSession verwenden, um die Sitzung zu erstellen. Anschließend importieren Sie das auf dem entfernten Gerät verfügbare Modul über den PSSession-Parameter mit Import-Module.

PS51> $AdminServer = New-PSSession -ComputerName $AdminServerName -Credential (Get-Credential)PS51> Import-Module -Name ActiveDirectory -PSSession $AdminServer -Prefix 'Rmt'

Die Verwendung dieser Methode zum Importieren entfernter Module ermöglicht eine schnellere Codeausführung in einer verteilten Umgebung. Wenn Sie beispielsweise von Ihrem Computer aus arbeiten, die Server, an denen Sie arbeiten, sich aber auf der anderen Seite der USA befinden, kann es erheblich länger dauern, bestimmte Befehle lokal auf den Servern auszuführen. Die Ausführung der Befehle auf einem Server und die Rückführung der Ausgabe in Ihre lokale Sitzung ist dagegen viel schneller.

Hinzufügen eines Modulpräfixes

Sie können auch ein Präfix für die vom entfernten Rechner importierten Funktionen hinzufügen. Diese Option steht beim Importieren lokaler Module zur Verfügung, wird aber nur selten verwendet, wenn man nicht gerade verschiedene Versionen eines Moduls nebeneinander testet.

Wenn Sie den obigen Import-Befehl ausführen würden, würden Sie folgende Befehle sehen:

In diesem Fall können Sie ein Präfix verwenden, um anzuzeigen, dass es sich nicht um ein lokales Modul handelt. Dies kann in Fällen verwendet werden, in denen Sie ein Modul importieren, das auch lokal verfügbar ist. Das Hinzufügen des Präfixes verringert die Verwirrung darüber, wo der Code ausgeführt wird.

Entfernen von Modulen

Sie können ein Modul auch aus der aktuellen Sitzung entfernen, ohne Remove-Module zu verwenden. Dadurch wird ein Modul aus der lokalen Sitzung entfernt, ohne die Moduldateien zu entfernen. Dies kann sinnvoll sein, wenn Sie ein Modul in einer entfernten Sitzung verwenden. Sie könnten Remove-Module verwenden, um Ihre Sitzung zu bereinigen und dann die Remote-Sitzung zu trennen.

Eine andere Verwendung von Remove-Module ist, wenn Sie Änderungen an einem Modul vornehmen und keine neue PowerShell-Sitzung starten möchten. In diesem Fall würden Sie Remove-Module gefolgt von Import-Module verwenden, um das Modul erneut in Ihre Sitzung zu laden. Alternativ können Sie auch den Parameter Force mit Import-Module verwenden. Dadurch wird das Entladen und Neuladen des Moduls für Sie abgeschlossen.

Was ein PowerShell-Modul ausmacht

Ein Modul kann aus einer oder mehreren Dateien bestehen. Um die Mindestanforderungen für ein Modul zu erfüllen, müssen Sie eine Moduldatei haben. Dies kann eine PSM1-Datei oder eine beliebige andere Moduldatei sein, z. B. eine binäre Moduldatei. Darauf aufbauend sollten in Ihrer PSM1-Datei Funktionen definiert sein, sonst ist sie für niemanden von Nutzen.

Es gibt zwar keine Anforderungen, wie die Funktionen aussehen oder was sie tun sollten, aber es gibt einige Richtlinien. In der Regel wird bevorzugt, dass alle Funktionen in einem Modul auf demselben Konzept aufbauen.

Module enthalten gleichartige Funktionen

Das Modul ActiveDirectory enthält beispielsweise nur Funktionen, die in irgendeiner Weise mit Active Directory interagieren. Normalerweise enthalten die Funktionsnamen auch ein Präfix. Wenn Sie das ActiveDirectory-Modul als Beispiel nehmen, beginnen alle Substantive in den Funktionsnamen mit AD.

Die Verwendung dieser Richtlinien erleichtert die Auffindbarkeit der Funktionen. Stellen Sie sich vor, Sie haben dieses neue Modul gerade importiert und wollen die Funktionen mit der Tabulatortaste durchgehen. Das ist viel einfacher, wenn alle Funktionen eine ähnliche Namensstruktur haben. Auch wenn Sie häufig sehen, dass Module mit PS beginnen, ist dieses Präfix offiziell nur für Microsoft-Module reserviert. Wenn Sie PS am Anfang Ihres Moduls verwenden, werden Sie wahrscheinlich kein Problem verursachen, aber Sie könnten einen Konflikt mit einem anderen Modulnamen erzeugen.

Wenn Sie diese Richtlinien anwenden, könnten Sie bei einer Reihe von Funktionen, die alle mit der Interaktion mit der Registrierung zu tun haben, etwas wie folgt haben:

function Get-ATARegistryKey {...}function Set-ATARegistryKey {...}

Modulmanifeste

Um auf der Textmoduldatei aufzubauen, können Sie auch ein Modulmanifest einfügen. Diese Dateien haben eine PSD1-Erweiterung und enthalten Metadaten über das Modul. Hier finden Sie Informationen über den Autor, die Beschreibung des Moduls, andere erforderliche Module und viele andere Attribute. Für die Veröffentlichung in einem Repository müssen die Felder Author und Description ausgefüllt sein.

Hier ein Beispiel für ein Manifest, das wir für unser Registrierungsmodul haben könnten:

#Module manifest for module 'ATARegistry'#Generated by: Tyler#Generated on: 8/11/2019@{#Script module or binary module file associated with this manifest.RootModule = 'ATARegistry'#Version number of this module.ModuleVersion = '1.0'#Supported PSEditions#CompatiblePSEditions = @()#ID used to uniquely identify this moduleGUID = 'fef619fa-016d-4b11-a09d-b222e094de3e'#Author of this moduleAuthor = 'Tyler Muir'#Company or vendor of this moduleCompanyName = 'Adam the Automator'#Copyright statement for this moduleCopyright = '(c) 2019 tyler. All rights reserved.'#Description of the functionality provided by this moduleDescription = 'This is a test module.'#Minimum version of the Windows PowerShell engine required by this module#PowerShellVersion = ''#Name of the Windows PowerShell host required by this module#PowerShellHostName = ''#Minimum version of the Windows PowerShell host required by this module#PowerShellHostVersion = ''#Minimum version of Microsoft .NET Framework required by this module. This prerequisite is valid for the PowerShell Desktop edition only.#DotNetFrameworkVersion = ''#Minimum version of the common language runtime (CLR) required by this module. This prerequisite is valid for the PowerShell Desktop edition only.#CLRVersion = ''#Processor architecture (None, X86, Amd64) required by this module#ProcessorArchitecture = ''#Modules that must be imported into the global environment prior to importing this module#RequiredModules = @()#Assemblies that must be loaded prior to importing this module#RequiredAssemblies = @()#Script files (.ps1) that are run in the caller's environment prior to importing this module.#ScriptsToProcess = @()#Type files (.ps1xml) to be loaded when importing this module#TypesToProcess = @()#Format files (.ps1xml) to be loaded when importing this module#FormatsToProcess = @()#Modules to import as nested modules of the module specified in RootModule/ModuleToProcess#NestedModules = @()#Functions to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no functions to export.FunctionsToExport = @('Get-RegistryKey','Set-RegistryKey')#Cmdlets to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no cmdlets to export.CmdletsToExport = @()#Variables to export from this moduleVariablesToExport = '*'#Aliases to export from this module, for best performance, do not use wildcards and do not delete the entry, use an empty array if there are no aliases to export.AliasesToExport = @()#DSC resources to export from this module#DscResourcesToExport = @()#List of all modules packaged with this module#ModuleList = @()#List of all files packaged with this module#FileList = @()#Private data to pass to the module specified in RootModule/ModuleToProcess. This may also contain a PSData hashtable with additional module metadata used by PowerShell.PrivateData = @{PSData = @{#Tags applied to this module. These help with module discovery in online galleries.#Tags = @()#A URL to the license for this module.#LicenseUri = ''#A URL to the main website for this project.#ProjectUri = ''#A URL to an icon representing this module.#IconUri = ''#ReleaseNotes of this module#ReleaseNotes = ''} #End of PSData hashtable} #End of PrivateData hashtable#HelpInfo URI of this module#HelpInfoURI = ''#Default prefix for commands exported from this module. Override the default prefix using Import-Module -Prefix.#DefaultCommandPrefix = ''}

Auch wenn dies auf den ersten Blick einschüchternd wirken mag, bietet Microsoft ein praktisches Cmdlet, mit dem Sie ein Modulmanifest erstellen können. Der enthaltene Befehl lautet New-ModuleManifest. Um das oben gezeigte Manifest zu generieren, könnten Sie Folgendes verwenden:

PS51> New-ModuleManifest -Path .\Scripts\TestModule.psd1 -Author 'Tyler Muir' -CompanyName 'Adam the Automator' -RootModule 'TestModule.psm1' -FunctionsToExport @('Get-RegistryKey','Set-RegistryKey') -Description 'This is a test module.'

Externe Hilfedateien

In einigen Modulen werden auch externe Hilfedateien angezeigt. Sie können durch den <Modulnamen>-Help.xml am Ende des Dateinamens identifiziert werden. Diese externen Hilfedateien enthalten dieselben Informationen, die normalerweise in der befehlsbasierten Hilfe enthalten sind, die Sie in einer Funktionsdefinition finden können.

In diesem Fall müssen Sie auch # .ExternalHelp <ModulePath>-Help.xml zu Ihrer Funktion hinzufügen, damit sie richtig funktioniert, wenn Sie den Befehl Get-Help nach dem Importieren des Moduls verwenden. Externe Hilfedateien sind in der Regel nur bei sehr großen Modulen zu finden und fallen daher nicht in den Anwendungsbereich.

Dies sind zwar die häufigsten Dateitypen, die in einem Modul zu finden sind, aber nicht die einzigen. Manchmal werden Sie neben einem Textmodul auch Binärdateien sehen, da es andere Abhängigkeiten gibt. Wenn Sie die Modulpfade durchsuchen, finden Sie viele Beispiele für zusätzliche Dateitypen in Modulen.

Um nicht standardmäßige Moduldateien ordnungsgemäß zu veröffentlichen, müssen Sie andere Dateien in den FileList-Parameter in Ihrem Modulmanifest aufnehmen.

Im Modulmanifest finden Sie viele andere Parameter, die derzeit leer sind. Sie können diese verwenden, um andere Anforderungen für die Verwendung Ihres Moduls zu definieren. So können Sie beispielsweise die PowerShell-Versionen festlegen, mit denen das Modul arbeiten kann. Wenn Sie versuchen, das Modul mit einer nicht unterstützten Version von PowerShell zu importieren, würden Sie Folgendes sehen:

PSRepositories

Eine der wichtigsten Verteilungsoptionen für Module ist ein PSRepository. Auf 1000′-Sicht ist ein PSRepository ein Ort, an dem mehrere Personen oder mehrere Geräte auf die Moduldateien zugreifen können. Häufig handelt es sich dabei um Webserver, auf denen Sie Dateien veröffentlichen können.

Sie können auch ein Verzeichnis für das Repository verwenden, aber das schränkt Sie in der Funktionalität Ihres Repositorys ein. Sie können ein PSRepository selbst hosten, oder Sie können eine der vielen im Internet verfügbaren Optionen wie die PowerShell Gallery nutzen. Sie können Ihre PSRepositories mit dem Befehl Get-PSRepository anzeigen.

Standardmäßig haben Sie nur einen Eintrag, und zwar für die PowerShell Gallery. Vielleicht fällt Ihnen auf, dass dort „untrusted“ steht. Dies liegt daran, dass PowerShell Sie darauf hinweist, dass Sie bei der Verwendung der PowerShell-Galerie möglicherweise Code verwenden, der nicht von Microsoft geschrieben und genehmigt wurde. Das bedeutet, dass Sie vor der Installation von Modulen aus der Galerie eine ausdrückliche Genehmigung erteilen müssen.

Hinzufügen von PSRepositories

Sie können auch Ihre eigenen Repositories hinzufügen. Um der PowerShell Gallery zu vertrauen, können Sie Get-PSRepository -Name PSGallery | Set-PSRepository -InstallationPolicy Trusted ausführen oder die Warnung akzeptieren, wenn Sie zum ersten Mal ein Modul aus der PowerShell Gallery installieren.

Alle Befehle, die Sie verwenden würden, um mit diesen PSRepositories zu interagieren, befinden sich im PowerShellGet-Modul. Sie können die Funktionen hier sehen:

Das PowerShellGet-Modul muss möglicherweise aktualisiert werden, bevor mit bestimmten Repositorys interagiert werden kann.

Module suchen

Eine weitere wichtige Funktion bei der Verwendung eines PSRepository ist die Möglichkeit, nach Modulen zu suchen. Dies wird mit dem Befehl Find-Module bewerkstelligt. Es gibt mehrere Möglichkeiten zum Filtern, um genau das zu finden, wonach Sie suchen, aber im Moment können Sie nach den VMware-Modulen wie folgt suchen:

Damit werden alle Module angezeigt, die mit VMware beginnen. Die meisten dieser Module stammen von VMware, aber Sie müssen sich das Autorenattribut ansehen, um zu sehen, wer das Modul veröffentlicht hat.

Da jeder in die PowerShell Gallery hochladen kann, sind Tausende von Modulen verfügbar. Dies bedeutet, dass Sie möglicherweise Module finden, die für Ihren Anwendungsfall nicht richtig funktionieren. Viele Module, die Sie finden, sind Open Source, so dass Sie zu ihnen beitragen können, um die Funktionalität des Moduls zu verbessern.

Installieren von Modulen

Um den Befehl Install-Module zu verwenden, müssen Sie ein vertrauenswürdiges PSRepository haben, das das Modul hostet. Dies kann die PowerShell Gallery, ein anderes PSRepository im Internet oder eine selbst gehostete Site sein. Sie können den Befehl Find-Module über die Pipeline verwenden, um das Modul einfach zu bestätigen, bevor Sie es installieren.

Sie können die Version eines Moduls auch mit den Parametern MinimumVersion, MaximumVersion oder RequiredVersion definieren.

Um alle mit Install-Module installierten Module anzuzeigen, können Sie Get-InstalledModule verwenden. Dadurch werden alle Module aufgelistet, die im Bereich AllUsers oder im Bereich CurrentUser installiert sind.

Deinstallieren von Modulen

So wie Sie ein Modul installieren können, können Sie auch ein Modul deinstallieren. Wenn das Modul nicht über den Befehl Install-Module installiert wurde, können Sie es nicht mit dem Befehl Uninstall-Module deinstallieren.

Wie Sie hier sehen können, versuchen wir, das Modul ActiveDirectory zu deinstallieren. Da dieses Modul nicht mit Install-Module installiert wird, würden Sie einen Fehler erhalten, wenn Sie versuchen, Uninstall-Module zu verwenden. Damit Sie dieses Modul deinstallieren können, müssen wir es in umgekehrter Weise deinstallieren, wie Sie es installiert haben.

Um eine erfolgreiche Deinstallation eines Moduls zu sehen, können Sie das VMware.PowerCLI-Modul deinstallieren, das Sie zuvor installiert haben.

Auch wenn Sie VMware.PowerCLI deinstalliert haben, können Sie sehen, dass noch viele Abhängigkeiten installiert sind. Wenn Sie alle Module deinstallieren wollten, könnten wir Get-InstalledModule VMware.* | Uninstall-Module -Force verwenden.

Die vollständige Deinstallation dieses Moduls ist deshalb so schwierig, weil es so viele Abhängigkeiten hat. Außerdem sind einige dieser Module voneinander abhängig, weshalb der Parameter Force erforderlich ist.

Aktualisieren von Modulen

Nachdem Sie nun wissen, wie Sie ein Modul installieren und deinstallieren können, fragen Sie sich vielleicht, wie Sie ein installiertes Modul aktualisieren.

Wenn das Modul nicht mit Install-Module installiert wurde, können Sie es nicht mit den PowerShell-Befehlen aktualisieren, genau wie andere Prozesse. Sie können Update-Module verwenden, um ein Modul auf die neueste Version oder auf eine neuere spezifische Version zu aktualisieren.

Es gibt auch einen Schalter AllowPreRelease, mit dem Sie auf eine Version aktualisieren können, die nicht offiziell freigegeben wurde. Manchmal kann dies hilfreich sein, da vielleicht ein Fehler behoben wurde oder eine neue Funktion hinzugekommen ist, die du gerne nutzen möchtest.

Module prüfen/speichern

Einer der viel weniger genutzten Befehle, der sehr hilfreich ist, wenn man Module vor der Verwendung prüft, ist Save-Module. Mit diesem Befehl können Sie ein Modul in einen Pfad herunterladen, ohne es zu installieren.

Anschließend können Sie die Dateien inspizieren, und wenn es sich nicht um ein binäres Modul handelt, können Sie den Code, aus dem das Modul besteht, öffnen und betrachten. Dies kann nicht nur nützlich sein, um sicherzustellen, dass ein Modul nichts Böses tut, sondern auch, um zu erfahren, wie andere ihre Module strukturieren.

In diesem Beispiel wird nicht nur das Modul VMware.PowerCLI heruntergeladen, sondern auch alle Abhängigkeiten. Hier sehen Sie, was im VMware.PowerCLI-Ordner angezeigt wird:

Dies ist ein gutes Beispiel dafür, dass manchmal nicht standardmäßige Moduldateien im Modul enthalten sind, wie z. B. die Endbenutzer-Lizenzvereinbarung.

Schreiben eines eigenen Moduls

Sie haben jetzt gesehen, wie man mit einem fremden Modul interagiert. Jetzt wollen Sie lernen, wie Sie Ihr eigenes Modul erstellen, damit Sie Ihren Code für die Skalierbarkeit optimieren können.

Vorlagendateien erstellen

Zuerst müssen Sie einen Ordner für alle Ihre Moduldateien erstellen. Nachdem Sie den Container haben, müssen Sie Ihre Moduldatei erstellen. Sie müssen sicherstellen, dass Ihre Moduldatei denselben Namen wie Ihr Ordner hat, da PowerShell das Modul sonst nicht richtig erkennt, wenn Sie versuchen, es zu veröffentlichen.

PS51> New-Item -Path .\Scripts -Name ATARegistry -ItemType DirectoryPS51> New-Item -Path .\Scripts\ATARegistry -Name ATARegistry.psm1

Wenn Sie nun auch ein Manifest verwenden möchten, müssen Sie es genauso benennen wie den Container und die Moduldatei.

PS51> New-ModuleManifest -Path .\Scripts\ATARegistry\ATARegistry.psd1 -Author 'Tyler Muir' -CompanyName 'Adam the Automator' -RootModule ATARegistry.psm1 -Description 'Used for interacting with registry keys'

Mit dem Container, der Moduldatei und der Manifestdatei haben Sie ein voll funktionsfähiges Modul. Sie könnten dieses Modul in einem PSRepository veröffentlichen und überall installieren, wo Sie wollen. Da die Moduldatei jedoch leer ist, wird sie Ihnen wahrscheinlich nicht viel nützen. Sie können diese Dateien dennoch zum Testen der Veröffentlichung verwenden, um sicherzustellen, dass Ihr Repository funktioniert.

Registrieren eines PSRepository

Bevor Sie Ihr Modul veröffentlichen können, müssen Sie ein weiteres PSRepository zu Ihrer Sitzung hinzufügen. Zum Testen können Sie einen lokalen Pfad als PSRepository verwenden, da es einfach einzurichten und zu entfernen ist.

Wenn Sie ein PSRepository mit einem Verzeichnis einrichten, möchten Sie normalerweise sicherstellen, dass mehrere Computer darauf zugreifen können. Sie können ein lokales Repository wie folgt erstellen:

PS51> New-Item -Path C:\ -Name Repo -ItemType DirectoryPS51> Register-PSRepository -Name 'LocalRepo' -SourceLocation 'C:\Repo' -PublishLocation 'C:\Repo' -InstallationPolicy Trusted

Wenn Sie nur aus dem PSRepository herunterladen und nie veröffentlichen würden, könnten Sie den Parameter PublishLocation ausschließen.

Veröffentlichen Ihres Moduls

Da Sie die Installationsrichtlinie bereits auf vertrauenswürdig eingestellt haben, erhalten Sie keine Bestätigung, dass ein Modul aus dem Repository installiert werden darf. Da Sie nun ein neues PSRepository zur Verfügung haben, können Sie Ihr Modul mit Publish-Module -Name .\Scripts\ATARegistry -Repository LocalRepo veröffentlichen.

Nach der Veröffentlichung Ihres Moduls können Sie die oben genannten Befehle verwenden, um das Modul zu finden und zu installieren.

Nachdem Sie das Modul installiert haben, können Sie Get-Module verwenden, um das in Ihre lokale Sitzung importierte Modul zu sehen. Da Sie dem FunctionsToExport-Array im Manifest keine Funktionen hinzugefügt haben, ist die ExportedCommands-Eigenschaft leer.

Hinzufügen zu Ihrem Modul

Nun, da Sie wissen, dass Sie Ihr Modul veröffentlichen und installieren können, können Sie damit beginnen, ihm einige Funktionen hinzuzufügen. Sie könnten eine Funktion hinzufügen, die einen Registrierungsschlüssel zurückgibt, so dass er wie folgt aussieht:

function Get-ATARegistryKey { param ( $Path ) Get-Item $Path}

Wenn Sie das Manifest so belassen und versuchen, Ihr neues Modul hochzuladen, würden Sie auf zwei Probleme stoßen. Das erste ist, dass Sie eine Fehlermeldung erhalten würden, die besagt, dass die Version Ihres Moduls bereits in Ihrem Repository existiert. Das liegt daran, dass Sie die Modulversion in der Manifestdatei nicht geändert haben.

Exportieren von Modulfunktionen

Das andere Problem wäre, dass Sie nach dem Importieren des Moduls immer noch keine Funktionen in der ExportedCommands-Eigenschaft sehen würden, weil Sie Ihre neue Funktion nicht zum Manifest hinzugefügt haben.

Ihre Funktion könnte zwar verwendet werden, ohne dass sie in der FunctionsToExport-Liste aufgeführt ist, aber sie wäre dadurch viel schwerer zu finden.

Um diese beiden Probleme zu beheben, können Sie Ihre Moduldatei wie folgt aktualisieren:

ModuleVersion = '1.1'FunctionsToExport = 'Get-RegistryKey'

Nachdem Sie nun eine Funktion zu Ihrem Modul hinzugefügt und Ihr Manifest aktualisiert haben, um diese Änderungen widerzuspiegeln, können Sie die neue Version Ihres Moduls mit demselben Befehl wie zuvor veröffentlichen.

PS51> Publish-Module -Name .\Scripts\ATARegistry -Repository LocalRepo.

Aktualisieren Ihres Moduls

Der letzte Schritt besteht darin, Ihr Modul in Ihrer Sitzung zu aktualisieren, um die aktualisierten Dateien verwenden zu können. Mit Update-Module ATARegistry laden Sie das Update herunter, das Sie soeben im Repository veröffentlicht haben.

Jetzt können Sie sehen, dass Sie die neue Version des Moduls haben und die Funktion sehen, die Sie im Manifest definiert haben.

Erstellen von Hilfeinhalten

Eine der Optionen, die vorhin besprochen wurde, ist das Hilfesystem, das in PowerShell integriert ist. Sie haben wahrscheinlich schon einmal Get-Help für eine Funktion verwendet. Diese Informationen können auf zwei Arten hinzugefügt werden.

Die erste ist das Hinzufügen von kommentarbasierter Hilfe in die Funktionsdefinition. Dies ist normalerweise der Weg, den viele Modulautoren implementieren. Die andere Möglichkeit ist die Verwendung einer externen Hilfedatei. Sie können den Parameter Full verwenden, um alles anzuzeigen, was die Hilfe zu bieten hat.

Wie Sie sehen, gibt es wirklich nicht viele Informationen, und die wenigen Informationen, die Sie erhalten, sind wahrscheinlich für niemanden hilfreich.

Sie können Ihrer Moduldatei eine kommentarbasierte Hilfe hinzufügen, um diese Felder im Hilfesystem aufzufüllen. Sie können alle Optionen für die kommentargestützte Hilfe mit Get-Help about_Comment_Based_Help nachlesen.

Fürs Erste können Sie Ihre Funktion wie unten dargestellt aktualisieren. Dies ist eine Liste der am häufigsten verwendeten Hilfe-Parameter, aber alle diese sind immer noch optional und es gibt andere, die stattdessen hinzugefügt werden können.

Jetzt sieht Ihre Funktion wie folgt aus:

 function Get-RegistryKey {<# .SYNOPSIS Returns registry key using provided path. .DESCRIPTION The function uses the Get-Item command to return the information for a provided registry key. .PARAMETER Path The path that will be searched for a registry key. .EXAMPLE Get-RegistryKey -Path 'HKLM:\HARDWARE\DESCRIPTION\System' .INPUTS System.String .OUTPUTS Microsoft.Win32.RegistryKey .NOTES This module is an example of what a well documented function could look. .LINKhttps://adamtheautomator.com#>param($Path)Get-Item $Path}

Es gibt einige spezielle Hilfe-Parameter, wie .FORWARDHELPTARGETNAME. Diese Option leitet alle eingehenden Hilfeanfragen an einen anderen Befehl weiter. Dies könnte in einem Fall verwendet werden, in dem die Hilfe dieselben Informationen für mehrere Befehle anzeigen soll.

Nachdem Sie die Hilfe hinzugefügt haben, können Sie die Version im Modulmanifest aktualisieren, die neue Version veröffentlichen und die installierte Version für Ihre Sitzung aktualisieren, wie Sie es zuvor getan haben.

Wenn Sie sich jetzt die Hilfe für die Funktion ansehen, können Sie feststellen, dass viel mehr Informationen verfügbar sind. Dies ist eine großartige Möglichkeit, eine Dokumentation über die Verwendung der Funktionen einzubinden, insbesondere für jemanden, der weniger Erfahrung hat und vielleicht nicht in der Lage ist, schnell zu verstehen, was das Modul tut, indem er sich den Code ansieht.

Im Falle einer externen Hilfedatei sind die hinzugefügten Informationen die gleichen, aber die Informationen werden in einer separaten Datei platziert und innerhalb der Funktion verknüpft.

Wenn Sie in den AllUsersModulpfad schauen, können Sie die Version des Moduls und alle Moduldateien sehen, die Sie installiert haben.

Wenn Sie zu Ihrem PSRepository-Pfad C:\Repo zurückgehen, den Sie zuvor erstellt haben, können Sie eine Reihe von NUPKG-Dateien sehen. Es gibt eine für jede Version, die veröffentlicht wurde. Dies sind komprimierte Versionen dessen, was Sie veröffentlicht haben, wenn Sie Publish-Module.

Zusammenfassung

Wenn Sie die PowerShell-Konsole, PowerShell als Sprache und das Schreiben von Skripten im Griff haben, ist der letzte Schritt das Erstellen eigener Module. Mit Modulen können Sie mit der Entwicklung nützlicher Tools in PowerShell beginnen. Wenn Sie Module für einen bestimmten Zweck erstellen, werden Sie im Laufe der Zeit immer weniger Code schreiben müssen. Sie werden beginnen, Ihre Modulfunktionen in mehr Code zu referenzieren und von dort aus aufzubauen.

Modulfunktionen ermöglichen es Ihnen, den Code zu abstrahieren, den Sie in Skripts wiederholen. Sie stellen „Etiketten“ dar, auf die man später im Code verweisen kann und die jederzeit aufgerufen werden können, anstatt das Rad neu zu erfinden und zu versuchen, herauszufinden, wie man sein Ziel bereits vorher erreicht hat. Module sind die endgültige „Verpackung“ von PowerShell-Code, die gleichgesinnten Code zusammenfasst, um zu verhindern, dass Sie Zeit für Probleme verschwenden, die Sie bereits gelöst haben.