稿
目
次
稿
目
次
Linux でも動きます！
.net framework と言えば Microsoft が一生懸命旗を振っている、Java によく似たプログラミング環境とそれによって作成されたプログラムの実行環境だというイメージを持たれるのではないでしょうか。確かにそれは間違いではありませんが、Java に比べて二つの点で大きなアドバンテージがあります。
まず一つ目は、Java がひとつの言語だけを対象とした枠組みであるのに対し、.net framework は C++/CLI、C#、VB など複数の言語に対して平等な枠組みを提供します。これによって、開発者は状況に応じた適切な言語、あるいは自分の好みにあった言語を選択しつつも、他の言語で開発されたコンポーネントを手軽に使えるようになります。
二つ目は、プログラムの実行環境がECMA（ヨーロッパ電子計算機工業会）によって ECMA-335 (共通 言語基盤;CLI) として標準化されている点であり、これを追認する形で ISO や JIS としても標準化されている点です。従って、.net framework は CLI に準拠したプログラム実行環境の実装を核とした、プログラミングおよびソフトウェア実行に関する枠組み（framework）の一つであると言えます。従って、他の OS による CLI の実装も存在し、CLI にさえ対応していれば Windows で開発したソフトを他の OS で実行することも可能です。実際、Linux では mono や dotgnu といった CLI の実装系が存在します。
Java のおさらい
Java は Sun が開発した「プラットフォームに依存しない」ことが売りのプログラミング言語ですが、その仕組みは.のようになっています。
最大の特徴は、Java をコンパイルすると特殊なバイナリ（上図の「Java バイナリ」）が生成され、このバイナリは Java バーチャルマシン（Java Runtime Environment とか JRE と言われる）上で動くという点です。そして、Java バーチャルマシンは Solaris はもちろん、Windows や Linux にもインストールすることができます。ですのでプログラマやユーザーは Java バーチャルマシンがインストールされている環境であれば、OS を気にせず Java で作られたプログラムを動作させることができる仕組みです。
CLI
一見便利に見える Java ですが、プログラムを開発する側から見れば不十分な点もあります。それは使える言語が Java しかないという点で、さまざまな言語を適材適所で使いたいといった要望を満たすことができないことです。この点に関しては、厳密に言えば Java バーチャルマシン上で動く言語として JRuby、Groovy、Jython などが存在するので正しくはありません。しかし、Java バーチャルマシンの仕様は標準化されておらず、極論を言ってしまえば Sun の一声で仕様が変わってしまい、それらの言語は動かなくなってしまう危険性があります（これはサードパーティ製の Java バーチャルマシンでも同じことが言えます）。
これに対して CLI は、OS に依存しないという Java の利点を生かしつつ、さらに複数の言語を使えるというメリットがあり（※発想は似ていますが、CLI は Java を拡張したものではありません）、その仕組みは.のようになっています。
CLI では、プログラムがコンパイルされたときにどのようなバイナリが作られるべきかを共通化しました。この共通化された取り決めに従ったバイナリであれば、これらは CLI の実行環境（CLI 実装）で動作させることができます（特に、.net framework に含まれる実行環境を Common Language Rumtime と呼び、CLR と略します）。
そして、CLI の共通化された取り決めは ECMA をはじめとする各国の工業団体が定める標準として採用されていますので、その気になればだれでもコンパイラや CLI 実装を作ることができます。実際、先述したとおり mono のような Linux 上で動くコンパイラと CLI 実装も存在し、Windows 上の .NET に対応した、任意の言語で書かれたプログラムが mono 上で動いたり、またその逆も可能です。このように仕様が標準化されているため、Microsoft 以外の個人や団体でも、言語やCLI実装を安心して作ることができ、多様な開発環境の安定供給が期待できます。
実際に試す前に、もう少し特徴的な点を述べておきます。現在 Microsoft の .NET Framework は 1.0、1.1、2.0、3.0 の3バージョンが存在します。しかし、CLI の取り決め自体は変更されていないので、2.0 でコンパイルしたプログラムを 1.0 で動かすこともできます。これらのバージョンの違いは基本的にクラスライブラリの違いです。ですので、動かせると言ってもさすがに 2.0 でしかサポートされていないクラスを含んだプログラムを 1.0 や 1.1 で動作させることはできません.。（詳細については詳しく調べていませんが、標準化された CLI に厳密に準拠しているのは 2.0 からだと思います。実際、Microsoft は開発中の 3.5 に関しても 2.0 で動くと述べており、それは核が 2.0 から変わっていないからだと述べています。）
また、.NET framework の 2.0 からは C++ も純粋な CLI を作ることができるようになりました。この C++ は C++/CLI と呼ばれ、やはり ECMA を代表する標準として採用されています。C++/CLI はメモリのガーベジコレクタが標準でサポートされるなど、従来の C++ とは思想的に異なる部分もあるため、従来の C++ とは異なった部分も含まれますが、だいたいのところは C++ と同じです。そして、上述したような CLI の特徴により、C++/CLI プログラムも .NET Framework の 1.0 や 1.1、mono の各バージョンで動かすことができます。
膨大な情報源
さて、ソフトウェアを開発する際に CLI を選択すると、思わぬ副産物の恩恵を受けることができます。それは、CLI プログラミングに関する膨大な情報です。
CLI に対応した言語での開発は、根本原理がみな同じですから、特に Visual Studio に含まれるクラスライブラリに限って言えば、文法の違いこそあれど、VB も C# も C++/CLI も、何かやりたいことがあればその実現手法（クラスライブラリの使い方）はみな同じです。
従って、VB 用に書かれた解説も、C# 用に書かれた解説も、C++/CLI 用に書かれた解説も、すべての解説が CLI プログラミングを行う上で有益な情報源となりうるのです。
