Utilizarea PSScriptAnalyzer pentru a verifica PowerShell compatibilitate versiune

PSScriptAnalyzer versiunea 1.18 a fost lansat recent, și navele cu grafică nouă și noi reguli care pot verifica PowerShell script-uri pentru incompatibilități cu alte PowerShell versiuni și medii.

în această postare pe blog, prima dintr-o serie, vom vedea cum să folosim aceste noi reguli pentru a verifica un script pentru probleme care rulează pe PowerShell 3, 5.1 și 6.

așteaptă, Ce este PSScriptAnalyzer?,

PSScriptAnalzyer este un modul care oferă analiză statică (sau linting) și unele analize dinamice (bazate pe starea mediului) pentru PowerShell. Este capabil să găsească probleme și să remedieze obiceiurile proaste în scripturile PowerShell pe măsură ce le creați, similar cu modul în care compilatorul C# vă va oferi avertismente și va găsi erori în codul c# înainte de a fi executat.,

Dacă utilizați VSCode PowerShell extensie, s-ar putea fi văzut „verde squigglies” și rapoartele de probleme care PSScriptAnalyzer generează pentru script-uri autor:

puteți instala PSScriptAnalyzer pentru a utiliza pe propriile scripturi cu:

Install-Module PSScriptAnalyzer -Scope CurrentUser

PSScriptAnalyzer lucrări de funcționare o serie de reguli pe script-uri, fiecare dintre care evaluează în mod independent unele problemă., De exemplu AvoidUsingCmdletAliases controale care pseudonimele nu sunt folosite în scripturi, și MisleadingBackticks controale care backticks la capetele de linii nu sunt urmate de spațiu.

Pentru mai multe informații, consultați seria de bloguri PSScriptAnalyzer deep dive.

Introducerea verifica compatibilitatea normelor

noul compatibilitate verificare funcționalitate este asigurată de trei noi reguli:

• PSUseCompatibleSyntax, care verifică dacă o sintaxă utilizate într-un scenariu va lucra în alte PowerShell versiuni.,
• PSUseCompatibleCommands, care verifică dacă comenzile utilizate într-un script sunt disponibile în alte medii PowerShell.
• PSUseCompatibleTypes, care verifică dacă tipurile. NET și metodele/proprietățile statice sunt disponibile în alte medii PowerShell.

regula de verificare a sintaxei necesită pur și simplu o listă de versiuni PowerShell pe care doriți să le vizați și vă va spune dacă o sintaxă utilizată în scriptul dvs. nu va funcționa în niciuna dintre aceste versiuni.,

regulile de verificare a comenzilor și tipurilor sunt mai sofisticate și se bazează pe profiluri (cataloage de comenzi și tipuri disponibile) de pe platformele PowerShell utilizate în mod obișnuit. Acestea necesită configurare pentru a utiliza aceste profiluri, pe care le vom trece mai jos.

pentru această postare, vom analiza configurarea și utilizarea PSUseCompatibleSyntax și PSUseCompatibleCommands pentru a verifica dacă un script funcționează cu diferite versiuni de PowerShell. Ne vom uita la PSUseCompatibleTypes într-un post mai târziu, deși este configurat foarte similar cu PSUseCompatibleCommands.,

exemplu de Lucru: un mic script PowerShell

Imaginați-vă că avem o mică (și contrived) arhivă script salvate .\archiveScript.ps1:

Acest script a fost scris în PowerShell 6.2, și le-am testat ca functioneaza acolo. Dar vrem să o rulăm și pe alte mașini, dintre care unele rulează PowerShell 5.1, iar altele rulează PowerShell 3.0.în mod ideal, îl vom testa pe celelalte platforme, dar ar fi frumos dacă am putea încerca să eliminăm cât mai multe bug-uri posibil înainte de timp.,

verificarea sintaxei cu PSUseCompatibleSyntax

prima și cea mai ușoară regulă de aplicat este PSUseCompatibleSyntax. Vom crea unele setări pentru PSScriptAnalyzer pentru a activa regula, și apoi executați analiza pe script – ul nostru pentru a obține înapoi orice diagnosticare despre compatibilitate.

rularea PSScriptAnalyzer este simplă., Ea vine ca o PowerShell module, astfel încât odată ce este instalat pe module cale invoci pe fișierul cu Invoke-ScriptAnalyzer, astfel:

Invoke-ScriptAnalyzer -Path ".\archiveScript.ps1`

Un foarte simplu invocarea ca aceasta va rula PSScriptAnalyzer folosind reguli implicite și configurații pe scenariul pe care îl indica.

cu toate acestea, deoarece necesită o configurație mai bine direcționată, regulile de compatibilitate nu sunt activate în mod implicit. În schimb, trebuie să furnizăm câteva setări pentru a rula regula de verificare a sintaxei., În special, PSUseCompatibleSyntax necesită o listă a versiunilor PowerShell pe care le vizați cu scriptul dvs.

rularea acestui lucru ne va prezenta următoarea ieșire:

Acest lucru ne spune că ]::new() sintaxa pe care am folosit-o nu va funcționa în PowerShell 3. Mai mult decât atât, în acest caz, statul a propus de fapt un fix:

$diagnostics = Invoke-ScriptAnalyzer -Path .\archiveScript.ps1 -Settings $settings$diagnostics.SuggestedCorrections

sugerate de corecție este de a utiliza New-Object în loc., Modul în care este sugerat acest lucru ar putea părea puțin nefolositor aici cu toate informațiile despre poziție, dar vom vedea mai târziu de ce acest lucru este util.

acest exemplu de dicționar este un pic artificial, desigur (deoarece un hashtable ar veni mai natural), dar având o cheie aruncată în lucrările din PowerShell 3 sau 4 din cauza unui ::new() nu este neobișnuit. La PSUseCompatibleSyntax regula va avertiza de asemenea, despre cursuri, fluxuri de lucru și using declarații, în funcție de versiunile de PowerShell ești de creație pentru.,

nu vom face schimbarea sugerată încă, deoarece există mai multe pentru a vă arăta mai întâi.

Verificarea utilizării comenzii cu PSUseCompatibleCommands

acum vrem să verificăm comenzile. Deoarece compatibilitatea comenzii este un pic mai complicată decât sintaxa (deoarece disponibilitatea comenzilor depinde de mai mult decât ce versiune de PowerShell este rulată), trebuie să vizăm profilurile în schimb.profilele sunt cataloage de informații preluate de la mașinile de stoc care rulează medii PowerShell comune., Cele livrate în PSScriptAnalyzer nu se pot potrivi întotdeauna perfect mediului dvs. de lucru, dar se apropie destul de mult (există și o modalitate de a vă genera propriul profil, detaliat într-o postare ulterioară pe blog). În cazul nostru, încercăm să vizăm PowerShell 3.0, PowerShell 5.1 și PowerShell 6.2 pe Windows. Avem primele două profiluri, dar în ultimul caz va trebui să vizăm 6.1 în schimb. Aceste obiective sunt foarte apropiate, astfel încât avertismentele vor fi în continuare pertinente pentru utilizarea PowerShell 6.2. Mai târziu, când un profil 6.2 este pus la dispoziție, vom putea trece la asta.,

trebuie să ne uităm în documentația PSUseCompatibleCommands pentru o listă de profiluri disponibile în mod implicit. Pentru țintele dorite alegem:

numele lungi din dreapta sunt identificatori canonici de profil, pe care îi folosim în Setări:

s-ar putea să existe o întârziere prima dată când executați acest lucru, deoarece regulile trebuie să încarce cataloagele într-un cache. Fiecare catalog al unei platforme PowerShell conține detalii despre toate modulele și .,Ansambluri nete disponibile pentru PowerShell pe acea platformă, care pot fi de până la 1700 de comenzi cu 15.000 de parametri și 100 de ansambluri cu 10.000 de tipuri. Dar odată încărcat, analiza suplimentară a compatibilității va fi rapidă. Vom obține astfel de rezultate:

RuleName Severity ScriptName Line Message-------- -------- ---------- ---- -------PSUseCompatibleCommands Warning archiveScr 2 The parameter "FullyQualifiedName" is not available for ipt.ps1 command "Import-Module" by default in PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleCommands Warning archiveScr 12 The command "Get-FileHash" is not available by default in ipt.ps1 PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleCommands Warning archiveScr 18 The parameter "LeafBase" is not available for command ipt.ps1 "Split-Path" by default in PowerShell version "5.1.17763.316" on platform "Microsoft Windows Server 2019 Datacenter"PSUseCompatibleCommands Warning archiveScr 18 The parameter "LeafBase" is not available for command ipt.ps1 "Split-Path" by default in PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleCommands Warning archiveScr 19 The command "Compress-Archive" is not available by ipt.ps1 default in PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleCommands Warning archiveScr 23 The parameter "NoNewline" is not available for command ipt.ps1 "Out-File" by default in PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"

Acest lucru ne spune că:

• Import-Module nu suport -FullyQualifiedName în PowerShell 3.0;
• Get-FileHash nu există în PowerShell 3.0;
• Split-Path nu -LeafBase în PowerShell 5.1 sau PowerShell 3.,0;
• Compress-Archive nu este disponibil în PowerShell 3.0, și;
• Out-File nu suport -NoNewline în PowerShell 3.0

Un lucru pe care veți observa este că Get-FoldersToArchive funcție este de a nu fi avertizat despre. Aceasta deoarece compatibilitatea reguli sunt concepute pentru a ignora furnizate de utilizator comenzi; o comandă va fi marcat ca fiind incompatibile dacă este prezent în unele profil și nu în unul dintre obiectivele tale.,din nou ,putem schimba scriptul pentru a remedia aceste avertismente, dar înainte de a face acest lucru, vreau să vă arăt cum să faceți din aceasta o experiență mai continuă; pe măsură ce schimbați scriptul, doriți să știți dacă modificările pe care le faceți încalcă Compatibilitatea și acest lucru este ușor de făcut cu pașii de mai jos.

folosind un fișier de setări pentru invocarea repetată

primul lucru pe care îl dorim este să facem invocarea PSScriptAnalyzer mai automatizată și reproductibilă. Un pas frumos spre acest lucru este de a lua setările hashtable am făcut și transformându-l într-un fișier de date declarativ, separarea „ce” de „cum”.,

PSScriptAnalyzer va accepta o cale de a o PSD1 în -Settings parametru, astfel încât tot ce trebuie să facem este să ne întoarcem într-un hashtable PSD1, pe care o vom face ./PSScriptAnalyzerSettings.psd1. Notificare putem merge la setări pentru ambele PSUseCompatibleSyntax și PSUseCompatibleCommands:

Acum putem rula PSScriptAnalyzer din nou pe script-ul, folosind fișierul de setări:

Invoke-ScriptAnalyzer -Path ./archiveScript.ps1 -Settings ./PSScriptAnalyzerSettings.psd1

Acest lucru dă de ieșire:

RuleName Severity ScriptName Line Message-------- -------- ---------- ---- -------PSUseCompatibleCommands Warning archiveScr 1 The parameter "FullyQualifiedName" is not available for ipt.ps1 command "Import-Module" by default in PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleCommands Warning archiveScr 9 The command "Get-FileHash" is not available by default in ipt.ps1 PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleCommands Warning archiveScr 12 The parameter "LeafBase" is not available for command ipt.ps1 "Split-Path" by default in PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleCommands Warning archiveScr 12 The parameter "LeafBase" is not available for command ipt.ps1 "Split-Path" by default in PowerShell version "5.1.17763.316" on platform "Microsoft Windows Server 2019 Datacenter"PSUseCompatibleCommands Warning archiveScr 13 The command "Compress-Archive" is not available by ipt.ps1 default in PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleCommands Warning archiveScr 16 The parameter "NoNewline" is not available for command ipt.ps1 "Out-File" by default in PowerShell version "3.0" on platform "Microsoft Windows Server 2012 Datacenter"PSUseCompatibleSyntax Warning archiveScr 6 The constructor syntax ipt.ps1 "]::new()" is not available by default in PowerShell versions 3,4

Acum nu depindem de orice variabile mai, și au o zonă separată de spefication de analiză vrei., Folosind acest lucru, puteți pune acest lucru în medii de integrare continuă, de exemplu, pentru a verifica dacă modificările scripturilor nu încalcă Compatibilitatea.dar ceea ce ne dorim cu adevărat este să știm că scripturile PowerShell rămân compatibile pe măsură ce le editați. La asta se construiește fișierul de setări și, de asemenea, Unde este mai ușor să faceți modificările de care aveți nevoie pentru a face scriptul compatibil. Pentru aceasta, dorim să ne integrăm cu extensia Vscode PowerShell.,

integrarea cu VSCode pentru on-the-fly verificarea compatibilității

așa cum sa explicat la începutul acestui post, extensia Vscode PowerShell a suport builtin pentru PSScriptAnalyzer. În fapt, începând cu versiunea 1.12.0, PowerShell extensia nave cu PSScriptAnalyzer 1.18, ceea ce înseamnă că nu trebuie să facă altceva decât să creeze un fișier de setări pentru a face analiza de compatibilitate.

avem deja fișierul nostru de setări gata să treacă de la ultimul pas, deci tot ce trebuie să facem este să îndreptăm extensia PowerShell către fișierul din setările VSCode.,

puteți deschide setările cu Ctrl+, (utilizați Cmd în loc de Ctrl pe macOS). În vizualizarea setărilor, dorim PowerShell > Script Analysis: Settings Path. În settings.jsonvezi acest lucru este"powershell.scriptAnalysis.settingsPath"., Intră într-o cale relativă aici veți găsi un fișier de setări în spațiul nostru de lucru, așa că am pus un ./PSScriptAnalyzerSettings.psd1:

În settings.json vezi acest lucru va arata ca:

"powershell.scriptAnalysis.settingsPath": "./PSScriptAnalyzerSettings.psd1"

Acum, deschidere script-ul în VSCode vom vedea „verde squigglies” pentru compatibilitate avertismente:

În problemele panoul, veți obține un complet desrciption de toate incompatibilitățile:

Să repara erorile de sintaxa problemă în primul rând., Dacă vă amintiți, PSScriptAnalyzer furnizează o corecție sugerată la această problemă. VSCode integrează cu PSScriptAnalyzer propuse corecții și le poate aplica dacă faceți clic pe bec sau cu Ctrl+bara de Spațiu atunci când regiunea este sub cursor:

Aplică această schimbare, script-ul este acum:

alte incompatibilități nu trebuie corecții; de acum PSUseCompatibleCommands știe ce comenzi sunt disponibile pe fiecare platformă, dar nu ceea ce a substitui cu atunci când o comandă nu este disponibilă., Deci, avem nevoie doar să se aplice unele PowerShell cunoștințe:

Ne-am termina cu ceva de genul asta (specifice de implementare este lipsit de importanță, dar avem ceva care va lucra în toate versiunile):

ar trebui să observați că pe măsură ce tastați, VSCode afișează noua analiza a ceea ce scrii și verde squigglies picătură departe. Când am terminat, obținem o factură curată pentru compatibilitatea scriptului:

Acest lucru înseamnă că veți putea acum să utilizați acest script în toate versiunile PowerShell pe care trebuie să le vizați., Mai bine, acum aveți o configurație în spațiul dvs. de lucru, astfel încât să scrieți Mai multe scripturi, există o verificare continuă a compatibilității. Iar dacă țintele dvs. de compatibilitate se schimbă, tot ce trebuie să faceți este să schimbați fișierul de configurare într-un singur loc pentru a indica țintele dorite, moment în care veți obține o analiză pentru platformele țintă actualizate.sperăm că în această postare pe blog aveți o idee despre noile reguli de compatibilitate care vin cu PSScriptAnalyzer 1.18.,

Ne-am acoperit cum să configurați și să utilizați sintaxa compatibilitate verificarea regulă, PSUseCompatibleSyntax, iar comanda verificarea regulă, PSUseCompatibleCommands, ambele folosind un hashtable de configurare și setările PSD1.

ne-am uitat, de asemenea, la utilizarea regulilor de compatibilitate Cu extensia PowerShell pentru VSCode, în cazul în care acestea provin în mod implicit de la versiunea 1.12.0.

dacă aveți cea mai recentă versiune a extensiei PowerShell pentru VSCode (1.12.1), veți putea să setați fișierul de configurare și să obțineți imediat verificarea compatibilității.,

În următorul post pe blog, ne vom uita la modul de a utiliza aceste reguli și PSUseCompatibleTypes (care verifică dacă .NET tipuri și metode statice sunt disponibile pe platforme țintă) poate fi folosit pentru a vă ajuta să scrie script-uri care funcționează cross-platform pe Windows și Linux folosind Windows PowerShell și PowerShell Core.echipa PowerShell