Adam the Automator

Werken met PowerShell-modules is een belangrijk onderdeel van PowerShell-automatisering. Als je PowerShell begint te leren, zijn de eerste stappen meestal het gebruik van losse commando’s. Dit leidt tot het bouwen van scripts, die vervolgens leidt tot het bouwen van functies.

Door het gebruik van functies, kunt u uw scripts meer modulair maken. Dit stelt u in staat om dezelfde code te gebruiken op vele plaatsen zonder kopiëren en plakken naar code all over the place. Door functies te gebruiken hoeft u minder tijd te besteden aan het aanpassen van dezelfde code overal waar die wordt gebruikt. In plaats daarvan kunt u werken aan het verbeteren van uw code op een enkele plaats.

Om functies naar het volgende niveau te brengen, kunt u deze functies samenvoegen in een module.

Een module is een verzameling van functies in een tekstbestand met een psm1 extensie. Er zijn enkele optionele toevoegingen, zoals een module manifest en commentaar-gebaseerde of externe hulp die ook kunnen worden opgenomen. Deze komen later aan de orde.

Voorvereisten

Ik gebruik in dit artikel Windows PowerShell 5.1. Als u een oudere versie of PowerShell Core gebruikt, kan het resultaat variëren.

Interactie met modules

Als u voor het eerst een PowerShell-sessie opent, begint u met twee modules. De eerste is Microsoft.PowerShell.Utility die veel basis PowerShell functies bevat die u al gebruikt. De andere module is PSReadline. U kunt deze startmodules bekijken met de opdracht Get-Module.

Dit gezegd hebbende, is dit geen volledige lijst van alle beschikbare modules. Sinds PowerShell 3 worden modules die zijn geïnstalleerd, indien nodig geïmporteerd. Als u een oudere versie van PowerShell gebruikt, moet u eerst de opdracht Import-Module gebruiken om de module te importeren voordat u een van de opdrachten gebruikt.

Er zijn momenten waarop u Import-Module nog steeds wilt gebruiken, zelfs in latere versies. Als u een module wilt importeren nadat deze al is geïnstalleerd, kunt u Import-Module als volgt gebruiken:

Terwijl Get-Module alle modules toont die zijn geïmporteerd, ziet u niet de modules die nog niet zijn geïmporteerd. U kunt dan de parameter ListAvailable gebruiken om alle andere modules te tonen die beschikbaar zijn.

Niet alle commando’s worden standaard getoond

De eigenschap ExportedCommands bevat een lijst met alle beschikbare commando’s die uit de module worden geëxporteerd. U kunt verschillen zien tussen deze lijst en wat er in het module bestand staat. Geëxporteerde commando’s is een eigenschap die in het module manifest is ingebouwd en die de schrijver in staat stelt om een functie als verborgen te laten staan. Module-auteurs kunnen ook het cmdlet Export-ModuleMember gebruiken, maar dat valt buiten het bereik van dit artikel.

Module-auteurs kunnen een functie verborgen willen hebben, omdat deze bedoeld is om andere functies te ondersteunen, niet om naar de gebruiker gericht te zijn. Om een functie te verbergen zou de auteur deze uitsluiten van de FunctionsToExport array in het manifest. Hier ziet u een uitgebreide weergave van de ExportedCommands eigenschap.

Modules importeren

Er zijn vele manieren om met modules aan de slag te gaan. U kunt de module handmatig importeren met behulp van het pad naar de modulebestanden. Dit stelt u in staat om de module te testen en bij te werken zonder veel werk te hoeven doen. Maar dit laat niet veel portabiliteit toe, aangezien u het exacte pad naar de module zou moeten gebruiken. PowerShell zal ook niet automatisch modules importeren die niet in de $env:PSModulePath variabele staan.

Selectief importeren van commando’s

U kunt Import-Module gebruiken om alleen specifieke functies te importeren in plaats van de hele module door gebruik te maken van de Function parameter. Dit kan tijd besparen bij het importeren van modules van externe systemen, zoals de Office 365-modules.

Alle gebruikersmodules

Modules die voor alle gebruikers zijn geïnstalleerd, worden geplaatst in C:Program FilesWindowsPowerShellModules. Deze directory bevat veel vooraf toegevoegde modules, inclusief alle modules die zijn geïnstalleerd met Install-Module met de standaard scope AllUsers.

Huidige gebruiker modules

Als u een module installeert maar slechts één gebruiker deze wilt laten gebruiken, dan is er een CurrentUser scope. Dit plaatst de module bestanden in uw Documenten folder op C:\Users\<gebruikersnaam>\Documenten\WindowsPowerShell\Modules. Dit kan handig zijn in een omgeving waar u folder redirection gebruikt met de Documenten folder.

In dit geval kunt u een module op de ene computer installeren en op de andere gebruiken omdat ze beiden dezelfde documenten folder delen.

Systeem Modules

Voor de volledigheid, er is ook een module folder op C:Windows\System32WindowsPowerShell\1.0\Modules. Technisch gezien zou een module in dit pad geïmporteerd worden net als een van de andere paden, maar het is niet aan te raden omdat dit is gereserveerd voor Microsoft’s systeem modules.

Naamgeving is belangrijk

U kunt uw module handmatig in een van deze paden plaatsen om deze standaard beschikbaar te maken bij een nieuwe sessie, maar u moet er wel voor zorgen dat u de vereiste naamgeving voor modules volgt. De map waarin de module bestanden worden geplaatst, moet dezelfde naam hebben als het psm1 module bestand en het psd1 module manifest als er een is.

Het gebruik van Get-Module -ListAvailable waar we het eerder over hadden, verwijst naar deze paden. U kunt alle modulepaden zien met $env:PSModulePath -Split ';'. Het is mogelijk dat u andere paden in de lijst ziet dan wat hier wordt getoond. Veel programma’s voegen hun eigen modulepaden toe wanneer ze geïnstalleerd worden. Een van de voorbeelden hiervan is SQL, dat zijn eigen modules heeft opgenomen in zijn eigen modulepaden.

Er zijn ook enkele modules die u met een ander proces zou installeren. Een van de belangrijkste voorbeelden hiervan is de ActiveDirectory module. Vanaf Windows 7 tot Windows 10 1803 installeert u deze met het installatieprogramma Remote Server Administration Tools (RSAT).

Op nieuwere versies van Windows 10 (1809+) is deze alleen beschikbaar via de functie Features On Demand. Met de installatie van RSAT installeert u de ActiveDirectory-modules en vele andere die u gebruikt om andere Windows-rollen te beheren. Op Windows-serverbesturingssystemen worden deze modules geïnstalleerd via Serverbeheer.

Modules op afstand importeren (impliciete remoting)

Er zijn enkele gevallen waarin het niet praktisch is om een module lokaal te laten draaien. In plaats daarvan is het beter om verbinding te maken met een apparaat op afstand en een daarop geïnstalleerde module te importeren. Wanneer u dit doet, worden de commando’s daadwerkelijk uitgevoerd op de machine op afstand. Dit wordt vaak gebruikt met Microsoft’s Office 365 modules. Veel van deze modules maken verbinding met een Office 365-server die vervolgens een module importeert. Wanneer u een van de commando’s uitvoert, worden ze uitgevoerd op de externe server en vervolgens wordt de uitvoer teruggestuurd naar uw sessie.

Een ander gebruik van het importeren van externe modules is wanneer u de module niet lokaal hebt geïnstalleerd. Dit is wat u zou krijgen als u de ActiveDirectory-module niet had geïnstalleerd, maar deze wel probeerde te importeren.

Om een externe module te importeren, moet u eerst een PSSession maken. U kunt New-PSSession gebruiken om de sessie aan te maken. Vervolgens importeert u de module die beschikbaar is op het apparaat op afstand met behulp van de parameter PSSession met Import-Module.

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

Door deze methode voor het importeren van modules op afstand te gebruiken, kunt u code sneller uitvoeren in een gedistribueerde omgeving. Als u bijvoorbeeld vanaf uw computer werkt, maar de servers waarop u werkt bevinden zich aan de andere kant van de VS, kan het aanzienlijk langer duren om bepaalde commando’s lokaal uit te voeren tegen de servers. Terwijl het uitvoeren van de commando’s op een server en het terugvoeren van de uitvoer naar uw lokale sessie veel sneller is.

Een Module Voorvoegsel Toevoegen

U kunt ook een voorvoegsel toevoegen aan de functies die worden geïmporteerd van de machine op afstand. Deze optie is beschikbaar tijdens het importeren van lokale modules, maar wordt zelden gebruikt buiten het testen van verschillende versies van een module naast elkaar.

Als u het import commando hierboven uitvoerde en dit is wat u zou zien als u naar de commando’s kijkt:

In dit geval kunt u een voorvoegsel gebruiken om aan te geven dat het niet om een lokale module gaat. Dit kan worden gebruikt in gevallen waarin u een module importeert die ook lokaal beschikbaar is. Het toevoegen van het voorvoegsel vermindert verwarring over waar de code wordt uitgevoerd.

Modules verwijderen

U kunt ook een module uit de huidige sessie verwijderen zonder Remove-Module te gebruiken. Dit verwijdert een module uit de lokale sessie zonder de module bestanden te verwijderen. U zou dit kunnen gebruiken in een geval waar u een remote sessie gebruikt om een module te gebruiken. U kunt Remove-Module gebruiken om uw sessie op te schonen en vervolgens de verbinding met de externe sessie te verbreken.

Een ander gebruik van Remove-Module is wanneer u wijzigingen aanbrengt in een module en u geen nieuwe PowerShell-sessie wilt starten. In dat geval gebruikt u Remove-Module gevolgd door Import-Module om de module opnieuw in uw sessie te laden. Als alternatief kunt u de Force parameter gebruiken met Import-Module. Dit zal het unload en reload van de module voor u voltooien.

What Makes up a PowerShell Module

Een module kan bestaan uit een of meer bestanden. Om aan de minimumeisen voor een module te voldoen, moet u een modulebestand hebben. Dit kan een PSM1 bestand zijn of een ander module bestand zoals een binair module bestand. Om daarop voort te bouwen, moeten in uw psm1 functies gedefinieerd zijn, anders heeft niemand er wat aan.

Er zijn geen eisen voor hoe de functies er uit moeten zien of wat ze moeten doen, maar er zijn wel enkele richtlijnen. Het verdient meestal de voorkeur om alle functies in een module rond hetzelfde concept op te bouwen.

Modules bevatten gelijksoortige functies

Bij voorbeeld, de ActiveDirectory module bevat alleen functies die op een of andere manier met Active Directory te maken hebben. Meestal bevatten de functienamen ook een voorvoegsel. Als we de ActiveDirectory module als voorbeeld nemen, dan beginnen alle zelfstandige naamwoorden in de functienamen met AD.

Het gebruik van deze richtlijnen helpt bij de vindbaarheid van de functies. Stel je voor dat je net deze nieuwe module hebt geïmporteerd en door de functies wilt bladeren. Dit is veel gemakkelijker als alle functies een vergelijkbare naamstructuur hebben. Hoewel u vaak ziet dat modules beginnen met PS, is dit voorvoegsel officieel alleen voorbehouden aan Microsoft modules. U zult waarschijnlijk geen problemen veroorzaken als u PS gebruikt aan het begin van uw module, maar u kunt wel een conflict veroorzaken met een andere module naam.

Uitgaande van deze richtlijnen, als u een stel functies had die allemaal te maken hadden met interactie met het register, zou u zoiets kunnen hebben als:

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

Module Manifests

Om voort te bouwen op het tekst module bestand, kunt u ook een module manifest toevoegen. Deze bestanden hebben een PSD1 extensie en bevatten metadata over de module. Dit is waar je informatie over de auteur, beschrijving van de module, andere vereiste modules, en vele andere attributen zou kunnen opnemen. Om te publiceren naar een repository, is het vereist dat de Author en Description velden zijn ingevuld.

Hier is een voorbeeld van een manifest dat we kunnen hebben voor onze register module:

#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 = ''}

Hoewel dit er op het eerste gezicht intimiderend uitziet, heeft Microsoft een handige cmdlet die je kunt gebruiken om een module manifest te genereren. Het bijgeleverde commando is New-ModuleManifest. Om het bovenstaande manifest te genereren zou je kunnen gebruiken:

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 Help Bestanden

Je kunt in sommige modules ook externe help bestanden tegenkomen. Ze zijn te herkennen aan de <ModuleName>-Help.xml aan het eind van de bestandsnaam. Deze externe help bestanden bevatten dezelfde informatie die normaal gesproken in de commando gebaseerde help staat die u kunt vinden in een functie definitie.

Dit zou ook vereisen dat u # .ExternalHelp <ModulePath>-Help.xml toevoegt aan uw functie om deze goed te laten werken bij gebruik van het Get-Help commando na het importeren van de module. Het is gewoonlijk alleen gebruikelijk om externe help bestanden te zien bij zeer grote modules en daarom vallen ze buiten het bereik.

Hoewel dit de meest voorkomende typen bestanden zijn die je in een module zult zien, zijn dit niet de enige bestanden. Soms zie je naast een tekstmodule ook binaire bestanden omdat er andere afhankelijkheden zijn. Door het verkennen van de module paden, kunt u vele voorbeelden van extra bestandstypen in modules.

Om niet-standaard module bestanden goed te publiceren zou je andere bestanden in de FileList parameter in uw module manifest.

In de module manifest, zult u merken dat vele andere parameters die momenteel leeg zijn. U kunt deze gebruiken om andere vereisten voor het gebruik van uw module te definiëren. U kunt bijvoorbeeld definiëren met welke versies van PowerShell de module kan werken. Als u de module probeert te importeren op een versie van PowerShell die niet wordt ondersteund, ziet u het volgende:

PSRepositories

Een van de belangrijkste distributieopties voor modules is een PSRepository. Op 1000′ bekeken is een PSRepository een lokaal waar meerdere mensen of meerdere apparaten toegang hebben tot de modulebestanden. Dit zijn vaak webservers waar je bestanden kunt publiceren.

Je kunt ook een directory gebruiken voor de repository, maar dit beperkt je wel in de functionaliteit van je repository. Je kunt zelf een PSRepository hosten, of je kunt gebruik maken van een van de vele mogelijkheden op het internet zoals de PowerShell Gallery. U kunt uw PSRepositories bekijken met het Get-PSRepository-commando.

Standaard is er maar één item en dat is voor de PowerShell-galerie. U zult zien dat er “untrusted” staat. Dit komt doordat PowerShell u erop wijst dat u met de PowerShell-galerie mogelijk code gebruikt die niet door Microsoft is geschreven en goedgekeurd. Dit betekent dat u expliciet toestemming moet geven voordat modules worden geïnstalleerd.

PSRepositories toevoegen

U kunt ook uw eigen repositories toevoegen. Om PowerShell Gallery te vertrouwen, kunt u Get-PSRepository -Name PSGallery | Set-PSRepository -InstallationPolicy Trusted uitvoeren of u kunt de waarschuwing accepteren de eerste keer dat u een module uit de PowerShell Gallery installeert.

Alle commando’s die u zou gebruiken om te communiceren met deze PSRepositories zijn te vinden in de PowerShellGet module. U kunt de functies hier zien:

Het is mogelijk dat de module PowerShellGet moet worden bijgewerkt voordat er interactie mogelijk is met bepaalde repositories.

Modules zoeken

Een ander belangrijk kenmerk van het gebruik van een PSRepository is de mogelijkheid om naar modules te zoeken. Dit wordt gedaan met het Find-Module commando. Er zijn meerdere manieren om te filteren om specifiek te vinden wat u zoekt, maar voor nu kunt u als volgt naar de VMware-modules zoeken:

Dit toont alle modules die beginnen met VMware. Hoewel de meeste van deze modules van VMware zijn, moet u naar het kenmerk van de auteur kijken om te zien wie de module heeft gepubliceerd.

Doordat iedereen kan uploaden naar PowerShell Gallery, zijn er duizenden modules beschikbaar. Dit betekent dat u mogelijk modules vindt die niet goed werken voor uw use case. Veel modules die u zult vinden zijn open source, zodat u kunt bijdragen aan hen om de functionaliteit van de module te verbeteren.

Modules installeren

Om het Install-Module commando te gebruiken, moet u een vertrouwde PSRepository hebben die de module host. Dit kan de PowerShell Galerie zijn, een andere internet PSRepository, of een zelf gehoste site. U kunt het Find-Module commando gebruiken om de module eenvoudig te bevestigen voordat u deze installeert.

U kunt ook de versie van een module bepalen door de MinimumVersion, MaximumVersion, of RequiredVersion parameters te gebruiken.

Om alle modules te zien die zijn geïnstalleerd met Install-Module kunt u Get-InstalledModule gebruiken. Dit geeft een lijst van alle modules die zijn geïnstalleerd op de AllUsers scope of uw CurrentUser scope.

Modules verwijderen

Zoals u een module kunt installeren, kunt u ook de installatie van een module ongedaan maken. Als de module niet is geïnstalleerd met het commando Install-Module, kunt u de installatie niet ongedaan maken met het commando Uninstall-Module.

Zoals u hier kunt zien, proberen we de module ActiveDirectory ongedaan te maken. Aangezien deze module niet is geïnstalleerd met Install-Module, zou u een foutmelding krijgen wanneer u Uninstall-Module probeert te gebruiken. Om deze module te verwijderen, moeten we de installatie omkeren door de module te installeren.

Om een succesvolle de-installatie van een module te zien, kunt u de VMware.PowerCLI module verwijderen die u eerder hebt geïnstalleerd.

Ondanks dat u VMware.PowerCLI hebt verwijderd, kunt u zien dat er nog steeds veel afhankelijkheden zijn geïnstalleerd. Als u alle modules wilt verwijderen, kunnen we Get-InstalledModule VMware.* | Uninstall-Module -Force gebruiken.

De reden waarom het zo moeilijk zou zijn om deze module volledig te verwijderen, is omdat deze zoveel afhankelijkheden heeft. Bovendien zijn sommige van deze modules afhankelijk van elkaar, wat de reden is waarom de Force parameter nodig zou zijn.

Modules bijwerken

Nu u weet hoe u een module installeert en verwijdert, vraagt u zich misschien af hoe u een module bijwerkt die u hebt geïnstalleerd.

Net als andere processen, als de module niet is geïnstalleerd met Install-Module, kunt u de module niet bijwerken met de PowerShell-commando’s. U kunt Update-Module gebruiken om een module bij te werken naar de nieuwste release, of naar een nieuwere specifieke versie.

Er is ook een switch naar AllowPreRelease waarmee u kunt updaten naar een versie die nog niet officieel is uitgebracht. Soms kan dit helpen omdat er misschien een bug die u ondervindt is opgelost of een nieuwe functie is toegevoegd die u graag zou willen gebruiken.

Een module inspecteren/opslaan

Een van de veel minder gebruikte commando’s die erg handig is bij het doorlichten van modules voordat ze worden gebruikt is Save-Module. Met dit commando kunt u een module downloaden naar een pad zonder deze te installeren.

U kunt dan de bestanden inspecteren en als de module geen binaire module is, kunt u deze openen en de code bekijken waaruit de module is opgebouwd. Dit kan niet alleen handig zijn om er zeker van te zijn dat een module niets schadelijks doet, maar ook om te leren hoe anderen hun modules structureren.

In dit voorbeeld wordt niet alleen de VMware.PowerCLI-module gedownload, maar ook alle afhankelijkheden. Dit is wat er in de map VMware.PowerCLI staat:

Dit is een goed voorbeeld van hoe er soms niet-standaard modulebestanden in de module zijn opgenomen, zoals de licentieovereenkomst voor eindgebruikers.

Uw eigen module schrijven

U hebt nu gezien hoe u kunt communiceren met de module van iemand anders. Nu wilt u leren hoe u uw eigen module kunt maken, zodat u kunt beginnen met het optimaliseren van uw code voor schaalbaarheid.

Sjabloonbestanden maken

Eerst moet u een map maken voor al uw modulebestanden. Nadat u de container hebt, moet u uw module bestand te maken. U moet ervoor zorgen dat uw module-bestand dezelfde naam heeft als uw map, anders zal PowerShell bij het publiceren van uw module, de module niet correct ontdekken.

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

Nu u ook een manifest wilt gebruiken, moet u dit ook dezelfde naam geven als de container en het module-bestand.

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'

Met de container, het module-bestand en het manifest-bestand, hebt u een volledig functionerende module. Je zou deze module kunnen publiceren naar een PSRepository en overal installeren waar je maar wilt. Hoewel, omdat het module bestand leeg is, zal het waarschijnlijk niet veel helpen. Je kunt deze bestanden wel gebruiken om te testen of je repository werkt.

Registreren van een PSRepository

Voordat je je module kunt publiceren, moet je nog een PSRepository aan je sessie toevoegen. Voor het testen kun je een lokaal pad als PSRepository gebruiken, omdat deze dan makkelijk op te zetten en af te breken is.

Normaal gesproken zou je, als je een PSRepository met een directory zou opzetten, er zeker van willen zijn dat meerdere computers er toegang toe kunnen krijgen. Je kunt een lokale repository als volgt aanmaken:

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

Als je alleen download van de PSRepository en nooit publiceert, kun je de PublishLocation parameter uitsluiten.

Publiceer je Module

Omdat je de installatie policy al op vertrouwd hebt gezet, zul je geen bevestiging krijgen om een module te mogen installeren vanuit de repository. Nu je een nieuwe PSRepository beschikbaar hebt, kun je je module publiceren met Publish-Module -Name .\Scripts\ATARegistry -Repository LocalRepo.

Na het publiceren van je module, kun je de commando’s van hierboven gebruiken om de module te vinden en te installeren.

Nu je de module hebt geïnstalleerd, kun je Get-Module gebruiken om de module geïmporteerd te zien in je lokale sessie. Aangezien u geen functies hebt toegevoegd aan de FunctionsToExport array in het manifest, is de ExportedCommands eigenschap leeg.

Extra functionaliteit toevoegen aan uw module

Nu u weet dat u uw module kunt publiceren en installeren, kunt u beginnen met het toevoegen van wat functionaliteit aan de module. Je zou een functie kunnen toevoegen die een registersleutel teruggeeft, zodat het er als volgt uitziet:

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

Als je het manifest laat zoals het is en je probeert je nieuwe module te uploaden, dan zou je twee problemen tegenkomen. Het eerste is dat je een foutmelding krijgt dat de versie van je module al bestaat in je repository. Dit komt omdat je de versie van de module niet hebt veranderd in het manifest bestand.

Module Functies Exporteren

Het andere probleem zou zijn dat nadat je de module hebt geïmporteerd, je nog steeds geen functies zou zien in de ExportedCommands eigenschap omdat je je nieuwe functie niet hebt toegevoegd aan het manifest.

Hoewel je functie zou kunnen worden gebruikt zonder dat deze in de FunctionsToExport lijst staat, zou dit het veel moeilijker maken om deze te vinden.

Om deze twee problemen op te lossen, kunt u uw modulebestand als volgt bijwerken:

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

Nu u een functie aan uw module hebt toegevoegd en uw manifest hebt bijgewerkt om deze veranderingen weer te geven, kunt u de nieuwe versie van uw module publiceren met hetzelfde commando als voorheen.

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

Uw module bijwerken

De laatste stap zou voor u zijn om uw module in uw sessie bij te werken om in staat te zijn de bijgewerkte bestanden te gebruiken. Met Update-Module ATARegistry download je de update die je zojuist in de repository hebt gepubliceerd.

Nu kun je zien dat je de nieuwe versie van de module hebt en je kunt de functie zien die je in het manifest hebt gedefinieerd.

Hulpinhoud opbouwen

Een van de opties die eerder aan de orde is geweest, is het Help-systeem dat in PowerShell is ingebouwd. Je hebt waarschijnlijk ooit Get-Help gebruikt op een functie. Deze informatie kan op twee manieren worden toegevoegd.

De eerste is om hulp op basis van commentaar toe te voegen aan de functiedefinitie. Dit is gewoonlijk de manier die veel module-schrijvers implementeren. De andere manier is het gebruik van een extern helpbestand. U kunt de parameter Full gebruiken om alles te laten zien wat de hulp te bieden heeft.

Zoals u ziet, is er niet echt veel informatie en de weinige informatie die u krijgt, is waarschijnlijk voor niemand van nut.

U kunt hulp op basis van commentaar toevoegen aan uw modulebestand om deze velden in het hulpsysteem te vullen. U kunt meer lezen over alle opties voor hulp op basis van commentaar door Get-Help about_Comment_Based_Help te gebruiken.

Voorlopig kunt u uw functie bijwerken zodat die eruit ziet zoals hieronder. Dit is een lijst van de meest gebruikte help parameters, maar al deze zijn nog steeds optioneel en er zijn andere die in plaats daarvan kunnen worden toegevoegd.

Nu ziet uw functie er als volgt uit:

 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}

Er zijn enkele speciale help parameters, zoals .FORWARDHELPTARGETNAME. Deze optie stuurt alle inkomende hulpvragen door naar een ander commando. Dit kan gebruikt worden in een geval waar de help dezelfde informatie voor meerdere commando’s moet tonen.

Nu je de help hebt toegevoegd, kun je de versie in het module manifest bijwerken, de nieuwe versie publiceren, en de geïnstalleerde versie voor je sessie bijwerken zoals je eerder hebt gedaan.

Als je nu naar de help voor de functie kijkt, zie je dat er veel meer informatie beschikbaar is. Dit is een goede manier om documentatie over het gebruik van de functies op te nemen, vooral voor iemand die minder ervaring heeft en misschien niet snel kan begrijpen wat de module doet door naar de code te kijken.

In het geval van een extern helpbestand is de toegevoegde informatie hetzelfde, maar de informatie wordt in een apart bestand geplaatst en gekoppeld aan de functie.

Als u in het modulepad AllUsers kijkt, ziet u de versie van de module en alle modulebestanden die u hebt geïnstalleerd.

Als u teruggaat naar uw PSRepository-pad C:\Repo dat u eerder hebt gemaakt, ziet u een heleboel NUPKG-bestanden. Er is er een voor elke versie die is gepubliceerd. Dit zijn gecomprimeerde versies van wat u hebt gepubliceerd met Publish-Module.

Samenvatting

Als u eenmaal de PowerShell-console, PowerShell als een taal en het schrijven van scripts onder de knie hebt, is het bouwen van uw eigen modules de laatste stap. Met modules kunt u beginnen met het ontwikkelen van nuttige hulpmiddelen in PowerShell. Indien goed ontworpen en gebouwd door het creëren van modules voor een enkel doel, zult u onvermijdelijk merken dat u na verloop van tijd steeds minder code schrijft. U zult beginnen te verwijzen naar uw module functies in meer code en bouwen van daaruit.

Module functies kunt u abstraheren van de code die je merkt te herhalen in scripts. Ze vormen “labels” om later naar te verwijzen in code die op elk moment kan worden aangeroepen in plaats van het wiel opnieuw uit te vinden en te proberen uit te vinden hoe je je doel eerder al had bereikt. Modules zijn de uiteindelijke “verpakking” van PowerShell-code die gelijksoortige code groepeert om te voorkomen dat tijd wordt verspild aan problemen die u al hebt opgelost.