2008年08月29日(金) 18時46分

どうする？　.NET Framework 1.xアプリケーションの今後（ITmediaエンタープライズ）

　.NET Frameworkの登場から6年。その間、世の中はどんどん進み、ITの世界も大きく変わっている。どうやら、かつて構築した.NET Framework 1.xベースのアプリケーションの今後を考える時期に来ているようだ。

【表：.NET Framework関連のサポート終了時期一覧】

●.NET Frameworkのこれまでの経緯

　2002年4月にVisual Studio .NET 2002と.NET Framework 1.0が登場してからすでに6年以上が経過した。今や.NET FrameworkはWindowsプラットフォームだけでなく、Silverlight 2によってそのほかのプラットフォーム進出までも果たしている。

　Windowsプラットフォームでの開発にはもはや欠くことのできない.NET Framework。だが、1.0の登場当時、特にVisual Basicを開発言語に用いている技術者にとっては、完全なオブジェクト指向へのパラダイムシフトを必要としたせいか、移行にはそれなりの時間がかかったように記憶している。そのためか、.NET Frameworkが本格的に普及したのは、マイナーバージョンアップとなった.NET Framework 1.1になってからだった。

　1つの転換期となったのは、Visual Studioが2005へとバージョンアップし、同時に.NET Frameworkも2.0に進化したときである。Visual Studio 2005に搭載されたアップグレードウィザードが、Visual Basic 6.0のプロジェクトの変換を効率的に行えるようになっていたため、Visual Basic 6.0からの移行は、.NET Framework 1.xを通さず、直接2.0へと行われたものも少なくない。

　2007年11月にはVisualStudio 2008が登場し、.NET Frameworkのバージョンは3.5となった。2008年8月にはVisualStudio 2008および.NET Framework 3.5 サービスパック（SP）1が登場し、現時点での標準的な開発環境はWindows Server 2008＋SQL Server 2008＋.NET Framework 3.5SP1＋Visual Studio 2008SP1となった。

●対応に悩む.NET Framework 1.xベースのアプリケーション

　ここで注目したいのが、.NET Framework 2.0から3.5の間は、ランタイム環境であるCLRのバージョンが変わっていないということだ。開発環境とクラスライブラリが異なるだけで、.NET Framework 2.0アプリケーションと.NET Framework 3.5アプリケーションでは実行環境に違いがないことになる。

　つまり現在では、レガシーに分類されてしまうであろうVisual Basic 6.0以前のアプリケーションと、.NET Framework 1.xベースのアプリケーション、そして.NET Framework 2.0ベースのアプリケーションが存在することになる。

　今、アプリケーション移行（マイグレーション）を考えた場合、必然的に.NET Framework 1.xベースのアプリケーションに注目することになる。なぜなら.NET Framework 2.0ベースのアプリケーションは実質的に最新のアプリケーションと言ってもよいため移行対象にはならないし、Visual Basic 6.0以前のアプリケーションについては移行するしないで悩むレベルでなく、捨てるか、移行するか、新規開発かを「選択しなければならない」時期は過ぎて、すでに判断されているはずだからだ。

　.NET Framework 1.xベースのアプリケーションも今、捨てるか、移行するか、新規開発かの選択を迫られている。とはいえ、.NET以前からの移行に比べ、Visual Studio 2008への移行は楽なので、新規開発という選択肢を用意する必要はないかもしれない。実際は、移行するかしないかについて判断することになるだろう。

　ところで、.NET Framework環境の利点の1つと言われているものに、サイドバイサイド技術というものがあった。これは、アプリケーションのランタイム環境や実行時に必要とするDLLを実行ファイル単位に用意することで、.NET Framework 1.1の実行環境と.NET Framework 2.0の実行環境が同じマシンに同居でき、しかもお互いに干渉しないようにできるということだ。

　それなら、.NET Framework 1.xアプリケーションをわざわざマイグレーションしなくても済みそうなところだ。そのままサイドバイサイドで実行させ続ければよいからだ。

　ここで問題となるのが、マイクロソフト製品のサポートライフサイクルだ。

●.NET Frameworkのサポート ライフサイクル

　マイクロソフトのサポートライフサイクルとは、製品に対するサポート体制を、「メインストリーム サポート フェーズ」、「延長サポート フェーズ」、「オンライン セルフ ヘルプ サポート」の3つに分けて管理することを言う。

　簡単に言うと、メインストリーム サポート フェーズは基本的にすべてのサポートを行うフェーズ、延長サポート フェーズはセキュリティについての最低限のサポートのみを行うフェーズ、オンライン セルフ ヘルプ サポートはあるがままとするフェーズだ。

　製品発売時によって異なるものの、マイクロソフトの製品のサポートライフサイクルのポリシーは明確で、現時点ではメインストリーム サポート フェーズは製品発売から最短5年、延長サポート フェーズはメインストリーム サポート フェーズ終了後の最短5年となっている。

　.NET Framework 1.0はすでにメインストリームサポートフェーズが終わっており、1年を待たずに延長サポートフェーズも終了してしまう。.NET Framework 1.1についても、あと数カ月でメインストリームサポートが終了してしまう状況だ。もちろん.NET Frameworkと同時に発売されたVisual Studioに関しても同じだ。

　こうなると、ほぼ選択肢はないように思える。少なくとも.NET Framework 1.0のアプリケーションについては、セキュリティ面を考慮しつつ使い続けるのであれば、パッチが提供される2009年7月までの間に、.NET Frameworkの新バージョンに移行せざるを得ない。加えて言えば、現在普通に入手できるOSのWindows VistaやWindows Server 2008は、そもそも.NET Framework 1.0のサポートOSではない。そのため、Virtual ServerなどでWindows Server 2003を実行させるなどの方法を取らない限り、場合によっては実行環境そのものを準備できなくなる恐れもある。

　.NET Framework 1.1ベースのアプリケーションは、延長サポートフェーズの終了がまだ先のため、一応の余裕はある。しかし、開発環境であるVisual Studio .NET 2003自体のメインストリームサポートが終了してしまうため、アプリケーションのメンテナンスに関して不安が残る。また、Visual Studio .NET 2003の動作環境として、Windows VistaやWindows Server 2008が使用できないため、開発環境を維持することが困難となる可能性もある。

　つまり、「今のうちにVisual Studio 2008に移行しましょう」ということになってしまう。これは否定できない事実のようである。

●移行のターゲットは？

　では、移行先はどうすればいいだろうか。開発環境となるVisual Studio 2008では、作成するアプリケーションを.NET Framework 2.0、3.0、3.5という3つのターゲットから選択することができる。そこでどのバージョンをターゲットとするかで悩むことになる。

　.NET Framework 3.0や3.5のクラスライブラリで提供される機能を必要としないのであれば、.NET Framework 2.0にしておくことで、しばらくの間は動作に困ることはないだろう。ClickOnceによる簡単な配布や、64ビット環境への対応といった、今となっては限定的なメリットしか享受できないが、.NET Framework 3.5の実行環境は、先に書いたとおり.NET Framework 2.0と同じであるためだ。ただ、サポートライフタイムポリシーを考慮すれば、.NET Framework 3.5を選択するのが無難だろう。

　さらに、先日発表された.NET Framework 3.5 SP1を移行先とすれば、最新のテクノロジーを利用できるだけでなく、改良されたCLRによりアプリケーションの起動を高速化することもできる。また、.NET Framework 2.0がインストールされていないWindows XPに限っての話だが、.NET Framework 3.5 SP1のクライアント機能のみに絞ってサイズを約26Mバイトに縮小した.NET Framework Client Profileを利用できる。これにより、.NET Framework 3.5の最新機能を利用しつつ、メモリ消費を抑えることも可能だ。

●気になるVisual Studio 2008の互換性は？

　移行するとなれば、Visual Studio 2008が備える変換ウィザードを利用する。対象となるフレームワークを変換時に選択できるので、ターゲットとする.NET Frameworkのバージョンを選ぶ。

　だが変換の前に、.NET Frameworkのバージョン間の互換性について調べておくべきだろう。マイクロソフトのサイトにある「.NET Framework の互換性と移行に関する情報」や、「.NET Framework 2.0 での重大な変更点」は参考になる。互換性に関しては、CLRのバージョンの関係から、.NET Framework 1.xから.NET Framework 2.0への変更点を主に見るだけでよい。

　次はVisual Studio 2008自身の互換性だ。ASP.NETについては、Visual Studio 2005で廃止され、SP1で復活したWebアプリケーションプロジェクトも使えるし、DataSetデザイナーでもADO.NET 1.x形式のDataSetをそのまま使える上、2.0形式のDataTableを追加して共存させることも可能だ。Windowsフォームデザイナーについても、2種類のFormを混在できるし、イベントハンドラーの登録も2003形式で可能になっている。つまり、多くの部分で高い互換性を確保できていると言える。

　注意したいのは、Visual Studio 2005から導入されているコードビハインド（パーシャルクラス）だ。例外もあるものの、変換ウィザードではパーシャルへの変換は行ってくれないため、変換後のソースコードはあくまでも1つのファイルのままだ。

　便利な機能もある。Visual Studio Team Systemに用意されているコードの静的分析ツールを使えば、.NET Frameworkデザインガイドラインに従って、マネージコードの潜在的な問題点を洗い出してくれる。

　とはいえ、サードパーティー製のコンポーネントを使用していたり、ネイティブコードで記述されたAPIを使用していたり、シリアル化され永続化されているオブジェクトを利用する場合など、ツールに頼ることでは解決できない問題もある。

　最終的には、これらの状況を見つつ、移行プロジェクトチームで判断するしかないが、継続的にメンテナンスされる「生きた」アプリケーションであれば、WPFやSilverlightに代表される最新のテクノロジーが利用できる、最新環境に移行するのがベストなのは言うまでもないだろう。

【関連記事】
・ → 「.NET」 最新記事一覧
・ → 「Visual Studio」 最新記事一覧
・ 「.NET Framework 3.5」「Visual Studio 2008」のSP1完成
・ Vistaアプリケーション開発に乗り出す企業
・ 「.NET Framework 3.0」はWindows Vista世代標準の開発プラットフォーム

http://headlines.yahoo.co.jp/hl?a=20080829-00000072-zdn_ep-sci