それが行われなかった場合、その理由は1つだけです。それを行うための努力は、考えられる利益よりも高いということです。
コストが高すぎるため、Microsoftは絶対にそれを行いません。.netコードはアセンブリに存在し、誰もそれを変更しません。そして、はい、アセンブリはクラスごとのインクリメンタルコンパイルを防ぎます。アセンブリの使用をやめる人は誰もいません。
そして、これが私の答えです。なぜ誰もそれを必要としないのです。単一のプロジェクトを構成するクラスを複数のアセンブリに分散し、それらを1つずつコンパイルできます。これは実際にはインクリメンタルコンパイルですが、クラスごとのインクリメンタルコンパイルほどきめ細かくはありません。また、アーキテクチャが適切に設計されている場合は、アセンブリレベルのインクリメンタルコンパイルで十分です。
編集：さて、私はそれをインクリメンタルにすることが可能であることを確認するためにMono C＃コンパイラをダウンロードしました。それほど難しいことではないと思います。基本的に、次の手順を実行します。1）ファイルを解析します。2）コンパイルします。3）アセンブリを作成します。型がコンパイルされた後、どこかにフックして、ある種の中間ファイルに保存することができます。次に、変更されたものだけを再コンパイルします。したがって、それは可能ですが、Monoチームにとって優先度の高い問題ではないようです。
編集2：人々がMono C＃コンパイラのインクリメンタルコンパイルについて議論しているこの興味深いスレッドを見つけました。それはかなり古いですが、重要な説明はまだ有効かもしれません：
字句解析と解析は通常非常に高速であり、解析されるコードのサイズにのみ依存します。参照されるアセンブリをロードし、シンボルとタイプを解決するために巨大なメタデータを選別することが実際にはコンパイラの要であるため、セマンティック分析は通常最も時間のかかるステップです。また、新しい「コンパイルされた」コードがこのメタデータ/ASTに「追加」されます。時間の経過とともにシンボルを解決することの複雑さ。コードの放出は最初にメモリで行われるため、高速です。ディスクへの保存は遅いですが、発行されたコードサイズによって異なります。
インクリメンタルコンパイルの場合、メタデータをキャッシュすると、通常はコンパイルごとにほとんど変更されないため、すべてが非常に高速になります。ただし、gmcsは、メタデータ/ ASTの一部のみを無効にする必要があります。これは、そのために構築されたものではありません。
編集3：C＃コンパイラ/incrementalにはv1.0とv1.1のオプションがありましたが、削除されました：
C＃コンパイラの1.0および1.1バージョンにある/incrementalフラグは廃止されたと見なされるようになりました。
編集4 ： Miguel de Icazaは、Monoコンパイラがインクリメンタルにならない理由を明確に答えています（1、2 ）。
GMCSが編集と続行のシナリオで機能するように設計されていない場所は他にもたくさんあります。
誰かがこれを彼らの論文の主題にしたいのなら、それは私にとっては問題ありませんが、あまりにも多くの分野で変更の量が多すぎます。わざわざ列挙したくありません。
私が物事をリストしなかった理由は、それらがコンパイラーのいたるところにあるからです。それらを試してみるとすぐにそれらに遭遇すると確信しています;-)
それで彼はそれが一人の男の論文よりも大きな仕事であると考えています。そして、Monoにははるかに優れた実際のタスクがあります。