読者です 読者をやめる 読者になる 読者になる

素敵なおひげですね

PowerShellを中心に気分で書いているブログです。

WMF 5.1の新機能をざっくり説明する - 1. 新シナリオと機能 編

Windows PowerShell

WMF 5.1のプレビュー版も出たので、そろそろWMF 5.1の機能について触れないとダメかなと思いエントリを書きます。

一回では書ききれないので何回かに分けて書く予定です。

公式情報

WMF 5.1についてはMSDNの、

WMF 5.1 リリース ノート

でリリースノートが出ており、公式な情報はここから入手できます。

今回の対象範囲

今回は、

WMF 5.1 の新しいシナリオと機能

についてわかる範囲で補足を入れていく感じにします。

PowerShell のエディション

これは、 Nano ServerのPowerShellについてざっくりとした話でも触れましたがMSDNの説明の通りですね。

  • デスクトップ エディション: .NET Framework 上に構築されており、Server Core や Windows Desktop などの Windows の完全エディションで実行する PowerShell のバージョンを対象とするスクリプトおよびモジュールとの互換性を提供します。

  • コア エディション: .NET Core 上に構築されており、Nano Server や Windows IoT などの Windows の縮小エディションで実行する PowerShell のバージョンを対象とするスクリプトおよびモジュールとの互換性を提供します。

続いて、以下の項目についてはまだドキュメントが更新されていませんのでわかる範囲でざっと触れていきます。

PowerShell の実行エディションを特定する

過去のエントリで何回か触れていますが、PowerShellのエディションは$PSVersionTable.PSEditionで判定できます。

# PowerShell 5.1以降
PS C:\> $PSVersionTable.PSEdition
Desktop

文字列型で、DesktopエディションならDesktop、CoreエディションならCoreを返します。
そして、PowerShell 5.0以前にはこのプロパティはありませんので$nullか例外を返すことになります。

# PowerShell 1.0 ~ 5.0
PS C:\> $PSVersionTable.PSEdition
PS C:\>

# StrictMode を設定している場合は例外を返す場合がある
PS C:\> Set-StrictMode -Version 2.0
PS C:\> $PSVersionTable.PSEdition
このオブジェクトにプロパティ 'PSEdition' が見つかりません。プロパティが存在することを確認してください。
発生場所 行:1 文字:1
+ $PSVersionTable.PSEdition
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], PropertyNotFoundException
    + FullyQualifiedErrorId : PropertyNotFoundStrict

これらをまとめると、

PowerShellのバージョン エディション 判定方法
1.0 ~ 5.0 (便宜上)Desktop $PSVersionTable.PSEdition = $null または プロパティアクセス時に例外
5.1 ~ Desktop $PSVersionTable.PSEdition = "Desktop"
5.1 ~ Core $PSVersionTable.PSEdition = "Core"

となります。

特定の PowerShell バージョンに対するモジュールの互換性を宣言する

TODO : まだよくわかりません。わかったら追記します。
新しいドキュメントではこの項目自体が消滅していました...

CompatiblePSEditions で Get-Module の結果をフィルターする

こちらはNano ServerのPowerShellについてざっくりとした話でも触れた通り以下の様にしてフィルタできます。

Get-Module -ListAvailable | ? CompatiblePSEditions -Contains "Desktop"

ただ、現時点ではCompatiblePSEditions = $nullの様で、今後どうなるかはよくわかりません
結局既存のモジュールについてはCompatiblePSEditions = $nullのままとなりました。

互換性のある PowerShell のエディションで実行しない場合はスクリプトを実行させない

こちらもNano ServerのPowerShellについてざっくりとした話でも触れた様に#requires -PSEditionステートメントで実行可能なエディションを制限することができます。

以下の簡単なサンプルで試してみます。

DesktopOnlySample.ps1

#requires -PSEdition Desktop

Write-Output "これはDesktopエディション専用です!"

CoreOnlySample.ps1

#requires -PSEdition Core

Write-Output "これはCoreエディション専用です!"

実行結果(Windows 10 Insider Preview(Desktopエディション)で試した結果)

f:id:stknohg:20160730182021p:plain

確かにエディションが制限されていることがわかります。

カタログ コマンドレット

WMF 5.1ではコマンドレットからセキュリティカタログファイルの作成と検証ができる様になりました。

セキュリティカタログファイルについてざっくり説明すると、指定されたフォルダやファイルのハッシュを1つのファイル(.cat)にまとめたもので改竄検知に利用します。
デバイスドライバの開発によく使われる様ですが、わたしは門外漢なのでその辺はよくわかりません。

New-FileCatalogでカタログファイルを作成、Test-FileCatalogでカタログの検証を行います。
細かい説明はMSDNの内容を参照してください。

現時点では、日本語版の画像が存在しておらずリンク切れになっているのでこのエントリで試した結果を補足しておきます。

# カタログファイルの作成
New-FileCatalog -Path 'C:\Program Files\WindowsPowerShell\Modules\Pester\' -CatalogFilePath Pester.cat -CatalogVersion 2.0

作成結果

f:id:stknohg:20160730182151j:plain

できたカタログファイル

f:id:stknohg:20160730182219j:plain

f:id:stknohg:20160730182230j:plain

# カタログファイルの検証
Test-FileCatalog -Path 'C:\Program Files\WindowsPowerShell\Modules\Pester\' -CatalogFilePath Pester.cat -Detailed

検証結果

f:id:stknohg:20160730182310j:plain

ちなみに、該当フォルダを適当に変えてみるとTest-FileCatalogの結果がValidationFailedとなりきちんと改竄を検知できることがわかります。

f:id:stknohg:20160730183529p:plain

f:id:stknohg:20160730183716p:plain

モジュール分析キャッシュ

こちらについては...MSDNに書いてある通りなのでしょう...

PowerShellはあまり内部構造を公開していないので、この機能がどういった場合にうれしいのかちょっとわからない感じです。

キャッシュ機構についてはPowerShell 5.1以前でも${env:LOCALAPPDATA}\Microsoft\Windows\PowerShell\CommandAnalysisというフォルダがあり、このフォルダの内部に大量のキャッシュと思しきファイルが存在しています。
PowerShell 5.1ではこのキャッシュ機構が見直され、ユーザーが介在する余地が増えたと捉えるのが妥当でしょうか。

いまのところはPSModuleAnalysisCachePathPSDisableModuleAnalysisCacheCleanup環境変数があることを知っておけば十分な気がします。
トラブルシューティング時に利用する機会があるかもしれません。

モジュールのバージョンの指定

まったくドキュメント化されていない*1のですが、using moduleステートメント自体はWMF 5.0から存在していました。

using module [モジュール名]

Import-Moduleと同等のことができる機能です。

これは、

WMF 5.1 では、using module は PowerShell の他のモジュール関連構造と同様に動作します。 以前は、モジュールの特定のバージョンを指定する方法はありませんでした。
複数のバージョンが存在する場合、エラーが発生しました。

にある通りWMF 5.0ではバージョン指定はできません。
以下の例の様にPSReadline1.11.2が共存しているときにusing moduleを実行するとエラーとなります。

f:id:stknohg:20160730184607p:plain

f:id:stknohg:20160730184614p:plain

これがWMF 5.1では

using module @{ModuleName = 'PSReadLine'; RequiredVersion = '1.1'}

の様にしてバージョン指定可能になります。

実行結果はこんな感じです。

f:id:stknohg:20160730190227p:plain

また、バージョンを指定しない場合は最新バージョンがロードされます。

f:id:stknohg:20160730190400p:plain

Pester の機能強化

これはMSDNの通りですね。
細かい変更点はCHANGELOGを参照してください。

リンク

他の回のリンクはこちら。
その2その3その4

*1:激おこですよ