.NET Framework と .NET（.NET Core）

Windows 上で動作するオートデスク製品は、Microsoft が開発・提供する .NET Framework を利用しています。2000 年に .NET Framework が発表された際、当時、販売されていた Windows には .NET Framework はまだ搭載さてはいなかったため、別途、入手してインストールする必要がありました。現在では Windows に最初から組み込まれているのはご存じのとおりです。

さて、この .NET Framework、なぜ、重宝され、オートデスク製品の多くが利用するようになったかご存じでしょうか？

.NET Framework

.NET Framework は、おおまかに 2 つの役割、アプリケーションの実行環境 と 開発機能提供 を持っていると考えることが出来ます。

アプリケーションの実行環境

ビジネスの領域で最も使われていると言っても過言ではない Microsoft Windows ですが、Windows 3.1 → Windows 95 → Windows XP → Windows 2000 → Windows Vista などのように、バージョン名に一貫性は見られないものの、その登場以来、バージョンアップが実施されています。

このバージョン名に隠れた形で変化し続けてきたのが、Windows が稼働するハードウェアの向上です。そして、着目すべきは、演算をおこなう頭脳である CPU のビット数です。Windows 初期には 16 ビット CPU だったのが、32 ビット時代を経て、現在は 64 ビット CPU が主流になっています。CPU のビット数が大きくなると、演算スピードの向上だけでなく、使用出来るメモリも増えていきます。メモリを多く使用する図形処理（CAD/BIM/CG）では、CPU の性能向上はとても重要です。

さて、Windows で稼働するアプリケーションは、Windows が採用するビット数に合致する実行ファイル（.exe や .dll）が必要です。言い換えれば、64 ビットアプリケーションは 32 ビット Windows では実行出来ないのです。（32 ビットアプリケーションは、Microsoft が用意した互換モード Wow64 を使って 64 ビット Windows で実行出来ました。）

32 ビット (x86) Windows と 64 ビット (x64) Windows が混在して利用されていた時期、アプリケーションを用意する開発者（オートデスク）にとって両方のビット数に対応するアプリケーションを用意しなければならず、いろいろな意味でとても大変でした。これを解決してくれたのが .NET Framework です。

一般に、Windows アプリケーションの開発には Microsoft Visual Studio という開発ツールを使用します。オートデスクの Windows 向け製品も Visual Studio を使って開発されています。Visual Studio で .NET Framework を利用するアプリケーション用のプログラムコードをコンパイルすると、拡張子 .exe や .dll ファイルを生成します。これら実行ファイルは、内部的には中間言語（IL、Intermediate Language）で構成されています。

中間言語で構成された .exe や .dll ファイルは、実行時に Windows のビット数に合わせて実行時コンパイルが実施され、CPU ビット数に合ったアプリケーションを生成、実行されることになります。

つまり、.NET Framework を使うと、Windows のビット数毎にアプリケーションを用意しなくても良いわけです。（ドライバーなどは個別用意が必要な場合もあります。）

開発機能提供

.NET Framework は、Windows が持つ機能を開発者に開発用ライブラリとして提供する役割も持っています。提供は、.NET Framework クラスライブラリ（開発用ライブラリ）を介しておこなわれます。.NET Framework クラスライブラリは非常に膨大なので詳細は割愛しますが、次のように機能別に分けることができます。

・データ型、属性、数値演算など基本機能
・データベース (ADO.NET) アクセス関連機能
・ Web サービスを含む Web 関連機能
・ XML 処理関連機能
・グラフィックス関連機能
・ Windows フォームなど UI 関連機能　

つまり、.NET Framework を使うと、Windows が持っている機能を開発するアプリケーションのプログラム（ソースコード）に簡単に組み込んで使用出来るわけです。　

.NET Framework を利用して構築されたアプリケーションは、メモリ管理の恩恵も受けることが出来るようになります。アプリケーションのプログラム側で、処理に必要なメモリの確保や解放処理を組み込む手間が省けるだけでなく、メモリの解放が自動化されて（ガベージコレクション）、メモリの解放し忘れ（メモリリーク）のリスクが低下します。このことから、.NET Framework に管理されない古いタイプのアプリケーションを アンマネージコードと呼んでいます。同じように、実行時に .NET Framework を必要とする新しいタイプのアプリケーションを マネージコード と呼んで区別することがあります。

使用されている Windows がほぼ 64 ビットになり、AutoCAD や Revit、Inventor といった主要アプリケーションも、64 ビット版しかリリースされなくなっています。ただ、他の観点からも、オートデスクにとって .NET Framework がとても便利で有用であることはご理解いただけると思います。

オートデスクは、Windows で稼働するアプリケーション本体だけでなく、それら製品のアドイン/プラグインアプリケーション開発用の API にも .NET Framework を導入しています。

参考：オートデスク製品の API が利用するテクノロジ

ところで、.NET Framework にもバージョンが存在しています。オートデスク製品が使用する .NET Framework も、その時々の最新バージョンが採用されています。

参考：AutoCAD と対応する .NET Framework バージョン

このように、とても有用な .NET Framework なのですが、.NET Framework 4.8 が最後のメジャーバージョンとなることがアナウンスされています。

今後が気になります。Microsoft は、.NET Framework をどうするのでしょう？

答えは先に触れたアナウンスのタイトル「.NET Core is the Future of .NET 」にあります。Microsoft は、.NET Framework とは別に .NET Core と呼ばれるオープンソースを用意、.NET Framework の後継に位置付けています。注意したいのは、.NET Framework を即座に廃止してしまうのではなく、メインテナンスが継続される点です。

Microsoft のライフサイクルに関する FAQ - .NET Framework | Microsoft Learn を見る限り、インストール先の Windows のバージョンと同じライフサイクルポリシーが適用されるようなので、.NET Framework 4.8 がプリインストールされている最新の Windows 11 を念頭におくと、当面運用に支障が出ることは考えにくいかと思います。

.NET（旧名 .NET Core）

.NET Framework は Windows 上のアプリケーション開発やメンテナンス、インターネットを使ったコミュニケーション方法（Web サービス）などを劇的に変化させることに成功しました。一方、iOS や Android といったモバイルデバイス向けのオペレーティングシステム（OS）が登場する中、macOS（Mac）や Linux といった Windows 以外の既存の OS でも同様のフレームワークを求める声もありました。

.NET Framework の後継となる .NET Core は、オープンソースであると同時に複数の OS のサポートするクロスプラットフォームを謳っています。もちろん、基本的なアーキテクチャは .NET Framework と同じと考えることが出来ます。なお、.NET Core 3.1 を最後に、現在は、よりシンプルに .NET に名称を改名しています（.NET 5 ～）。

.NET（旧名 .NET Core）は、.NET Framework 同様、初期リリース以来バージョンアップを繰り返しているわけですが、当初、用意されるクラスライブラリは Web 開発を中心にしたものでした。最近では Windows UI 関連（WinForms や WPF など）についても別パッケージによる実装が進んでいます。.NET SDK Beta：フィードバックのお願いで触れた Autodesk Platform Services（APS）用の SDK は、.NET ベースの SDK となります。

さて、Windows 以外の環境でも .NET が持つフレームワークの恩恵を受ける環境が整っている点がわかりました。ただ、Windows に特化した .NET Framework のクラスライブラリと .NET Core のクラスライブラリには、どうしても差が出てしまいます。ソースコードの互換性を考えるアプリケーション開発では、この差は吸収すべき、というのは言うまでもありません。