読者です 読者をやめる 読者になる 読者になる

黙々とC#

"In a mad world of VBA, only the mad are sane" 『VBAという名の狂った世界で狂っているというのなら私の気は確かだ』


C#の言語仕様と.NET Frameworkの後方互換生

C#四方山話

f:id:d_ymkw:20170303112002j:plain

C#の言語仕様と、.NET Frameworkの後方互換性について。

C#の言語仕様と.NET Framework非依存の話

ufcpp.net

C#6あたり?から言語仕様の拡張は、コンパイラ(Rosyln)によってC#コードからMSILに変換する際に実現されるようになったおかげで、MSILの実行エンジンである.NET Frameworkのバージョンにほとんど依存しなくなっている。VS2017からIDE上でサポートされるC#7もしかり。

このおかげで、最近では古い.NET Frameworkを対象としたプロジェクトでも、最新のC#の言語仕様でコード書けるようになってるのだけど。

C#6以降から急に始めた人には、どうなっているのか分かりにくいだろうなぁと。

(このRoslynの力技感は半端なくて、後方互換性を保ちながら、ハイスピードで進化し続けているので、スマート&凄い天才的な実装方法なのだけど…、それゆえに分かりづらさも有るかなぁと)

まぁ、そんなことを思ってる。

.NET Frameworkの後方互換性の話

これと似ているといっていいのかわからないけど、.NET Frameworkの後方互換性も一般の人にはわかりにくくなっていて、

MSの技術に明るくない人だとかなり混乱しているのが見て取れる。

実際には、上記記事でも触れられているのだけど*1MSDNの注釈

既定では、アプリケーションは、開発された共通言語ランタイムのバージョンで動作するため、アプリケーションを .NET Framework 4.5 で実行するには構成ファイルを提供する必要がある場合があります。

にあるように、アプリケーション側に何の細工もされていない場合、.NET 3.5のアプリを動かすには.NET Framework3.5がインストールされている必要がある。

のだけど、これには例外があって、.NET 3.5のアプリケーションの構成ファイル(manifestファイル)に『v4.5での動作を許可する』旨を記載すると、.NET 4.5のフレームワークを用いて動かすことが可能になる。*2

※ ちなみに、上の説明では.NET 3.5を例に上げたけど、2.0/3.5/4.xの断絶しているフレームワーク間で有効な一般的な話。

C#/Windowsプログラマなら公知の事実だけど、正直これを一般の人に分かれというのはかなり厳しいものがある。

*1:上記記事では内容を理解できなくてスルーしていると思われる。

*2:ただし、ごくわずかな可能性では有るのだけど、.NET 3.5のフレームワークに依存するトリッキーなコードが混ざっていると実行時例外が発生して落ちる。このため、デフォルトではv4.xのフレームワークでは、.NET3.5のアプリは起動しない。