この記事は、 PowerShell Advent Calendar 2015 の 18日目 の記事だ。
私はこれまでずっとネットヒッキーだったので、ネット上でほかの人とのかかわりを持ったことがほとんどなかったが、今回意を決して参加させてもらうことになった。
バリバリの 情シス や プログラマ ではなくても、日常のちょっとした業務で PowerShell を使っている人もいるだろう。
そういったひとびと（主に私）が、組織の中で使えそうだと思ったニッチな話題を書こうと思う。
- PowerShell Tools for Visual Studio を商用利用する環境は、無料でできる
- コンソールウィンドウを極力表示せずにスクリプトを実行
- ネットワーク共有上の DLL を読み込む
PowerShell Tools for Visual Studio を商用利用する環境は、無料でできる
ISE が更新される！ とか、 VSCode で PowerShell がデバッグ可能に！ とか言われているなかで、 あえての PowerShell Tools for Visual Studio 。
PowerShell Tools for Visual Studio 2013 拡張機能 ってあるよね？
PowerShell コードの編集やデバッグを Visual Studio で行えるようにする、拡張機能だ。
変数ウォッチができたり、スクリプトをまたいだ関数のジャンプができるなど、一度使い始めるとこれまでの ISE では物足りなくなってしまうところ。 そういうことにしといてください。
さて、組織に所属している場合、ライセンスの関係で事実上 Visual Studio Community を使うことはできず、有料の Professional のライセンスを買うか、 Express を使うことが検討される。
ところが、 Express の場合、当初から Microsoft 公式な Python Tools for Visual Studio 拡張機能 などの一部をのぞき、拡張機能をインストールすることができない。 もちろん、 PowerShell Tools for Visual Studio もインストールできないのだ。
かといって、 PowerShell Tools for Visual Studio のために \60,000 以上する Professional を買うのは…ねぇ？
Community が使えない組織で無料で使うのはあきらめなくてはならないのか…？ いや違う！
実は、PowerShell Tools for Visual Studio 拡張機能 は Visual Studio Integrated Shell にもインストールすることができるのだ。 → PowerShell Tools for Visual Studio – Now 100% more free!
拡張機能自体は Apache License だ。 Visual Studio のライセンスさえクリアできれば、組織での利用もなんてことはない！
導入は次のステップで。
- Download Windows Management Framework 4.0 などで、 PowerShell v3 以上をインストール (Windows7 の場合のみ)
- Download Microsoft Visual Studio 2013 Shell (Isolated) 再頒布可能パッケージ をインストール
- Download Microsoft Visual Studio 2013 Shell (Integrated) 再頒布可能パッケージ をインストール
- PowerShell Tools for Visual Studio 2013 拡張機能 をインストール
簡単でしょ？
Isolated Shell や Integrated Shell ってなんぞや？というひとは シェル統合および分離シェル あたりの説明を読んで、がんばって理解してほしい。
Microsoft Connect に参加すると、最新の Visual Studio 2015 Integrated and Isolated Shell と PowerShell Tools for Visual Studio 2015 拡張機能 を組み合わせることもできそうだが、当方では試していない。
コンソールウィンドウを極力表示せずにスクリプトを実行
WSH (VBScript, JScript) が、 cscript.exe, wscript.exe と コンソール版と対話版の両方を持っているのに対し、 PowerShell はコンソール版しかない。
このため、 powershell.exe で実行する限り、どうしてもコンソール画面が表示されてしまう。
初回起動時や定期実行などで PowerShell のコンソールウィンドウが表示されると鬱陶しいので、 Win32API を P/Invoke 呼び出し使って、コンソールウィンドウを隠してしまおう。
どうしても PowerShell が起動してから ウィンドウが隠されるまで時間差が生まれてしまうので、 バッチの start コマンド経由で PowerShell ウィンドウを最小化するなどして起動し、コンソール画面を極力デスクトップに表示させないようにしている。
コンソールウィンドウを隠していても、メッセージボックスなどはちゃんと表示されているのがわかる。
ネットワーク共有上の DLL を読み込む
組織内の複数の人間とスクリプトを共有して実行させるため、いわゆるネットワークフォルダにスクリプトを置くようなシチュエーションは少なくないだろう。
ところが、 PowerShell や IronPython などで ネットワーク共有フォルダに置かれている .NET アセンブリ (DLL) を読み込むと、このアセンブリのパスが実際に実行されているプログラム (つまり powershell.exe) の起動パスと異なるため、部分信頼での実行となってしまい、ファイルの読み書きなどの多くのコードが実行できなくなってしまう。
参考: MSDN | イントラネット アプリケーションの完全信頼での実行
この解決方法は大きくわけてふたつある。
一つ目は以前このブログでも取り上げたように (→ スクリプト言語などから、共有フォルダにある .NET アセンブリを完全信頼で読み込む)、スクリプトが含まれるフォルダから、ローカルへシンボリックリンクを張ってしまい、シンボリックリンク経由でアクセスする方法だ。
もうひとつは、アセンブリをいったん byte[] で読み込んでしまい、 [System.Reflection.Assembly]::Load($bin); でロードしてしまう方法。
後者は、アセンブリからの相対パスなどが利用できなくなったり、アセンブリがほかのアセンブリを読み込む場合、それもリフレクションでロードしておく必要があるなど、少々使い勝手が悪いことに注意だ。
貴兄も業務に PowerShell を導入して、生かしてみてはいかがだろうか？