Werken met PowerShell-modules is een belangrijk onderdeel van PowerShell-automatisering. Wanneer je begint met het leren van PowerShell, zijn de eerste stappen meestal het gebruik van afzonderlijke commando’s. Dit leidt tot het bouwen van scripts, wat vervolgens leidt tot het bouwen van functies.
Door functies te gebruiken, kun je je scripts modulair maken. Dit stelt je in staat om dezelfde code op veel plaatsen te gebruiken zonder deze overal te kopiëren en plakken. Het gebruik van functies zorgt ervoor dat je minder tijd hoeft te besteden aan het aanbrengen van dezelfde wijziging in dezelfde code overal waar deze wordt gebruikt. In plaats daarvan kun je werken aan het verbeteren van je code op één plek.
Om functies naar een hoger niveau te tillen, kun je deze functies samenvoegen tot een module.
A module is a collection of functions in a text file with a psm1 extension. There are some optional additions, such as a module manifest and comment-based or external help that may also be included. These will be covered later on.
Vereisten
I’ll be using Windows PowerShell 5.1 in this article. If you’re using an older version or PowerShell Core, your mileage may vary as to results you see.
Interactie met Modules
Zodra je een PowerShell-sessie opent, begin je met twee modules. De eerste is Microsoft.PowerShell.Utility, die veel basis-PowerShell-functies bevat die je al gebruikt. De andere module is PSReadline. Je kunt deze startmodules zien door het Get-Module-commando te gebruiken.
Dat gezegd hebbende, dit is geen volledige lijst van alle beschikbare modules. Sinds PowerShell 3 worden modules die zijn geïnstalleerd, geïmporteerd wanneer ze nodig zijn. Als je een oudere versie van PowerShell gebruikt, moet je het Import-Module-commando gebruiken om de module eerst te importeren voordat je een van de commando’s gebruikt.
Er zijn momenten waarop je nog steeds Import-Module wilt gebruiken, zelfs in latere versies. Als je een module wilt importeren nadat deze al is geïnstalleerd, kun je Import-Module als volgt gebruiken:
Terwijl Get-Module alle geïmporteerde modules laat zien, zie je modules die nog niet zijn geïmporteerd niet. Je kunt dan de parameter ListAvailable gebruiken om alle andere modules te tonen die beschikbaar zijn.
Get-Module -ListAvailableNiet alle commando’s worden standaard weergegeven
De eigenschap ExportedCommands bevat een lijst van alle beschikbare commando’s die worden geëxporteerd door de module. Je kunt enkele verschillen zien tussen deze lijst en wat er in het modulebestand staat. Geëxporteerde commando’s is een functie ingebouwd in het modulemanifest waarmee de schrijver een functie als verborgen kan achterlaten. Module-auteurs kunnen ook de Export-ModuleMember cmdlet gebruiken, maar dat valt buiten het bestek van dit artikel.
Module-auteurs willen mogelijk een functie verbergen omdat deze bedoeld is om andere functies te ondersteunen, niet om door gebruikers te worden gebruikt. Om een functie verborgen te hebben, zou de auteur deze uitsluiten van de FunctionsToExport array in het manifest. Hier kun je een uitgebreide weergave zien van de eigenschap ExportedCommands.
Modules importeren
Er zijn veel manieren om modules te gebruiken. Je kunt de module handmatig importeren met het pad naar de modulebestanden. Hierdoor kun je de module testen en bijwerken zonder veel werk te hoeven doen. Maar dit staat niet toe dat de module zeer draagbaar is, aangezien je het exacte pad naar de module zou moeten gebruiken. PowerShell zal ook geen modules automatisch importeren die niet in de $env:PSModulePath variabele staan.
Selectief Commando’s Importeren
Je kunt Import-Module gebruiken om alleen specifieke functies in plaats van de hele module te importeren door de Function parameter te gebruiken. Dit kan tijd besparen bij het importeren van modules vanaf externe systemen, zoals de Office 365 modules.
Alle Gebruikersmodules
Modules geïnstalleerd voor alle gebruikers worden geplaatst in C:\Program Files\WindowsPowerShell\Modules. Deze map bevat veel vooraf toegevoegde modules, inclusief alle modules die zijn geïnstalleerd met Install-Module met de standaardscope AllUsers.
Modules van Huidige Gebruiker
Als je een module installeert maar deze alleen door een enkele gebruiker wilt laten gebruiken, is er een CurrentUser scope. Hierdoor worden de modulebestanden in je Documentenmap geplaatst op C:\Users\<gebruikersnaam>\Documents\WindowsPowerShell\Modules. Dit kan handig zijn in een omgeving waarin je mapomleiding gebruikt met de Documentenmap.
In dit geval kun je een module installeren op de ene computer en deze op een andere gebruiken, omdat ze beide dezelfde documentenmap delen.
Systeemmodules
Voor volledigheid is er ook een modulemap op C:\Windows\System32\WindowsPowerShell\1.0\Modules. Hoewel technisch gezien een module geplaatst in deze map geïmporteerd zou worden als een van de andere paden, wordt dit niet aanbevolen omdat het gereserveerd is voor Microsoft’s systeemmodules.
Naamgeving is Belangrijk
Je kunt handmatig je module in een van deze paden plaatsen om het standaard beschikbaar te maken bij een nieuwe sessie, maar je moet ervoor zorgen dat je de vereiste namen voor modules volgt. De map waarin de modulebestanden zijn geplaatst, moet dezelfde naam hebben als het psm1-modulebestand en het psd1-modulemanifest als dat er is.
Door Get-Module -ListAvailable te gebruiken, waarnaar we eerder verwezen, worden deze paden genoemd. Je kunt alle modulepaden zien door $env:PSModulePath -Split ';' te gebruiken. Je zult mogelijk andere paden in de lijst zien dan wat hier wordt getoond. Veel programma’s voegen hun eigen modulepaden toe wanneer ze zijn geïnstalleerd. Een van de voorbeelden hiervan is SQL, dat zijn eigen modules heeft in zijn eigen modulepaden.
$env:PSModulePathEr zijn ook enkele modules die je zou installeren met een ander proces. Een van de belangrijkste voorbeelden hiervan is de ActiveDirectory-module. Van Windows 7 tot Windows 10 1803 installeerde je deze met de Remote Server Administration Tools (RSAT) installer.
Op nieuwere versies van Windows 10 (1809+) is dit alleen beschikbaar via de Features On Demand. Door RSAT te installeren worden de ActiveDirectory-modules en vele andere geïnstalleerd die je zou gebruiken om andere Windows-rollen te beheren. Op Windows-serverbesturingssystemen worden deze modules geïnstalleerd via de Server Manager.
Importeren van Externe Modules (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 extern apparaat en een daarop geïnstalleerde module te importeren. Wanneer je dit doet, worden de opdrachten daadwerkelijk uitgevoerd op de externe machine. Dit wordt vaak gebruikt met Microsoft’s Office 365-modules. Veel van deze modules verbinden met een Office 365-server die vervolgens een module importeert. Wanneer je een van de opdrachten uitvoert, worden ze uitgevoerd op de externe server en wordt de uitvoer teruggestuurd naar je sessie.
Nog een gebruik van het importeren van externe modules is wanneer je de module niet lokaal hebt geïnstalleerd. Dit is wat er gebeurt als je de ActiveDirectory module niet lokaal hebt geïnstalleerd, maar toch probeert deze te importeren.
Om een externe module te importeren, moet je eerst een PSSession maken. Je kunt New-PSSession gebruiken om de sessie te maken. Vervolgens zou je de beschikbare module op het externe apparaat importeren met behulp van de PSSession-parameter met Import-Module.
Het gebruik van deze methode om externe modules te importeren maakt snellere uitvoering van code mogelijk in een gedistribueerde omgeving. Bijvoorbeeld, als je vanaf je computer werkt, maar de servers waarop je werkt zich aan de andere kant van de Verenigde Staten bevinden, kan het aanzienlijk langer duren om bepaalde opdrachten lokaal tegen de servers uit te voeren. Het uitvoeren van de opdrachten op een server en het terugvoeren van de uitvoer naar je lokale sessie gaat echter veel sneller.
Het toevoegen van een modulevoorvoegsel
Je kunt ook een voorvoegsel toevoegen aan de functies die geïmporteerd zijn vanaf de externe machine. Deze optie is beschikbaar bij het importeren van lokale modules, maar wordt zelden buiten het testen van verschillende versies van een module naast elkaar gebruikt.
Als je het bovenstaande importcommando uitvoert, zie je het volgende wanneer je naar de commando’s kijkt:
In dit geval kun je een voorvoegsel gebruiken om aan te geven dat het geen lokale module is. Dit kan worden gebruikt in gevallen waarin je een module importeert die ook lokaal beschikbaar is. Het toevoegen van het voorvoegsel vermindert verwarring over waar de code wordt uitgevoerd.
Modules Verwijderen
Je kunt ook een module uit de huidige sessie verwijderen zonder Remove-Module te gebruiken. Hiermee verwijder je een module uit de lokale sessie zonder de modulebestanden te verwijderen. Je kunt dit gebruiken in een geval waarin je een externe sessie gebruikte om een module te gebruiken. Je zou Remove-Module kunnen gebruiken om je sessie op te schonen en vervolgens de externe sessie te verbreken.
Nog een gebruik van Remove-Module is als je wijzigingen aanbrengt in een module en je geen nieuwe PowerShell-sessie wilt starten. In dat geval zou je Remove-Module gebruiken gevolgd door Import-Module om het opnieuw te laden in je sessie. Je kunt ook de parameter Force gebruiken bij Import-Module. Dit voltooit het ontladen en opnieuw laden van de module voor je.
Wat Maakt een PowerShell-module?
A module can consist of one or more files. To meet the minimum requirements for a module, you must have a module file. This can be a PSM1 file or any other module file such as a binary module file. To build upon that, your psm1 should have functions defined in it, or it will not be much use to anyone.
Hoewel er geen vereisten zijn voor hoe de functies eruit moeten zien of wat ze moeten doen, zijn er wel enkele richtlijnen. Het wordt meestal gewaardeerd om alle functies in een module te hebben die zijn gebouwd rond hetzelfde concept.
Modules Bevatten Vergelijkbare Functies
Bijvoorbeeld, de ActiveDirectory module bevat alleen functies die op de een of andere manier communiceren met Active Directory. Meestal bevatten de functienamen ook een voorvoegsel. Terugkomend op de ActiveDirectory module als voorbeeld, beginnen alle zelfstandige naamwoorden in de functienamen met AD.
Het gebruik van deze richtlijnen helpt bij het ontdekken van de functies. Stel je voor dat je zojuist deze nieuwe module hebt geïmporteerd en door de functies wilt bladeren. Dit is veel gemakkelijker te doen als alle functies een vergelijkbare naamstructuur hebben. Hoewel je modules vaak ziet beginnen met PS, is dit voorvoegsel officieel gereserveerd voor Microsoft-modules. Je zult waarschijnlijk geen problemen veroorzaken als je PS aan het begin van je module gebruikt, maar je kunt wel een conflict creëren met een andere module-naam.
Door deze richtlijnen te gebruiken, als je een heleboel functies hebt die allemaal te maken hebben met het communiceren met het register, zou je iets kunnen hebben zoals:
Module Manifesten
Om voort te bouwen op het tekstmodulebestand, kun je ook een module manifest opnemen. Deze bestanden hebben een PSD1 extensie en bevatten metagegevens over de module. Hierin zou je informatie opnemen over de auteur, een beschrijving van de module, andere vereiste modules, en vele andere attributen. Om naar een repository te publiceren, is het nodig om de velden Auteur en Beschrijving ingevuld te hebben.
Hier is een voorbeeld van een manifest dat we kunnen hebben voor onze registratiemodule:
Hoewel dit er in het begin intimiderend uit kan zien, heeft Microsoft een handige cmdlet waarmee je een module-manifest kunt genereren. De bijgeleverde opdracht is New-ModuleManifest. Om het bovenstaande manifest te genereren, zou je het volgende kunnen gebruiken:
Externe Helpbestanden
Je kunt ook externe helpbestanden tegenkomen in sommige modules. Ze kunnen worden geïdentificeerd aan de hand van de <ModuleName>-Help.xml aan het einde van de bestandsnaam. Deze externe helpbestanden bevatten dezelfde informatie die normaal gesproken zou worden opgenomen in de op commando’s gebaseerde hulp die je zou vinden in een functiedefinitie.
Hiervoor moet je ook # .ExternalHelp <ModulePath>-Help.xml aan je functie toevoegen om ervoor te zorgen dat deze correct werkt bij het gebruiken van het Get-Help-commando na het importeren van de module. Het is meestal alleen gebruikelijk om externe helpbestanden te zien bij zeer grote modules, en daardoor vallen ze buiten het bereik.
Gerelateerde Bestanden
Hoewel dit de meest voorkomende soorten bestanden zijn die je in een module zult zien, zijn dit niet de enige bestanden. Soms zie je binaire bestanden naast een tekstmodule, omdat er andere afhankelijkheden zijn. Door door de modulepaden te bladeren, kun je veel voorbeelden vinden van aanvullende bestandstypen in modules.
Om niet-standaard modulebestanden correct te publiceren, zou je andere bestanden moeten opnemen in de FileList-parameter in het manifest van je module.
Binnen het modulemanifest zul je veel andere parameters opmerken die momenteel leeg zijn. Je kunt deze gebruiken om andere vereisten te definiëren voor het gebruik van je module. Bijvoorbeeld, je kunt de versies van PowerShell definiëren waarmee de module kan werken. Als je probeert de module te importeren in een niet-ondersteunde versie van PowerShell, is dit wat je zou zien:
PSRepositories
Een van de belangrijke distributieopties voor modules is een PSRepository . Op een hoog niveau is een PSRepository een lokale locatie 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 het repository, maar dit beperkt je wel in de functionaliteit van je repository. Je kunt zelf een PSRepository hosten, of je kunt gebruikmaken van een van de vele opties die beschikbaar zijn op internet, zoals de PowerShell Gallery. Je kunt je PSRepositories zien door het Get-PSRepository commando te gebruiken.
Standaard heb je slechts één vermelding en dat is voor de PowerShell Gallery. Je zult merken dat het als onbetrouwbaar wordt aangeduid. Dit komt omdat PowerShell je ervan op de hoogte stelt dat je mogelijk code gebruikt die niet is geschreven en goedgekeurd door Microsoft wanneer je de PowerShell Gallery gebruikt. Dit betekent dat je expliciete toestemming moet geven voordat er modules van worden geïnstalleerd.
PSRepositories toevoegen
Je kunt ook je eigen repositories toevoegen. Om de PowerShell Gallery te vertrouwen, kun je Get-PSRepository -Name PSGallery | Set-PSRepository -InstallationPolicy Trusted uitvoeren of je kunt de waarschuwing accepteren de eerste keer dat je een module installeert vanuit de PowerShell Gallery.
Alle opdrachten die je zou gebruiken om met deze PSRepositories te communiceren, zijn te vinden in de PowerShellGet-module. Je kunt de functies hier bekijken:
De PowerShellGet-module moet mogelijk worden bijgewerkt voordat je met bepaalde repositories kunt communiceren.
Modules vinden
Nog een belangrijke functie van het gebruik van een PSRepository is het kunnen zoeken naar modules. Dit wordt bereikt met behulp van de Find-Module-opdracht. Er zijn meerdere manieren om te filteren om specifiek te vinden waar je naar op zoek bent, maar voor nu kun je zoeken naar de VMware-modules zoals dit:
Dit toont alle modules die beginnen met VMware. Hoewel de meeste van deze van VMware zijn, moet je naar het auteurattribuut kijken om te zien wie de module heeft gepubliceerd.
Aangezien iedereen naar PowerShell Gallery kan uploaden, zijn er duizenden modules beschikbaar. Dit betekent dat je mogelijk modules vindt die niet goed werken voor jouw gebruiksscenario. Veel modules die je zult vinden, zijn open source, dus je kunt bijdragen om de functionaliteit van de module te verbeteren.
Modules installeren
Om de Install-Module-opdracht te gebruiken, moet je een vertrouwde PSRepository hebben die de module host. Dit kan PowerShell Gallery zijn, een andere internet-PSRepository of een zelfgehoste site. Je kunt vanuit de Find-Module-opdracht doorpiping om de module eenvoudig te bevestigen voordat je deze installeert.
Je kunt ook de versie van een module definiëren door de MinimumVersion, MaximumVersion of RequiredVersion-parameters te gebruiken.
Om alle geïnstalleerde modules te zien die zijn geïnstalleerd met Install-Module, kun je Get-InstalledModule gebruiken. Dit toont een lijst van alle modules die zijn geïnstalleerd op het AllUsers-niveau of op het CurrentUser-niveau.
Modules verwijderen
Net zoals je een module kunt installeren, kun je ook een module verwijderen. Als de module niet is geïnstalleerd via het Install-Module-commando, kun je deze niet verwijderen met het Uninstall-Module-commando.
Uninstall-ModuleZoals je hier kunt zien, proberen we de ActiveDirectory module te verwijderen. Aangezien deze module niet is geïnstalleerd met Install-Module, zou je een foutmelding ontvangen bij het proberen te gebruiken van Uninstall-Module. Om deze module te verwijderen, moeten we dit doen door het omgekeerde te doen van wat je hebt gebruikt om de module te installeren.
Om een succesvolle verwijdering van een module te zien, kun je de VMware.PowerCLI module die je eerder hebt geïnstalleerd, verwijderen.
Zelfs nadat je VMware.PowerCLI hebt verwijderd, zie je dat er nog steeds veel afhankelijkheden zijn geïnstalleerd. Als je alle modules wilt verwijderen, kunnen we Get-InstalledModule VMware.* | Uninstall-Module -Force gebruiken.
De reden waarom je zoveel moeite hebt om deze module volledig te verwijderen, is omdat het zoveel afhankelijkheden heeft. Bovendien zijn sommige van deze modules afhankelijkheden van elkaar, daarom is de Force-parameter vereist.
Modules bijwerken
Nu je weet hoe je een module installeert en verwijdert, vraag je je misschien af hoe je een geïnstalleerde module kunt bijwerken.
Net als bij andere processen, als de module niet is geïnstalleerd met Install-Module, kun je deze niet bijwerken met de PowerShell-opdrachten. Je kunt Update-Module gebruiken om een module bij te werken naar de nieuwste versie of naar een specifiekere nieuwe versie.
Er is ook een schakelaar voor AllowPreRelease, waarmee je kunt bijwerken naar een versie die nog niet officieel is uitgebracht. Soms kan dit helpen, omdat er mogelijk een oplossing is voor een bug die je ervaart of een nieuwe functie is toegevoegd die je wilt gebruiken.
Update-ModuleInspecteren/Opslaan van een Module
Een van de minder gebruikte, maar zeer nuttige commando’s bij het beoordelen van modules voordat je ze gebruikt, is Save-Module. Met dit commando kun je een module downloaden naar een pad zonder deze te installeren.
Vervolgens kun je de bestanden inspecteren, en als de module geen binaire module is, kun je de code bekijken die de module vormt. Dit is niet alleen handig om ervoor te zorgen dat een module niets kwaadaardigs doet, maar ook om te leren hoe anderen hun modules structureren.
Save-ModuleIn dit voorbeeld wordt niet alleen de VMware.PowerCLI-module gedownload, maar ook alle afhankelijkheden. Hier is wat wordt weergegeven in de map van VMware.PowerCLI:
Dit is een goed voorbeeld om te laten zien dat er soms niet-standaard modulebestanden zijn opgenomen in de module, zoals de gebruiksrechtovereenkomst voor eindgebruikers.
Je eigen module schrijven
Je hebt nu gezien hoe je kunt communiceren met de module van iemand anders. Nu wil je leren hoe je je eigen module kunt maken, zodat je je code kunt optimaliseren voor schaalbaarheid.
Maak sjabloonbestanden
Je moet eerst een map maken voor al je modulebestanden. Nadat je de container hebt gemaakt, moet je je modulebestand maken. Zorg ervoor dat je modulebestand dezelfde naam heeft als je map, anders zal PowerShell de module niet correct ontdekken bij het publiceren.
Je wilt nu ook een manifest gebruiken, dus je moet het ook dezelfde naam geven als de container en het modulebestand.
Met de container, het modulebestand en het manifestbestand heb je een volledig functionerende module. Je kunt deze module publiceren naar een PSRepository en deze overal installeren waar je maar wilt. Hoewel, omdat het modulebestand leeg is, zal het waarschijnlijk niet veel nut hebben. Je kunt deze bestanden nog steeds gebruiken om het publiceren te testen en ervoor te zorgen dat je repository werkt.
Een PSRepository registreren
Voordat je je module kunt publiceren, moet je een andere PSRepository aan je sessie toevoegen. Voor testdoeleinden kun je een lokaal pad gebruiken als je PSRepository, omdat het eenvoudig op te zetten en af te breken is.
Normaal gesproken, als je een PSRepository met een directory zou opzetten, zou je ervoor willen zorgen dat meerdere computers er toegang toe hebben. Je kunt een lokale repository als volgt maken:
Als je alleen wilt downloaden vanuit de PSRepository en nooit wilt publiceren, kun je de parameter PublishLocation uitsluiten.
Je module publiceren
Aangezien u de installatiebeleid al hebt ingesteld op vertrouwd, krijgt u geen bevestiging om een module vanuit de repository te installeren. Nu u een nieuwe PSRepository beschikbaar hebt, kunt u uw module publiceren met Publish-Module -Name .\Scripts\ATARegistry -Repository LocalRepo.
Nadat u uw module hebt gepubliceerd, kunt u de bovenstaande commando’s gebruiken om de module te vinden en te installeren.
Nu u de module hebt geïnstalleerd, kunt u Get-Module gebruiken om te zien dat de module is geïmporteerd in uw lokale sessie. Omdat u geen functies hebt toegevoegd aan de FunctionsToExport-array in het manifest, is de ExportedCommands-eigenschap leeg.
Toevoegen aan uw module
Nu u weet dat u uw module kunt publiceren en installeren, kunt u wat functionaliteit toevoegen. U zou bijvoorbeeld een functie kunnen toevoegen om een registerkey terug te geven, zodat het er als volgt uitziet:
Als u het manifest ongewijzigd zou laten en zou proberen uw nieuwe module te uploaden, zou u tegen twee problemen aanlopen. Het eerste is dat u een foutmelding zou ontvangen waarin staat dat de versie van uw module al bestaat in uw repository. Dit komt omdat u de moduleversie niet hebt gewijzigd in het manifestbestand.
Functies van module exporteren
Het andere probleem zou zijn dat nadat u de module hebt geïmporteerd, u nog steeds geen functies zou zien in de ExportedCommands-eigenschap omdat u uw nieuwe functie niet aan het manifest hebt toegevoegd.
Hoewel uw functie zou kunnen worden gebruikt zonder deze op te nemen in de FunctionsToExport-lijst, zou dit het veel moeilijker maken om deze te vinden.
Zolang je geen lege array definieert,
@(), voor jeFunctionsToExport, worden alle functies, variabelen en aliassen standaard geëxporteerd.
Om deze twee problemen op te lossen, kun je je modulebestand bijwerken als volgt:
Nu je een functie aan je module hebt toegevoegd en je manifest hebt bijgewerkt om deze wijzigingen weer te geven, kun je de nieuwe versie van je module publiceren met dezelfde opdracht als voorheen.
Het kiezen tussen FunctionsToExport en Export-ModuleMember
Er zijn twee vergelijkbare functies in PowerShell bij het exporteren van moduleleden. De uitdaging is om tussen de twee te kiezen. Beide zijn correct, maar één kan beter voor je werken, afhankelijk van je behoeften.
Als je dynamisch wilt bepalen welke functies worden geëxporteerd, gebruik dan Export-ModuleMember omdat je een lijst met functies kunt doorgeven om te exporteren. Dit wordt meestal gebruikt bij het puntsgewijs laden van meerdere individuele functie PS1-bestanden. Door de interne functies in een privémap te verdelen en exporteerbare functies in een openbare map, kun je die eenvoudig exporteren door alle openbare functies door te geven aan de Export-ModuleMember functie.
A few notes about Export-ModuleMember:
- Het overschrijft het gedrag van
FunctionsToExport, dus als eenExport-ModuleMember-opdracht wordt gebruikt, heeft FunctionsToExport geen effect. Export-ModuleMemberexporteert geen variabelen en aliassen zonder deze expliciet te definiëren, in tegenstelling totFunctionsToExport, die die waarden wel exporteert.- Er kunnen meerdere
Export-ModuleMember-opdrachten worden gebruikt en deze worden gestapeld in plaats van voorrang te hebben.
Als je geen wijzigingen verwacht in je functielijst, werkt het prima om de FunctionsToExport-configuratie te gebruiken in het modulemanifest, en het vereist niet dat je variabelen en aliassen expliciet exporteert.
Je module bijwerken
Het laatste wat je moet doen is je module bijwerken in je sessie om de bijgewerkte bestanden te kunnen gebruiken. Met Update-Module ATARegistry download je de update die je zojuist hebt gepubliceerd naar het repository.
Nu kun je zien dat je de nieuwe versie van de module hebt en de functie kunt zien die je hebt gedefinieerd in het manifest.
Helpinhoud opbouwen
Een van de opties die eerder is overgeslagen, is het helpssysteem dat is ingebouwd in PowerShell. Op een gegeven moment heb je waarschijnlijk Get-Help gebruikt bij een functie. Deze informatie kan op twee hoofdmanieren worden toegevoegd.
De eerste is om op opmerkingen gebaseerde hulp toe te voegen aan de functiedefinitie. Dit is meestal de manier waarop veel modulemakers dit implementeren. De andere manier is om een extern helpbestand te gebruiken. Je kunt de Full-parameter gebruiken om alles te laten zien wat de hulp te bieden heeft.
Get-HelpZoals je kunt zien, is er eigenlijk niet veel informatie en de weinige informatie die je krijgt, zou waarschijnlijk niet nuttig zijn voor iemand.
Je kunt wat op opmerkingen gebaseerde hulp toevoegen aan je modulebestand om deze velden in het helpssysteem in te vullen. Je kunt alle opties voor op opmerkingen gebaseerde hulp lezen door Get-Help about_Comment_Based_Help te gebruiken.
Voor nu kunt u uw functie bijwerken zodat deze er als volgt uitziet. Dit is een lijst van de meest gebruikte helpparameters, 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:
Er zijn enkele speciale helpparameters, zoals .FORWARDHELPTARGETNAME. Met deze optie worden alle inkomende helpverzoeken doorgestuurd naar een ander commando. Dit kan worden gebruikt in een geval waarin de help dezelfde informatie voor meerdere commando’s moet tonen.
Nu u de help hebt toegevoegd, kunt u de versie in het modulemanifest bijwerken, de nieuwe versie publiceren en de geïnstalleerde versie voor uw sessie bijwerken zoals u eerder hebt gedaan.
Als u nu naar de help voor de functie kijkt, ziet u dat er veel meer informatie beschikbaar is. Dit is een geweldige manier om documentatie op te nemen over hoe de functies moeten worden gebruikt, vooral voor iemand die minder ervaring heeft en mogelijk niet snel kan begrijpen wat de module doet door naar de code te kijken.
Get-HelpIn het geval van een externe hulpbestand is de toegevoegde informatie hetzelfde, maar de informatie wordt in een apart bestand geplaatst en gekoppeld binnen de functie.
Als je kijkt in het AllUsers-modulepad, kun je de versie van de module en alle modulebestanden zien die je hebt geïnstalleerd.
Als je teruggaat naar je PSRepository-pad C:\Repo dat je eerder hebt gemaakt, zie je een heleboel NUPKG-bestanden. Er zal er een zijn voor elke versie die is gepubliceerd. Dit zijn gecomprimeerde versies van wat je hebt gepubliceerd bij het gebruik van Publish-Module.
Samenvatting
Zodra je vertrouwd bent met de PowerShell-console, PowerShell als taal en het schrijven van scripts, is het bouwen van je eigen modules de laatste stap. Modules stellen je in staat om nuttige tools te ontwikkelen in PowerShell. Als ze correct zijn ontworpen en gebouwd door modules te maken voor een specifiek doel, zul je onvermijdelijk merken dat je steeds minder code schrijft. Je zult je modulefuncties steeds meer in code refereren en daarop voortbouwen.
Modulefuncties stellen je in staat om de code die je herhaalt in scripts abstract te maken. Ze vertegenwoordigen “labels” om later in code te verwijzen die op elk moment kunnen worden aangeroepen, in plaats van het wiel opnieuw uit te vinden en te proberen uit te zoeken hoe je eerder je doel had bereikt. Modules zijn de uiteindelijke “verpakking” van PowerShell-code die gelijksoortige code bundelt om tijd te besparen bij problemen die je al hebt opgelost.