あなたのアプリケーションは大丈夫？ 〜 .NET Framework 2.0上での1.1アプリケーションの動作：Microsoft Tech・ED 2005 Yokohama

いよいよVisual Studio 2005の年内出荷に伴って、.NET Framework 2.0の正式リリースも近づいてきた。そこで気になるのが、既存の.NET Framework 1.1アプリケーションが、.NET Framework 2.0上でどのように動作するのかという点だ。

[下村恭（ハンズシステム），ITmedia]

　パシフィコ横浜で行われたTech・Ed 2005のセッションでは、現在動作している.NET Framework 1.1対応のアプリケーションをこれからも継続利用するためには、.NET Frameworkの互換性に対する正しい理解と適切な対応が必要なことが説明された。

　.NET Frameworkの互換性を語るには、まず、どのような仕組みをもって.NET Framework上でアプリケーションが実行されるのかを知っておく必要がある。.NET Framework対応アプリケーションは、まずソースコードをアセンブリと呼ばれる中間言語のMSILにコンパイルする必要がある。次にこのアセンブリを、.NET Frameworkの実行環境であるCLRがネイティブコンパイルして機械語に変換した上で実行されることになる。

　ここで問題となるのが、コンパイラのバージョンとCLRのバージョンだ。コンパイラとCLRは.NET Frameworkのバージョン毎に存在し、それぞれ対応付けられることになる。つまり、バージョン1.1のコンパイラでコンパイルされたアセンブリはCLRのバージョン1.1で動作し、2.0でコンパイルされたアセンブリは、LRの2.0で実行されるのが自然な流れとなる。言い換えれば、コンパイル後のアセンブリがコンパイラのバージョンを保持していて、これに対応付けられたCLRで実行されるという形だ。

　しかし、コンパイル時のコンパイラのバージョンに依存していては将来にわたっての実行に支障が出るため、.NET Frameworkはもともと互換性を考慮して作られている。いわゆる下位互換性と呼ばれるものだ。つまり、.NET Framework 2.0上で.NET Framework 1.1のアセンブリを実行できるようになっている。ただし、完全な下位互換性が保障されているわけではないようだ。

　そこで、Side-by-Sideという機能が生きてくる。Side-by-Sideとは、コンパイルされた時点の状況のまま、もしくは開発者がテストしたとおりの状況のままで、アプリケーションを動作させる仕組みのことだ。相関関係がある2つ以上のものに対して、どちらかが変化した場合に元の関係を維持させる機能と言える。

　ただし、一般にSide-by-Sideと呼ぶ機能は、2つの局面で利用されることに注意したい。1つは、あるアプリケーションの実行ファイルとその依存関係にあるライブラリの関係にみるように、開発者が作成した複数のアセンブリ間に適用されるSide-by-Sideだ。これに対して、.NET FrameworkとCLRの関係にみられるように、アプリケーションと実行環境の関係におけるSide-by-Sideがある。つまり、.NET Frameworkの互換性に関係するSide-by-Sideとは、実行環境にバージョン1.1と2.0の両方のCLRをインストールしておき、後述するルールに従って使用するCLRのバージョンを選択できるようにする機能であることを認識しておいていただきたい。

　ここで、バージョン1.1のアセンブリを.NET Framework 2.0のリリース後にどのように実行させるかという点を整理してみよう。.NET Framework 2.0の新機能を利用する場合には、やはりソースコードを書き換えて.NET Framework 2.0に完全対応したアプリケーションにしてしまうというやり方だ。これは、.NET Framework 2.0のすべての機能を利用できる反面、プログラムの書き直しを伴うためコストが高くつく。

　それよりも簡単な方法としては、.NET Framework 2.0の下位互換性を利用して2.0上で動作させる方法と、.NET Framework 2.0はあきらめてインストールせず、1.1のまま動作させる方法がある。どちらもプログラムの書き換えなどの手間が生じないため、コストは最小で済むが、.NET Framework 2.0の下位互換性が完全でない部分を利用している場合には実行できなかったり、他の.NET Framework 2.0アプリケーションを利用できないなどの問題が生じる。

.NET Framework 1.1で作成されたアセンブリを、.NET Framework 2.0リリース後にどのように実行させるかを示すシナリオ。おそらく、最も一般的となる実行方法はSide-by-Sideになる

　となると一番妥当な方法は、やはりSide-by-Sideということになるだろう。ただし、Side-by-Sideを利用するにはいくつか理解しておかなければならない点があることに注意しよう。それは、あるアセンブリを実行するにあたって、どのバージョンのCLRが選択されるのか、という問題だ。

　まず、マネージコードのスタンドアプリケーション、つまり、アプリケーションが.NET Frameworkのアセンブリ単体で構成されている場合を考えよう。この場合、自動的に.NET Framework 2.0のアセンブリはCLR 2.0上で実行され、.NET Framework 1.1のアセンブリはCLR 1.1が選択される。ただし、App.exe.config（「App」は例。実際にはここは実行ファイルのファイル名となる）という設定を記述するためのXMLファイルを実行ファイルと同じフォルダに保存しておくことで、任意にCLRのバージョンを指定することも可能だ。このとき、.NET Framework 2.0のアセンブリはCLR 1.1で実行できないので、configファイルで指定する必要があるのは、.NET Framework 1.1のアセンブリをCLR 2.0で実行したい場合になるだろう。

スタンドアロンのマネージコードの場合、基本的にアセンブリのバージョンと同じCLRが選択される。しかし、configファイルを設定しておくことで、1.1のアセンブリコードをCLR 2.0上で実行させることも可能だ

　次に、アンマネージコードからのアドイン形式でマネージコードを利用した場合、つまり、COMインタフェースなどを利用して.NETアセンブリを呼び出した場合だ。例えば、OfficeやInternet Explorerなどのアドインが.NET Frameworkのアセンブリで構成されていた場合などがこれに当たる。この場合は、.NET Framework 2.0のアセンブリであっても1.1のアセンブリであっても、CLRは2.0が選択される。これにはきちんとした理由がある。もし、2.0のアセンブリをライブラリとして使用している1.1のアセンブリがあった場合、アンマネージコードからの呼び出しでは、2.0のアセンブリと依存しているかどうかが分からない。このため、はじめに1.1のアセンブリが呼び出されたからと言ってCLR 1.1で実行してしまうと、2.0のアセンブリを呼び出してしまった時点で実行できないという事態になる。もし下位互換性がない機能を使用しているのであれば、configファイルで指定して、CLR 1.1で実行するように強制しなければならない。

アンマネージコードからCOMを通してアセンブリを呼び出した場合、CLRのバージョンは基本的に2.0が選択される。このため、下位互換性に問題があるような場合には、configファイルでCLRのバージョンを1.1に強制しなければならない

　稀なケースではあるが、もしconfigファイルを必要とするような場合には、configファイルの設定をアプリケーションのユーザー自身が行う必要があるだろう。というのも、開発者の手を離れた後のアプリケーションであるので、ユーザー環境そのものに関してはユーザーが設定する必要があるからだ。もちろん、開発者からのサポートが受けられる場合でも、これら互換性の問題をユーザー自身が認識する必要があるという点には間違いない。逆に、アプリケーションの開発者やベンダーは、これらの問題を検証し、サポートに対する準備をしておく必要がある。もちろん、下位互換性に問題がなければ、設定の変更をする必要もなく、そのままアプリケーションを実行させることが可能だ。

　このように注意点がいくつかあるが、.NET Framework 2.0の登場後も、一般的にはSide-by-Side技術によって、特に意識することなく.NET Framework 1.1のアプリケーションを利用することができる。