コマンドレットのパラメータを列挙してみる。2017の1日目です。Calendar、今年も始まりました。ここ数年は私がトップバッターを務めさせていただいて、1年間のPowerShell界隈の出来事をさくっとまとめてみています。Editionが各々正式版としてリリースされ、さらにはPowerShellがオープンソース化、マルチプラットフォーム展開を始めるという大きな変革があった年でした。今年2017年は昨年ほど大きな変化はないとはいえ、昨年のOSS化からのマルチプラットフォーム展開を着実に進行させた年だと言えると思います。以下、いくつかトピックを紹介します。Updateにも同梱されました。R2)のためのものです。Win10/2016に同梱のPester(テストフレームワーク)やPSReadline(コンソール入力支援)についてはWMF5.1には含まれていないので、別途PowerShellGetでインストールするのがお勧めです。ShellではまずBashがサポートされていましたが、今年9月にPowerShellもサポート(まだプレビューですが)されました。PowerShellのコマンドが使え、AzureのリソースにAzure:ドライブを介してアクセスすることが可能です。5.1であることはちょっと念頭においておいたほうがいいかもしれません。PowerShellの全機能がサポートされてないからだと思うんですが、今後に期待ですね。Codeの正式版(1.0)が5月に公開されました。現時点での最新バージョンは1.5.1となっています。ISEの方が多機能だったようにも思いますが、今はもう完全にISEの機能を追い越したんじゃないかと思います。Analyzer、テストフレームワークのPester、プロジェクト管理機能を提供するPlasterなどが統合されており、本格的な開発環境となっています。Coreの開発が各々可能です。VSCodeの開発に注力されることになります。ISEはとにかく標準添付である(GUI有効ならサーバーOSでも動く!)という強みがあり、シンプルなスクリプト記述であればそこそこ便利に使えるので、これからもシチュエーションに応じて使い分けて行けば良いのかなと思います。Candidate)となりました。6.0.0のGAリリースは来年1月になるそうです。OSS化直後からRCに至るまでの変更点は多岐に渡り、とても一言で説明できるものではないですが、ポイントとしては以下の3点に集約されるんじゃないかと思います。5.1のコードそのままであったと言ってよいかと思います。10年以上増改築が繰り返されたコードが突如、全世界に公開されたわけです。コミュニティの力でバグや変な仕様といった問題点が洗い出され、どんどん修正されていきました。不足していると思われる機能はどんどん追加されました。既存コマンドレットのパラメータが増えるというパターンが多かったように思います。特筆すべきは、破壊的変更であっても妥当性があれば躊躇せずに取り入れていったことかと思います。Coreでは細かいところで非互換性が色々出ていますので、移行の際には注意を要します。5.1なので、Windowsでしか動作しない部分が多々ありました。それをLinuxやMac環境でも動作するように多くの修正が加えられました。Edition相当のPowerShellをビルドすることが可能でした。Core」であることが明確にされました。CLR対応のコードのみとなりました。5.1に含まれているすべてのコマンドレットを網羅しているわけではありません。6.0には含まれておらず、α版の段階では実行も不可能(だったはず)でした。2.0がサポートされました。Coreでも実行可能になりました。PowerShellはどうなるのか、という話について。5.1については、今後もサポートライフサイクルに則り、重大なバグフィックスやセキュリティパッチ提供等のサポートは継続されます。PowerShellも同様です。Coreへと移行します。PowerShellとは無関係ということです。CoreがWindowsに同梱されるかどうかについては言及されておらず、今のところは不明です。以下は私見になります。Serverの管理はするが、Linuxとかは特に...というユーザーはこれからどうすべきか?という点は割と悩ましいところだと思います。Serverを管理するスクリプトが現時点であるなら、それを無理に今すぐCore対応にする必要はないと思います。現時点で今すぐCoreに移行すべき理由というのはとくに無いと感じます。Coreで追加、改善された機能はあるものの、Coreには無い機能もたくさんあるからです。PowerShell用に作れば良いのではないかと。OS付属のコマンドレットの動作は確実に保証されているわけですから。2016は半期に一度の大型アップデートで新機能が次々追加されていきます。Coreが含まれるようになったり、Coreのみ対応のコマンドレットが追加される可能性は無きにしもあらずなのではないかとも思います。Coreの状況をチラ見しつつ、未来に備えておく必要はあると思います。Windows10/Server2016の「次」も見据えて。それとPowerShellでWindowsもLinuxも面倒みていきたい、という野心がある方は、Coreを採用していくのがいいのではないかと思います。現状しばらくは茨の道ではあるとは思います。あとはスクリプトやモジュールを作成し公開する方は、より多くの環境で使われるように、可能であればCore対応を進めるのは悪くないんじゃないかと思います。Core構想とか、なにげに結構いろいろ話題はありました。Coreとしてはこれからも活発に動いていくものと思います。注目していきたいですね。そんな2017年の締めくくり、今年はどんな記事が集まるでしょうか。2017の参加、お待ちしております。|Tweet昨日10/11のPowerShell勉強会#4にお越しいただいた方、どうもありがとうございました。スタッフ一同、これからも定期的に開催していこうと考えておりますので、ぜひともよろしくお願い致します。私のセッション資料を公開します。くま横浜で行ったものとほとんど同じですが、v5関係のスライドを少しだけ修正しています。今回は高度な関数とコマンドレットの作り方を主に取り上げていますが、要するに、PowerShellコマンドはPowerShellスクリプトでもC#でもほぼ同じようにして同じようなものが書ける、ということなのです。基本を押さえればどちらにも対応可能です。両者は状況に応じて使い分ければOKかと思います。PowerShellよりC#が得意、というならばコマンドレットを書くと良いですし、スクリプト的なお手軽なコードで書きたい場合は高度な関数、とかですね。速度が求められる部分とか、.NETアセンブリを多用する部分だけコマンドレットにして、他を高度な関数にする、あるいは、主要部はコマンドレットにして、その他はコマンドレットのラッパー的な高度な関数を用意する、のように両者を組み合わせたモジュールもよくあります。以下はデモ用のサンプルスクリプトです。高度な関数の雛型的なものになります。使い方はスライド本文を参照してください。}}以下はデモで用いたC#のコードです。コマンドレットクラスの雛型的なものになっています。ビルドの際はSDKに含まれるPowerShell関係のdllを参照設定してください(詳しくはスライド)。実行してインポートして下さい。以下の例だとGet-Baz、Set-Bazの2コマンドレットがインポートされます。|Tweet8/23わんくま横浜勉強会で、PowerShellコマンドの書き方というセッションをしたのですが、その際、株式会社Codeerさんが公開されているFriendlyというライブラリを使ったコマンドレットを動作させるデモを行いました。準備の時間がなくて、突貫工事で作ったサンプルで恐縮ですが、公開することにします。2010以降でC#のクラスライブラリを新規作成する。ある.dllを参照設定する。4.5、対象プラットフォームをx64にする。上記のコードを貼り付ける。NuGetでFriendlyおよびFriendly.Windowsを追加する。上記をビルドして生成したDLLにはGet-FormControlTextと、Set-FormControlTextの2つのコマンドレットが含まれます。6制限事項フォーム直下に配置されたコントロールしか取得できない(と思います)。Formアプリケーションにしか対応していない(と思います)。x64アプリしか操作できない(と思います。x86用はアセンブリを分ける必要がある??)。sensitiveでワイルドカード不可です。(この辺ただの手抜きですが)今後の方針?上のコードをみてもらえればわかると思いますが、ちょっと触ってみたら一応動くものができるくらい、Friendlyは分かりやすいです。皆さんもぜひ使ってみてください。本来は、テキストじゃなくてコントロールそのものをGetしたりSetしたりInvoke(クリックとか)したりできるようにしたかったんですが、Controlはシリアル化できないオブジェクトなので、Friendlyで実物を持ってきてコマンドレットに出力する、というのは無理でした。何らかのプロキシオブジェクトみたいなのでラップしたりすれば良いかと思います。それにしてもPowerShellとFriendlyの組み合わせはものすごい可能性を秘めている予感がします。システム管理方面では...セッションでもやりましたが、PowerShellコマンドレットベースのアプリケーションを作ると、GUIとCUIのいいところどりが出来る、とはいうものの、コマンドインターフェースがなくGUIオンリーのアプリケーションはまだまだたくさんあるのが現実かと思います。いうアプリケーションも、PowerShellデフォルトの機能のみではつらいですが、上記のようにFriendlyを併用すれば、GUI操作の自動化が容易になると思います。開発方面では...C#でFriendlyを使ったGUIのテストコードを書く以外に、上記のようなFriendlyの機能をラップしたコマンドレットを用意することで、PowerShellスクリプトでもテストコードを書くことができるようになると思います。その際、Pester等のPowerShell用テストフレームワークを併用すると、より一貫したテストコードが記述できるようになるんじゃないかと思います。2014の大阪会場にお越しいただき、ありがとうございました。私のセッションスライドを公開します。前回のエントリーでも書きましたが、DSCについては何度かセッションをやってきており、今回が一応の集大成的なものとなるかと思います。今回はDSCというPowerShell4.0で追加された応用的な内容でしたが、4/12に開催されるPowerShell勉強会@大阪では基礎的なところからセッションをやる予定です。PowerShell勉強会@大阪については後ほど詳しく紹介エントリーを上げます。今回デモをやろうとしたんですが、見事に失敗してしまいました。申し訳ありません!原因としてはHyper-Vにドメインコントローラー(兼、Configuration配布用サーバー)と設定対象サーバーの2台を同一ドメインに所属させていたのですが、手違いで設定対象サーバーからDCへの認証ができなくなっていて、結果、DSC反映時に必要なKerberos認証に失敗したためでした。3.0でも注意深くやらないとダメですね。直前まではうまく動いてたんですけどもね...DCはやはり独立して用意すべきでした本番ではデモに失敗したんですが、環境を再整備して動作することを確認しました。そこで、今回、デモで用いる予定だったスクリプトを一式、公開する事にしました。こちら:dsc_demo.zip使用方法を以下に説明します。すべては無保証なので、必ず、壊れてもいいサーバーを新規で用意してください。デモ環境をHyper-Vの仮想サーバーとしておくと、DSC適用前の状態のスナップショットを取れるのでいつでもデモ実行前の状態に戻せて便利です。R2をGUI有効にしてインストールする。Rollupを適用してGA相当にアップデートする(ビルド番号6.3.9600.16394の状態にする)。両サーバーを同一ドメインに所属させる。両サーバー間でKerberos認証が通りWinRMでリモート接続できることを確認しておく。targetとしてtargetサーバーにリモート接続できるかどうかで確認できます。dsc_demo.zip中に含まれるdscpullフォルダをConfiguration配布用サーバーのC:\直下にコピーする。dsc_demo.zip中に含まれるtargetフォルダを設定対象サーバーのC:\直下にコピーする。Pushモードのデモこのデモでは、dscpullサーバーでDSCをpushモードで実行することにより、「targetサーバーにIISをインストールし、Webサイトを作成し、開始する」という操作を適用します。よって、事前にtargetサーバーにはIISが入っていないことを確認しておいてください。targetサーバーのInstall_Website_Resource.ps1を実行する。この操作により、xWebAdministrationリソースモジュールがtargetサーバーに配置されます。dscpullサーバーのStart_Website_of_Target.ps1を実行する。この操作により、xWebAdministrationリソースモジュールがdscpullサーバーにも配置され、xWebSite等のリソースを呼び出すConfigurationに従ってMOFファイルを生成し、Start-DscConfigurationコマンドレットによって実際にMOFファイルの内容をtargetサーバーに反映させます。※Pushモードの場合、カスタムリソースを利用する際は、実行側と対象の双方にカスタムリソースの事前配置が必要です。Start_Website_of_Target.ps1の実行が終了したら、targetサーバーをチェックして下さい。Siteは停止状態となり、MyWebSiteというサイトが作成され開始されていると思います。http://target/を開いてみてください。targetサーバーの設定を色々と変更して(Webサイトを停止する、削除する、IISをアンインストールする、InetPubフォルダのコンテンツを削除するetc)、再度Start_Website_of_Target.ps1を実行した場合でも、同じ設定に戻ることを確認してください。Serviceをインストールし、PullサーバーとしてMOFファイルを配布できるようにします。続いてtargetサーバーの設定をPullモードにし、dscpullサーバーから設定を定期的に取得、反映させるようにします。(このデモでは「印刷サービス」(プリントサーバー)をインストールするConfigurationをサンプルとして利用しています)dscpullサーバーのInstall_DSC_Service.ps1を実行する。この操作により、xPSDesiredStateConfigurationリソースモジュールがdscpullサーバーに配置され、このモジュールに含まれるxDscWebServiceリソースを呼び出すConfiguration(Sample_xDscWebService)を実行し、Pullサーバーが構築されます。dscpullサーバーのDeploy_Config.ps1を実行する。この操作により、プリントサーバーをインストールするConfigurationからMOFファイル(ファイル名は対象サーバー名ではなく、対象サーバーを識別するConfigurationIDとなる)を生成し、New-DscCheckSumコマンドレットによりチェックサムファイルを出力し、両ファイルをPullサーバーのMOFファイル配布用フォルダにコピーすることで、設定の配置が完了します。targetサーバーのConfig_LCMforPull.ps1を実行する。Manager)設定用のConfigurationからMOFファイルを生成し、Set-DscLocalConfigurationManagerによりMOFファイルを反映し、targetサーバーのLCMがPushモードからPullモードに変更されます。対象サーバーを識別するためのConfigurationIDも定義します。このスクリプトを実行すると処理の最後で自動的に再起動を実行します。(DSCのモード切替は再起動後に反映されます)再起動後、targetサーバーに印刷サービスがインストールされていることを確認してください。Configuration”を確認してください。LCMのConfigurationに指定した間隔で設定が再反映されていること、あるいは新設定をPullサーバーに取得しにいっていることを確認してください。|Tweet仕様みたいです。-passThru$test::TestMethod($null)結果は「null」ではなく「empty」になってしまいます。LiveSpac.esのコメント欄でも書いたのですが、回避策はリフレクション経由でメソッドを呼ぶしかなさそうです。@($null))このように、Invokeメソッドの第一引数はスタティックメソッドの実行なのでインスタンスを指定しないので$null、第二引数はメソッドに与える引数の配列を指定します。ここでは引数は一つ、その値は$nullなので、@($null)を指定します。このようにすると結果は「null」となり意図した結果が得られます。@mutaguchiBooks書籍版。