używanie PSScriptAnalyzer do sprawdzania zgodności wersji PowerShell

Install-Module PSScriptAnalyzer -Scope CurrentUser

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

bardzo proste wywołanie, takie jak to, uruchomi PSScriptAnalyzer używając domyślnych reguł i konfiguracji na skrypcie, na który go wskazujesz.

jednak, ponieważ wymagają bardziej ukierunkowanej konfiguracji, reguły zgodności nie są domyślnie włączone. Zamiast tego musimy podać pewne ustawienia, aby uruchomić regułę sprawdzania składni., W szczególności PSUseCompatibleSyntax wymaga listy wersji programu PowerShell, do których kierujesz skrypt.

uruchamianie tego spowoduje wyświetlenie następującego wyjścia:

To mówi nam, że składnia]::new() nie będzie działać w PowerShell 3. Co więcej, w tym przypadku reguła rzeczywiście zaproponowała poprawkę:

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

sugerowaną poprawką jest użycie New-Object., Sposób, w jaki jest to sugerowane, może wydawać się tutaj nieco nieprzydatny ze wszystkimi informacjami o pozycji, ale zobaczymy później, dlaczego jest to przydatne.

Ten przykład słownika jest oczywiście trochę sztuczny (ponieważ hashtable pojawiłby się bardziej naturalnie), ale posiadanie klucza wrzuconego do pracy w PowerShell 3 lub 4 z powodu::new() nie jest rzadkością. Reguła PSUseCompatibleSyntax ostrzega również o klasach, przepływach pracy i instrukcjach using w zależności od wersji PowerShell, dla których tworzysz.,

nie zamierzamy jeszcze wprowadzać sugerowanych zmian, ponieważ jest więcej do pokazania w pierwszej kolejności.

sprawdzanie użycia poleceń za pomocą PSUseCompatibleCommands

teraz chcemy sprawdzić polecenia. Ponieważ kompatybilność poleceń jest nieco bardziej skomplikowana niż składnia (ponieważ dostępność poleceń zależy bardziej od tego, jaka wersja PowerShell jest uruchamiana), musimy kierować profile.

profile są katalogami informacji pobranych z maszyn stockowych pracujących w popularnych środowiskach PowerShell., Te dostarczane w PSScriptAnalyzer nie zawsze idealnie pasują do Twojego środowiska pracy, ale są bardzo blisko (istnieje również sposób na wygenerowanie własnego profilu, opisany w późniejszym poście na blogu). W naszym przypadku staramy się kierować PowerShell 3.0, PowerShell 5.1 i PowerShell 6.2 na Windows. Mamy dwa pierwsze profile, ale w ostatnim przypadku musimy celować w 6.1. Cele te są bardzo bliskie, więc ostrzeżenia będą nadal istotne dla korzystania z PowerShell 6.2. Później, gdy udostępnimy profil 6.2, będziemy mogli przejść na ten profil.,

w dokumentacji PSUseCompatibleCommands musimy znaleźć listę profili dostępnych domyślnie. Dla naszych pożądanych celów wybieramy:

długie nazwy po prawej stronie są kanonicznymi identyfikatorami profilu, których używamy w Ustawieniach:

może wystąpić opóźnienie przy pierwszym uruchomieniu, ponieważ reguły muszą załadować katalogi do pamięci podręcznej. Każdy katalog Platformy PowerShell zawiera szczegóły wszystkich modułów i .,NET assemblies dostępne dla PowerShell na tej platformie, który może być aż 1700 poleceń z 15,000 parametrów i 100 zespołów z 10,000 typów. Ale po załadowaniu, dalsza analiza zgodności będzie szybka. Otrzymujemy dane wyjściowe w następujący sposób:

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"

To mówi nam, że:

• Import-Module nie obsługuje -FullyQualifiedName w PowerShell 3.0;
• iv id=”ca0af0f6f8″
  nie istnieje w PowerShell 3.0;

• Split-Pathnie ma -LeafBasew PowerShell 5.1 lub PowerShell 3.,
• Compress-Archive nie jest dostępny w PowerShell 3.0, a;
• Out-File nie obsługuje -NoNewline w PowerShell 3.0

jedną rzeczą, którą zauważysz, jest to, że Get-FoldersToArchive funkcja nie jest ostrzegana. Dzieje się tak, ponieważ reguły zgodności są zaprojektowane tak, aby ignorować polecenia dostarczone przez użytkownika; polecenie będzie oznaczone jako niezgodne tylko wtedy, gdy jest obecne w jakimś profilu, a nie w jednym z celów.,

ponownie możemy zmienić skrypt, aby naprawić te ostrzeżenia, ale zanim to zrobimy, chcę pokazać, jak sprawić, aby to bardziej ciągłe doświadczenie; jak zmienić skrypt, chcesz wiedzieć, czy wprowadzone zmiany łamią kompatybilność, a to jest łatwe do zrobienia z poniższych kroków.

używanie pliku ustawień do wielokrotnego wywołania

pierwszą rzeczą, jakiej chcemy, jest uczynienie wywołania PSScriptAnalyzer bardziej zautomatyzowanym i powtarzalnym. Miłym krokiem w tym kierunku jest przyjęcie ustawień hashtable, które zrobiliśmy i przekształcenie go w deklaratywny plik danych, oddzielając „co „od”jak”.,

PSScriptAnalyzer zaakceptuje ścieżkę do PSD1 w parametrze -Settings, więc wszystko, co musimy zrobić, to zmienić nasz hashtable W plik PSD1, który zrobimy ./PSScriptAnalyzerSettings.psd1. Zauważ, że możemy scalić ustawienia zarówno dla PSUseCompatibleSyntax jak i PSUseCompatibleCommands:

teraz możemy ponownie uruchomić PSScriptAnalyzer w skrypcie używając pliku ustawień:

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

daje to wyjście:

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

teraz nie jesteśmy już zależni od żadnych zmiennych, i mamy osobną specyfikację analizy, którą chcesz., Korzystając z tego, możesz umieścić to w środowiskach ciągłej integracji, na przykład, aby sprawdzić, czy zmiany w skryptach nie naruszają zgodności.

ale tak naprawdę chcemy wiedzieć, że skrypty PowerShell pozostają kompatybilne podczas ich edycji. Do tego buduje się plik ustawień, a także miejsce, w którym najłatwiej wprowadzić zmiany potrzebne do zapewnienia kompatybilności skryptu. W tym celu chcemy zintegrować z rozszerzeniem VSCode PowerShell.,

integracja z VSCode do sprawdzania zgodności w locie

jak wyjaśniono na początku tego postu, rozszerzenie VSCode PowerShell ma wbudowaną obsługę PSScriptAnalyzer. W rzeczywistości, począwszy od wersji 1.12.0, rozszerzenie PowerShell jest dostarczane z PSScriptAnalyzer 1.18, co oznacza, że nie musisz robić nic innego niż utworzyć plik ustawień, aby wykonać analizę zgodności.

mamy już gotowy plik ustawień od ostatniego kroku, więc wszystko, co musimy zrobić, to wskazać rozszerzenie PowerShell na plik w Ustawieniach VSCode.,

możesz otworzyć ustawienia za pomocą Ctrl+, (użyj Cmd zamiast Ctrl na macOS). W widoku Ustawienia chcemy PowerShell > Script Analysis: Settings Path. W widoku settings.json jest to "powershell.scriptAnalysis.settingsPath"., Wpisanie ścieżki względnej spowoduje znalezienie pliku ustawień w naszym obszarze roboczym, więc po prostu umieścimy ./PSScriptAnalyzerSettings.psd1:



w widoku settings.json wygląd ten będzie wyglądał następująco:

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

teraz, otwierając skrypt w VSCode widzimy „Green squigglies” dla ostrzeżeń o zgodności:



w okienku problemy otrzymasz pełny opis wszystkich niezgodności:



najpierw naprawimy problem ze składnią., Jeśli pamiętasz, PSScriptAnalyzer dostarcza sugerowaną korektę tego problemu. VSCode integruje się z sugerowanymi poprawkami PSScriptAnalyzer i może je zastosować, jeśli klikniesz na żarówkę lub za pomocą Ctrl+Spacja, gdy region znajduje się pod kursorem:



stosując tę zmianę, skrypt jest teraz:

Pozostałe niezgodności nie mają poprawek; na razie PSUseCompatibleCommands wie, jakie polecenia są dostępne na każdej platformie, ale nie to, co zastąpić, gdy polecenie nie jest dostępne., Musimy więc po prostu zastosować trochę wiedzy PowerShell:

kończymy z czymś takim (konkretna implementacja jest nieistotna, ale mamy coś, co będzie działać we wszystkich wersjach):

powinieneś zauważyć, że podczas pisania, VSCode wyświetla nową analizę tego, co piszesz i zielone squigglies znikają. Kiedy skończymy, otrzymamy czysty rachunek zdrowia dla kompatybilności skryptów:



oznacza to, że będziesz mógł używać tego skryptu we wszystkich wersjach PowerShell, których potrzebujesz., Lepiej, teraz masz konfigurację w obszarze roboczym, więc jak piszesz więcej skryptów, nie jest ciągłe sprawdzanie zgodności. A jeśli zmienią się cele dotyczące zgodności, wystarczy zmienić plik konfiguracyjny w jednym miejscu, aby wskazać pożądane cele, w którym to momencie otrzymasz analizę zaktualizowanych platform docelowych.

podsumowanie

mam nadzieję, że w tym wpisie na blogu zapoznałeś się z nowymi zasadami kompatybilności, które pochodzą z PSScriptAnalyzer 1.18.,

omówiliśmy, jak skonfigurować i używać reguły sprawdzania zgodności składni PSUseCompatibleSyntax oraz reguły sprawdzania komend PSUseCompatibleCommands, zarówno przy użyciu konfiguracji hashtable, jak i Pliku settings PSD1.

przyjrzeliśmy się również użyciu reguł zgodności z rozszerzeniem PowerShell dla VSCode, gdzie domyślnie pochodzą one z wersji 1.12.0.

Jeśli masz najnowszą wersję rozszerzenia PowerShell dla VSCode (1.12.1), będziesz mógł ustawić plik konfiguracyjny i natychmiast sprawdzić zgodność.,

w następnym wpisie na blogu przyjrzymy się, jak korzystać z tych reguł i Psusecompatibletypy (które sprawdzają, czy typy.NET i statyczne metody są dostępne na platformach docelowych) mogą być używane do pisania skryptów działających między platformami Windows i Linux przy użyciu Windows PowerShell i PowerShell Core.

Rob Holt

inżynier oprogramowania

zespół PowerShell