Windows SDK と PowerShell - NyaRuRuが地球にいたころ

コマンドプロンプトから PowerShell へ

Visual Studio や Windows SDK をインストールすると，開発ツールにパスを通すためのバッチファイルもスタートメニューに登録されます．このバッチファイルを実行することで，インクルードファイルやライブラリファイルへのディレクトリが設定され，コマンドラインのコンパイラを直接起動したり，msbuild.exe を使用してソリューション全体のビルドを行ったりするための環境が整います．意外とこのコマンドラインのビルド環境というのは重要で，例えばドライバのテストを行ったりするのに何かと活躍します．
従って，私が普段の生活をコマンドプロンプトから PowerShell に移すためには，さしあたりこのビルド環境の移行をクリアしなければなりません．
ビルド環境の設定が，本質的には環境変数のセットであると考えれば，バッチファイル実行後の環境変数一覧を取得し，それを PowerShell 環境に取り込むことで何とかなりそうです．

Invoke-CmdScript.ps1

少し調べてみたところ，まさに同じことを行っている記事を見つけました．

Nothing solves everything – PowerShell and other technologies

この記事で紹介されているスクリプト Invoke-CmdScript.ps1 は，cmd.exe 向けに書かれたバッチファイルを受け取ってそれを実行し，実行後の環境変数をテンポラリファイルを経由して取得・設定するというものです．
私の場合は当面 Windows SDK のビルド環境が設定できれば十分なので，Invoke-CmdScript.ps1 を参考に，$HOME:Documents\WindowsPowerShell\profile.ps1 に次のような関数を定義してみました．

function envwinsdk
{
    param([string] $parameters)  

    $script = "C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\SetEnv.Cmd"
    $tempFile = [IO.Path]::GetTempFileName()  

    cmd /E:ON /V:ON /c " `"$script`" $parameters && set > `"$tempFile`" " 

    ## Go through the environment variables in the temp file.  
    ## For each of them, set the variable in our local environment.  
    Get-Content $tempFile | Foreach-Object {   
        if($_ -match "^(.*?)=(.*)$")  
        { 
            Set-Content "env:\$($matches[1])" $matches[2]  
        } 
    }  

    Remove-Item $tempFile
}

例えば，Windows Vista のリリースビルド環境を設定するには，次のように実行します．

envwinsdk /Release /vista

バグに注意

ちなみに，上のスクリプトにはバグがあって，環境変数に改行が含まれている場合に正しく動作しません．例えば，環境変数 ZZZ が "dummy<LF>Path=C:\Malicious" という内容だった場合，上のスクリプトは環境変数 Path を誤った内容で上書きしてしまいます．

環境変数への改行文字のセット

安全を期したい方は，環境変数を取得するプログラムや powershell.exe のワンライナーで改良してみてください．

今後の課題

これでとりあえず csc.exe test.cs といったビルド作業を，PowerShell から行うことができるようになりましたが，全てが .NET オブジェクトという PowerShell が真価を発揮するにはほど遠い状態です．
例えば，テキストストリームや CodeDOM を受け取って，コンパイル後の System.Reflection.Assembly オブジェクトを返す Cmdlet があれば，ストレージ上の実行ファイルを意識することなく，すぐにビルドしたアセンブリを使用できます．
こういった細かいスクリプトが Windows SDK に付属してくれればもっと楽しくなるのでしょうが，TechEd 2007 のニュースなどを読んでいると、むしろ開発系の人々よりもサーバ系の人々の方が PowerShell には力を入れているようで，なんだかうらやましく思います．その意味でも，PowerShell をベースにした最初のサーバ OS である Windows Server 2008 は，案外と開発環境に使ってもおもしろいものなのかもしれません．

ベータ3で，PowerShellが突然復活

その一方でMicrosoftは，コマンド・プロンプトの重要性を高めようとする動きに逆らうかのように，最近リリースしたLonghorn Serverベータ3で爆弾を投下した。何とMicrosoftは前言を撤回して，Longhorn Serverベータ3にPowerShellを搭載したのだ。

悲しいことにPowerShellのLonghornへの追加は，例えばPowerShell版の「servermanagercmd.exe」を実現するには，少し遅すぎた。それでもMicrosoftはPowerShellマニアのために，PowerShell版の「servermanagercmd.exe」や，それ以外の管理関連の未完成部分について，これから埋め合わせをしていく予定だ。同社はいかなる詳細も明らかにしていないが，現在サーバー・コアでPowerShellを動作させるのに必要な.NETランタイムのサブセットを作る作業に取り組んでいる。完成するのは，時間の問題だ。

業務用アプリケーション基盤として見た場合の「Windows Server 2008」の利点は何か−−。米Microsoftが2007年内に出荷する予定のWindows Server 2008は，トランザクション機能やファイル・システムなどを強化しており，業務用アプリケーションをより効率的に開発できるという。現在開催中の「TechEd 2007」におけるセッション内容を元に，開発者にとってのWindows Server 2008の利点を確認しよう。