Whidbeyへのいざない：Visual Studio Magazine（3/7 ページ）

[Don Kiely，FTPOnline]

デスクトップとWebクライアントで大勝を狙う

　.NETにおけるMicrosoftの最初の目標は、各種のデバイスで稼動するWindows上で動作するアプリケーションをサポートする開発環境の提供である。Whidbeyは各デバイスに対応するアプリケーション開発の簡素化を継続するが、そのサポートの継続において最も重視されるのはWebクライアントとサーバのアプリケーションである。一度の開発で各種のデバイスにデプロイを可能にするインターフェースモデルへの道のりは長いが、それは着実に進んでいるといえる。

　Whidbeyは.NETのWinFormsモデルを取り込むことで、進化した開発モデルとデプロイメントモデルをサポートしている。Whidbeyがリリースされれば、おそらくユーザーはイントラネット対応のWebベースアプリケーションを二度と書くことがなくなるだろう。.NET Frameworkにほかならないクライアントにデプロイするための、リッチなフォームベースのインタフェースをユーザーが手にするとき、何が理由でアプリケーションをホストするために、発育不全のUIと垢抜けないクライアントサイドのスクリプティングを使うのだろうか？　このようなMicrosoftの思惑が確かなものだと確信できるのは、Internet Explorerの新バージョンに対して、もはや行うべき重要な作業がないとアナウンスされる時となろう。

　また、WhidbeyはMicrosoft Officeとの統合も進めている。2003年10月にリリースされたVisual Studio Tools for Office（VSTO）では、Officeを用いた次世代の開発をターゲットにしており、アプリケーションを書くために、WordとExcelに組み込まれた新しい機能を利用可能となっている。これにより、ドキュメントに埋め込まれたVBAのように、COMイベントに対してOfficeから容易に反応することが可能だ。

　Whidbeyは更なるステップとしてこの機能を取りこみ、Officeドキュメントのホスティングに関して、そのアクティブなドキュメントのコンテナを用いる。この名前の選択は不吉であるが（それはVB5のActive Documentが短命に終ったという不幸な記憶を呼び起す）、このコンテナはカスタムアプリケーションの中でOffice機能を使う上で、新しく先進的な方式を提供する。

　ASP.NETのWeb Formsに対するWhidbeyの拡張は、WinFormsに対するほどには急進的ではないが、より効果的なWeb開発をもたらす。データのアクセスと表示を行う新しいコントロールは、ダイナミックなWebサプリケーションの開発において必要な作業を削減する。各マスターページは、各ページ間で機能を共有するための基底ページクラスを使用することで、ASP.NETフォームに対するテンプレート作成のアプローチを簡略化する。

　私の興味が湧かないのは、それぞれの.NET言語同士を優雅にブレンドさせるという、Microsoftが画策する主眼点に対する期待をWhidbeyが満たしていない点だ。.NETの大きな利点と言われているものの1つに、ほとんどのプログミング言語で.NETアプリケーションを記述できることが挙げられる。

　MicrosoftのVB.NETおよびC#、Managed C++、J#を含む全ての.NET言語は、IL（Intermediate Language）にコンパイルするため、言語自体の選択は論理的に本質的ではない。しかし、この論理が現実には機能していない。確かに、全ての.NET言語はILへのコンパイルを行うが、それは同一のILではなく、それぞれの言語が生成するILのパフォーマンスと能力は、言語のコンパイラのオプティマイズに依存するのである。

　Whidbeyは.NET言語を更に分裂させる。例えば、現在のC#は、ブロックの中で生成されたオブジェクトを自動的に破壊するブロックの使用法を持つが、WhidbeyのVisual Basicは同等の機能に関する記法を含まない。もしこれが事実なら、言語同士は、しばらくの間は他の言語には載ることのない、新しい言語機能を多く持つことになる。それらを長々と並べてみると、VB.NETの進歩的で簡素化されたデータソースデザインとMy Tool、およびC#のアノニマスメソッドとenumパターン、C++のPOGO（Profile Guided Optimizations）と簡素化されたマネージドコードの拡張、そしてJ#のブラウザコントロールとenum、そして数値タイプなどが挙げられる。