Adam the Automator

Arbejde med PowerShell-moduler er en vigtig del af PowerShell-automatiseringen. Når du begynder at lære PowerShell, er de første skridt normalt at bruge enkeltkommandoer. Dette fører til opbygning af scripts, som derefter fører til opbygning af funktioner.

Gennem at bruge funktioner kan du gøre dine scripts mere modulære. Dette giver dig mulighed for at kunne bruge den samme kode mange steder uden at skulle kopiere og indsætte til kode over det hele. Ved at bruge funktioner kan du bruge mindre tid på at foretage den samme redigering af den samme kode alle steder, hvor den bruges. I stedet kan du arbejde på at gøre din kode bedre et enkelt sted.

For at tage funktioner til det næste niveau kan du kombinere disse funktioner sammen i et modul.

Et modul er en samling af funktioner i en tekstfil med en psm1-udvidelse. Der er nogle valgfrie tilføjelser, f.eks. et modulmanifest og kommentarbaseret eller ekstern hjælp, som også kan medtages. Disse vil blive behandlet senere.

Forudsætninger

Jeg vil bruge Windows PowerShell 5.1 i denne artikel. Hvis du bruger en ældre version eller PowerShell Core, kan det variere med hensyn til de resultater, du ser.

Interaktion med moduler

Når du først åbner en PowerShell-session, starter du med to moduler. Det første er Microsoft.PowerShell.Utility, som indeholder mange grundlæggende PowerShell-funktioner, som du allerede bruger. Det andet modul er PSReadline. Du kan se disse startmoduler ved at bruge kommandoen Get-Module.

Dette sagt er dette ikke en komplet liste over alle tilgængelige moduler. Lige siden PowerShell 3 vil de moduler, der er installeret, blive importeret efter behov. Hvis du kører en ældre version af PowerShell, skal du bruge kommandoen Import-Module til først at importere modulet, før du kan bruge nogen af kommandoerne.

Der er tidspunkter, hvor du stadig ønsker at bruge Import-Module, selv i senere versioner. Hvis du ønsker at importere et modul, efter at det allerede er installeret, kan du bruge Import-Module på denne måde:

Mens Get-Module vil vise alle de moduler, der er importeret, vil du ikke se moduler, der endnu ikke er importeret. Du kan derefter bruge parameteren ListAvailable til at vise alle de andre moduler, der er tilgængelige.

Ikke alle kommandoer vises som standard

Egenskaben ExportedCommands indeholder en liste over alle de tilgængelige kommandoer, der eksporteres fra modulet. Du kan se nogle forskelle mellem denne liste og det, der står i modulfilen. Eksporterede kommandoer er en funktion indbygget i modulmanifestet, der gør det muligt for forfatteren at lade en funktion være skjult. Modulforfattere kan også bruge cmdlet Export-ModuleMember, men det ligger uden for denne artikels anvendelsesområde.

Modulforfattere ønsker måske at have en funktion skjult, fordi den er beregnet til at understøtte andre funktioner og ikke være brugervendt. For at få en funktion skjult skal forfatteren udelukke den fra FunctionsToExport-arrayet i manifestet. Her kan du se en udvidet visning af ExportedCommands-egenskaben.

Import af moduler

Der er mange måder at komme i gang med at bruge moduler på. Du kan manuelt importere modulet ved hjælp af stien til modulfilerne. Dette giver dig mulighed for at kunne teste og opdatere modulet uden at skulle gøre meget arbejde. Men det giver ikke meget portabilitet, da du så skal bruge den nøjagtige sti til modulet. PowerShell vil heller ikke auto-importere moduler, der ikke er i $env:PSModulePath-variablen.

Selektiv import af kommandoer

Du kan bruge Import-Module til kun at importere bestemte funktioner i stedet for hele modulet ved at bruge Function-parameteren. Dette kan spare tid, når du importerer moduler fra fjernsystemer, f.eks. Office 365-moduler.

Alle brugermoduler

Moduler, der er installeret for alle brugere, bliver placeret i C:\Program Files\WindowsPowerShell\Modules. Denne mappe indeholder mange forudtilføjede moduler, herunder alle moduler, der er installeret ved hjælp af Install-Module med standardområde AllUsers.

Moduler for nuværende brugere

Hvis du installerer et modul, men kun ønsker, at en enkelt bruger skal bruge det, er der et CurrentUser-område. Dette placerer modulfilerne i din Dokumentmappe på C:\Users\<<brugernavn>\Dokumenter\WindowsPowerShell\Moduler. Dette kan være nyttigt i et miljø, hvor du bruger mappeomdirigering med mappen Dokumenter.

I dette tilfælde kan du installere et modul på en computer og bruge det på en anden, da de begge vil dele den samme dokumentmappe.

Systemmoduler

For fuldstændighedens skyld er der også en modulmappe på C:\Windows\System32\WindowsPowerShell\1.0\Moduler. Teknisk set vil et modul, der er placeret i denne sti, blive importeret som en af de andre stier, men det anbefales ikke, da den er forbeholdt Microsofts systemmoduler.

Navngivning er vigtig

Du kan manuelt placere dit modul i en af disse stier for at gøre det tilgængeligt som standard ved en ny session, men du skal sikre dig, at du følger den krævede navngivning for moduler. Den mappe, som modulfilerne placeres i, skal have samme navn som psm1-modulfilen og psd1-modulmanifestet, hvis der er et.

Ved brug af Get-Module -ListAvailable, som vi havde nævnt tidligere, henvises der til disse stier. Du kan se alle modulstierne ved at bruge $env:PSModulePath -Split ';'. Du vil måske bemærke andre stier på listen end dem, der er vist her. Mange programmer tilføjer deres egne modulstier, når de installeres. Et af eksemplerne på dette er SQL, som har sine egne moduler inkluderet i sine egne modulstier.

Der er også nogle moduler, som du ville installere med en anden proces. Et af de mest betydningsfulde eksempler på dette er ActiveDirectory-modulet. Fra Windows 7 og frem til Windows 10 1803 ville du installere dette med RSAT-installationsprogrammet (Remote Server Administration Tools).

På nyere versioner af Windows 10 (1809+) er dette kun tilgængeligt via Features On Demand (funktioner på forespørgsel). Ved at installere RSAT installeres ActiveDirectory-modulerne og mange andre, som du vil bruge til at administrere andre Windows-roller. På Windows-server OS’er installeres disse moduler via Server Manager.

Import af fjernmoduler (Implicit Remoting)

Der er nogle tilfælde, hvor det ikke er praktisk at have et modul kørende lokalt. I stedet er det bedre at oprette forbindelse til en ekstern enhed og importere et modul, der er installeret på den. Når du gør dette, bliver kommandoerne faktisk udført på fjernmaskinen. Dette bruges ofte med Microsofts Office 365-moduler. Mange af dem opretter forbindelse til en Office 365-server, som derefter importerer et modul. Når du kører en af kommandoerne, bliver de kørt på fjernserveren, og derefter sendes output tilbage til din session.

En anden anvendelse af import af fjernmoduler er, når du ikke har modulet installeret lokalt. Dette er, hvad du ville få, hvis du ikke havde ActiveDirectory-modulet installeret, men prøvede at importere det.

For at importere et fjernmodul skal du først oprette en PSSession. Du kan bruge New-PSSession til at oprette sessionen. Derefter importerer du det modul, der er tilgængeligt på fjernenheden, ved hjælp af PSSession-parameteren med Import-Module.

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

Ved hjælp af denne metode til import af fjernmoduler kan du hurtigere udføre kode i et distribueret miljø. Hvis du f.eks. arbejder fra din computer, men de servere, du arbejder på, befinder sig på den anden side af USA, kan det tage betydeligt længere tid at køre visse kommandoer lokalt mod serverne. Hvorimod det er meget hurtigere at køre kommandoerne på en server og sende output tilbage til din lokale session.

Tilføjelse af et modulpræfiks

Du kan også tilføje et præfiks på de funktioner, der importeres fra fjernmaskinen. Denne mulighed er tilgængelig, når du importerer lokale moduler, men bruges sjældent uden for test af forskellige versioner af et modul side om side.

Hvis du kørte importkommandoen ovenfor, og dette er, hvad du ville se, når du ser på kommandoerne:

I dette tilfælde kan du bruge et præfiks for at vise, at det ikke er et lokalt modul. Dette kan bruges i tilfælde, hvor du importerer et modul, som også er tilgængeligt lokalt. Ved at tilføje præfikset mindskes forvirringen om, hvor koden udføres.

Fjernelse af moduler

Du kan også fjerne et modul fra den aktuelle session uden at bruge Remove-Module. Dette fjerner et modul fra den lokale session uden at fjerne modulfilerne. Du vil måske bruge dette i et tilfælde, hvor du brugte en fjernsession til at bruge et modul. Du kan bruge Remove-Module til at rydde op i din session og derefter afbryde fjernsessionen.

En anden anvendelse af Remove-Module er, hvis du foretager ændringer i et modul, og du ikke ønsker at starte en ny PowerShell-session. I dette tilfælde skal du bruge Remove-Module efterfulgt af Import-Module for at genindlæse det i din session. Alternativt kan du bruge parameteren Force sammen med Import-Module. Dette vil fuldføre af- og genindlæsningen af modulet for dig.

Hvad består et PowerShell-modul af

Et modul kan bestå af en eller flere filer. Hvis du skal opfylde minimumskravene til et modul, skal du have en modulfil. Dette kan være en PSM1-fil eller en hvilken som helst anden modulfil, f.eks. en binær modulfil. For at bygge videre på det skal din psm1 have funktioner defineret i den, ellers vil den ikke være til megen nytte for nogen.

Selv om der ikke er nogen krav til, hvordan funktionerne skal se ud eller hvad de skal gøre, er der nogle retningslinjer. Det er normalt at foretrække, at alle funktionerne i et modul er bygget op omkring det samme koncept.

Moduler indeholder funktioner af samme type

Til eksempel indeholder ActiveDirectory-modulet kun funktioner, der interagerer med Active Directory på en eller anden måde. Som regel indeholder funktionsnavnene også et præfiks. Hvis vi går tilbage til ActiveDirectory-modulet som eksempel, begynder alle navneord i funktionsnavnene med AD.

Brug af disse retningslinjer er med til at gøre det lettere at finde funktionerne. Forestil dig, at du lige har importeret dette nye modul og ønsker at gennemse funktionerne med et faneblad. Dette er meget lettere at gøre, hvis alle funktionerne har en lignende navnestruktur. Selv om du ofte kan se moduler, der starter med PS, er dette præfiks officielt kun forbeholdt Microsoft-moduler. Du vil sandsynligvis ikke skabe et problem, hvis du bruger PS i starten af dit modul, du kan skabe en konflikt med et andet modulnavn.

Med disse retningslinjer kan du, hvis du havde en masse funktioner, der alle havde at gøre med interaktion med registreringsdatabasen, have noget i retning af:

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

Modulmanifester

For at bygge videre på tekstmodulfilen kan du også inkludere et modulmanifest. Disse filer har en PSD1-udvidelse og indeholder metadata om modulet. Det er her, du vil medtage oplysninger om forfatteren, beskrivelsen af modulet, andre nødvendige moduler og mange andre attributter. For at kunne udgive til et repository kræves det, at Author– og Description-felterne er udfyldt.

Her er et eksempel på et manifest, som vi kan have for vores registermodul:

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

Mens dette kan se intimiderende ud i starten, har Microsoft en praktisk cmdlet, som du kan bruge til at generere et modulmanifest. Den medfølgende kommando er New-ModuleManifest. For at generere det manifest, der er vist ovenfor, kunne du bruge:

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.'

Eksterne hjælpefiler

Du kan også se eksterne hjælpefiler i nogle moduler. De kan identificeres ved <Modulenavn>-Help.xml i slutningen af filnavnet. Disse eksterne hjælpefiler indeholder de samme oplysninger, som normalt ville være indeholdt i den kommandobaserede hjælp, som du kan finde i en funktionsdefinition.

Dette ville også kræve, at du tilføjer # .ExternalHelp <ModulePath>-Help.xml til din funktion for at få den til at fungere korrekt, når du bruger kommandoen Get-Help efter at have importeret modulet. Det er normalt kun almindeligt at se eksterne hjælpefiler med meget store moduler, og på grund af det er de uden for anvendelsesområdet.

Selv om disse er de mest almindelige typer af filer, du vil se i et modul, er det ikke de eneste filer. Nogle gange vil du se binære filer ud over et tekstmodul, da der er andre afhængigheder. Ved at udforske gennem modulstierne kan du finde mange eksempler på yderligere filtyper i moduler.

For at få ikke-standardiserede modulfiler offentliggjort korrekt skal du inkludere andre filer i parameteren FileList i dit modulmanifest.

I modulmanifestet vil du bemærke mange andre parametre, som i øjeblikket er tomme. Du kan bruge disse til at definere andre krav til brugen af dit modul. Du kan f.eks. definere de versioner af PowerShell, som modulet kan arbejde med. Hvis du forsøger at importere modulet på en PowerShell-version, der ikke understøttes, vil du se følgende:

PSRepositories

Et af de vigtigste distributionsmuligheder for moduler er et PSRepository. På en 1000′ visning er et PSRepository et lokalt sted, hvor flere personer eller flere enheder kan få adgang til modulfilerne. Det er ofte webservere, hvor du kan udgive filer.

Du kan også bruge en mappe til repositoriet, men det begrænser dig i forhold til funktionaliteten af dit repositorium. Du kan selv være vært for et PSRepository, eller du kan benytte en af de mange muligheder, der findes på internettet, f.eks. PowerShell Gallery. Du kan se dine PSRepositories ved at bruge kommandoen Get-PSRepository.

Som standard vil du kun have én post, og det vil være for PowerShell Gallery. Du kan bemærke, at der vil stå untrusted. Det skyldes, at PowerShell gør dig opmærksom på, at du ved at bruge PowerShell Gallery kan bruge kode, der ikke er skrevet og godkendt af Microsoft. Det betyder, at du skal give udtrykkelig tilladelse, før der installeres nogen moduler fra det.

Tilføjelse af PSRepositories

Du kan også tilføje dine egne repositories. Hvis du vil stole på PowerShell Gallery, kan du køre Get-PSRepository -Name PSGallery | Set-PSRepository -InstallationPolicy Trusted, eller du kan acceptere advarslen første gang, du installerer et modul fra PowerShell Gallery.

Alle de kommandoer, som du vil bruge til at interagere med disse PSRepositories, findes i PowerShellGet-modulet. Du kan se funktionerne her:

Det kan være nødvendigt at opdatere PowerShellGet-modulet, før det kan interagere med visse repositories.

Søge efter moduler

En anden vigtig funktion ved brug af et PSRepository er muligheden for at søge efter moduler. Dette gøres ved hjælp af kommandoen Find-Module. Der er flere måder at filtrere på for at finde specifikt det, du leder efter, men indtil videre kan du søge efter VMware-moduler på følgende måde:

Dette vil vise alle de moduler, der begynder med VMware. Selv om de fleste af disse er fra VMware, skal du se på forfatterattributten for at se, hvem der har udgivet modulet.

Da alle kan uploade til PowerShell Gallery, er der tusindvis af moduler til rådighed. Det betyder, at du kan finde moduler, der ikke fungerer korrekt til dit brugsscenarie. Mange af de moduler, du finder, er open source-moduler, så du kan bidrage til dem for at forbedre modulets funktionalitet.

Installation af moduler

For at kunne bruge kommandoen Install-Module skal du have et PSRepository, der har tillid til modulet, som er vært for det. Dette kan være PowerShell Gallery, et andet PSRepository på internettet eller et selvhostet websted. Du kan bruge pipe fra kommandoen Find-Module for at være tilgængelig og nemt kunne bekræfte modulet, før du installerer det.

Du kan også definere versionen af et modul ved at bruge parametrene MinimumVersion, MaximumVersion eller RequiredVersion.

For at se alle de moduler, der er installeret ved hjælp af Install-Module, kan du bruge Get-InstalledModule. Dette vil vise alle de moduler, der er installeret i AllUsers-området eller dit CurrentUser-område.

Afinstallation af moduler

Som du kan installere et modul, kan du også afinstallere et modul. Hvis modulet ikke blev installeret via kommandoen Install-Module, kan du ikke afinstallere det med kommandoen Uninstall-Module.

Som du kan se her, forsøger vi at afinstallere ActiveDirectory-modulet. Da dette modul ikke er installeret med Install-Module, ville du få en fejl, når du forsøger at bruge Uninstall-Module. For at du kan afinstallere dette modul, skal vi afinstallere det ved at vende det om, som du brugte til at installere modulet.

For at se en vellykket afinstallation af et modul kan du afinstallere det VMware.PowerCLI-modul, du installerede tidligere.

Selv om du har afinstalleret VMware.PowerCLI, kan du se, at der stadig er mange afhængigheder, der er installeret. Hvis du ønskede at afinstallere alle modulerne, kunne vi bruge Get-InstalledModule VMware.* | Uninstall-Module -Force.

Grunden til, at du ville have så store problemer med at afinstallere dette modul fuldstændigt, er, at det har så mange afhængigheder. Desuden er nogle af disse moduler afhængige af hinanden, hvilket er grunden til, at parameteren Force er nødvendig.

Opdatering af moduler

Nu hvor du ved, hvordan du installerer og afinstallerer et modul, undrer du dig måske over, hvordan du opdaterer et modul, du har installeret.

Som andre processer kan du ikke opdatere et modul, der ikke er installeret ved hjælp af Install-Module, hvis modulet ikke er installeret ved hjælp af PowerShell-kommandoerne. Du kan bruge Update-Module til at opdatere et modul til den nyeste version eller til en nyere specifik version.

Der er også et skifte til AllowPreRelease, som vil gøre det muligt at opdatere til en version, der ikke er blevet officielt frigivet. Nogle gange kan dette være nyttigt, da der måske er blevet rettet en fejl, som du oplever, eller der er blevet tilføjet en ny funktion, som du gerne vil bruge.

Inspektion/Sparring af et modul

En af de langt mindre brugte kommandoer, som er meget nyttig, når man gennemgår moduler før brug, er Save-Module. Ved hjælp af denne kommando kan du downloade et modul til en sti uden at installere det.

Du kan derefter inspicere filerne, og hvis modulet ikke er et binært modul, kan du åbne og kigge på den kode, som modulet består af. Dette kan være godt, ikke kun for at sikre, at et modul ikke gør noget skadeligt, men også for at lære, hvordan andre strukturerer deres moduler.

I dette eksempel downloades ikke kun VMware.PowerCLI-modulet, men også alle afhængigheder. Her er, hvad der vises i mappen VMware.PowerCLI:

Dette er et godt eksempel på at vise, hvordan der nogle gange er ikke-standardiserede modulfiler inkluderet i modulet, f.eks. slutbrugerlicensaftalen.

Skrive dit eget modul

Du har nu set, hvordan du interagerer med en andens modul. Nu vil du gerne lære at oprette dit eget, så du kan begynde at optimere din kode med henblik på skalerbarhed.

Opret skabelonfiler

Først skal du oprette en mappe til alle dine modulfiler. Når du har beholderen, skal du oprette din modulfil. Du skal sørge for, at din modulfil har samme navn som din mappe, ellers vil PowerShell ikke opdage modulet korrekt, når du forsøger at udgive dit modul.

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

Nu vil du også bruge et manifest, du skal også navngive det på samme måde som containeren og modulfilen.

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'

Med containeren, modulfilen og manifestfilen har du et fuldt funktionsdygtigt modul. Du kan udgive dette modul til et PSRepository og begynde at installere det hvor som helst, du vil. Selv om, da modulfilen er tom, vil det sandsynligvis ikke gøre dig meget gavn. Du kan stadig bruge disse filer til at teste udgivelse for at sikre dig, at dit repository fungerer.

Registrering af et PSRepository

Hvor du kan udgive dit modul, skal du tilføje et andet PSRepository til din session. Til test kan du bruge en lokal sti som dit PSRepository, da det vil være nemt at oprette og nedbryde.

Normalt set, hvis du skulle oprette et PSRepository med en mappe, ville du sikre dig, at flere computere kan få adgang til det. Du kan oprette et lokalt repository på denne måde:

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

Hvis du kun skulle downloade fra PSRepository og aldrig udgive, kunne du udelukke parameteren PublishLocation.

Udgiv dit modul

Da du allerede har indstillet installationspolitikken til trusted, får du ikke en bekræftelse for at tillade, at et modul kan installeres fra repositoryet. Nu, hvor du har et nyt PSRepository til rådighed, kan du udgive dit modul ved hjælp af Publish-Module -Name .\Scripts\ATARegistry -Repository LocalRepo.

Når du har udgivet dit modul, kan du bruge kommandoerne fra ovenfor til at finde modulet og installere det.

Nu, hvor du har installeret modulet, kan du bruge Get-Module til at se modulet importeret i din lokale session. Da du ikke tilføjede nogen funktioner til arrayet FunctionsToExport i manifestet, er egenskaben ExportedCommands tom.

Tilføjelse til dit modul

Nu da du ved, at du kan udgive og installere dit modul, kan du begynde at tilføje nogle funktioner til det. Du kunne tilføje en funktion til at returnere en registreringsdatabasenøgle, så den ser således ud:

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

Hvis du lod manifestet forblive som det er og forsøgte at uploade dit nye modul, ville du løbe ind i to problemer. Det første er, at du ville få en fejlmeddelelse om, at versionen af dit modul allerede findes på dit repository. Det skyldes, at du ikke har ændret modulversionen i manifestfilen.

Eksport af modulfunktioner

Det andet problem ville være, at efter du har importeret modulet, ville du stadig ikke se nogen funktioner i ExportedCommands-egenskaben, fordi du ikke har tilføjet din nye funktion til manifestet.

Selv om din funktion ville kunne bruges, uden at den er opført i FunctionsToExport-listen, ville det gøre det meget sværere at finde den.

For at løse disse to problemer kan du opdatere din modulfil på følgende måde:

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

Nu, hvor du har tilføjet en funktion til dit modul, og du har opdateret dit manifest, så det afspejler disse ændringer, kan du udgive den nye version af dit modul ved hjælp af den samme kommando som før.

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

Opdatering af dit modul

Det sidste skridt vil være, at du skal opdatere dit modul i din session, så du kan bruge de opdaterede filer. Ved hjælp af Update-Module ATARegistry downloader du den opdatering, som du netop har offentliggjort til repositoryet.

Nu kan du se, at du har den nye version af modulet, og du kan se den funktion, som du har defineret i manifestet.

Opbygning af hjælpeindhold

En af de muligheder, der blev gennemgået tidligere, er det hjælpesystem, der er indbygget i PowerShell. Du har sikkert på et tidspunkt brugt Get-Help på en funktion. Disse oplysninger kan tilføjes på to primære måder.

Den første er at tilføje kommentarbaseret hjælp i funktionsdefinitionen. Dette er normalt den måde, som mange modulskrivere implementerer. Den anden måde er at bruge en ekstern hjælpefil. Du kan bruge parameteren Full til at vise alt, hvad hjælpen har at byde på.

Som du kan se, er der virkelig ikke mange oplysninger, og de få oplysninger, du får, vil højst sandsynligt ikke være nyttige for nogen.

Du kan tilføje noget kommentarbaseret hjælp til din modulfil for at udfylde disse felter i hjælpesystemet. Du kan læse om alle mulighederne for kommentarbaseret hjælp ved at bruge Get-Help about_Comment_Based_Help.

For nu kan du opdatere din funktion, så den ser ud som nedenfor. Dette er en liste over de mest almindeligt anvendte hjælpeparametre, men alle disse er stadig valgfrie, og der er andre, der kan tilføjes i stedet.

Nu ser din funktion således ud:

 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}

Der er nogle specielle hjælpeparametre, som .FORWARDHELPTARGETNAME. Denne indstilling videresender alle indkommende hjælpeanmodninger til en anden kommando. Dette kan bruges i et tilfælde, hvor hjælpen skal vise de samme oplysninger for flere kommandoer.

Nu, hvor du har tilføjet hjælpen, kan du opdatere versionen i modulmanifestet, udgive den nye version og opdatere den installerede version for din session, som du gjorde tidligere.

Hvis du nu kigger på hjælpen til funktionen, kan du se, at der er meget mere information tilgængelig. Dette er en god måde at inkludere dokumentation for, hvordan man bruger funktionerne, især for nogen, der er mindre erfarne og måske ikke hurtigt kan forstå, hvad modulet gør ved at se på koden.

I tilfælde af en ekstern hjælpefil er de tilføjede oplysninger de samme, men oplysningerne er placeret i en separat fil og linket i funktionen.

Hvis du kigger i AllUsersmodulstien, kan du se modulets version og alle de modulfiler, du har installeret.

Hvis du går tilbage til din PSRepository-sti C:\Repo, som du oprettede tidligere, kan du se en masse NUPKG-filer. Der vil være en for hver version, der blev offentliggjort. Det er komprimerede versioner af det, du offentliggjorde, da du brugte Publish-Module.

Resumé

Når du har styr på PowerShell-konsollen, PowerShell som sprog og skrivning af scripts, er opbygning af dine egne moduler det sidste skridt. Moduler giver dig mulighed for at begynde at udvikle nyttige værktøjer i PowerShell. Hvis de er designet og opbygget korrekt ved at oprette moduler til et enkelt formål, vil du uundgåeligt opleve, at du med tiden skriver mindre og mindre kode. Du vil begynde at referere til dine modulfunktioner i mere kode og bygge videre derfra.

Modulfunktioner giver dig mulighed for at abstrahere den kode, som du finder dig selv gentage i scripts. De repræsenterer “etiketter”, som du kan referere til senere i kode, der kan kaldes når som helst i stedet for at genopfinde hjulet og forsøge at finde ud af, hvordan du allerede havde opnået dit mål tidligere. Moduler er den endelige “indpakning” af PowerShell-kode, der grupperer enslydende kode for at undgå at spilde tid på problemer, som du allerede har løst.