Microsoft Roslyn対CodeDom

新しいMicrosoft Roslynに関するInfoWorldの昨日のプレスリリースから：

この種の「分解された」コンパイラーの最も明白な利点は、.Netアプリケーション内からコンパイル/実行プロセス全体を呼び出すことができることです。Hejlsbergは、いくつかのコードスニペットを文字列としてC＃コンパイラに渡すC＃プログラムを示しました。コンパイラーは、結果のILアセンブリコードをオブジェクトとして返し、それを実行のために共通言語ランタイム（CLR）に渡しました。ほら！Roslynを使用すると、C＃は動的言語の機能を獲得し、実行時にコードを生成して呼び出すことができます。

私はこれを、.NET 4のリリース以来、CSharpCodeProvider.CompileAssemblyFromSource実際にそれを行うASP.Netプロジェクトで実際に使用するようになりました。これにより、ユーザーはコードをテキストボックスに入力して、アセンブリ/名前空間を選択できます。参照し、そのコードからの出力をオンザフライで実行および表示して、Windows Azureでのライブ環境コードテストを行います。

あるCodeDomの/ Roslynのにprecurser一部？ロザリンの特別な利点は何CodeDomですか？

免責事項：私はRoslynチームのマイクロソフトで働いています。

CodeDomはRoslynの前身ですが、関連性はわずかです。基本的に、CodeDomは、デザイナーをサポートするために.NET 1.0で追加されたコード（WinFormsを含む）を生成する、単純で（ある程度）言語にとらわれない方法です。CodeDomは、C＃、VB、およびその他の言語でコードを生成できる統合モデルを提供する試みだったため、サポートする言語の忠実度に欠けています（そのため、CodeDomでswitchステートメントを作成できません）。CSharpCodeProvider.CompileAssemblyFromSourceは、csc.exeの実行に関する単なるラッパーです。

ロズリンは完全に別の動物です。これは、マネージコードを使用して、C＃コンパイラとVBコンパイラの両方を一から書き直したものです。マネージコードでそれらを構築する利点は、ユーザーが.NETアプリケーションからライブラリとして実際のコンパイラを参照できることです（ラッパーは不要）。

コンパイラパイプラインの各コンポーネントを構築する際に、公開APIを公開しました。

• パーサー->構文ツリーAPI
• シンボルテーブル/メタデータのインポート->シンボルAPI
• バインダー->バインディングおよびフロー分析API
• ILエミッタ-> APIを放出

Roslynは洗練されたC＃およびVBソースコードジェネレーターとして使用できますが、CodeDomとの類似性はこれで終わりです。RoslynコンパイラAPIは、コードの解析、セマンティック分析の実行、コードの動的なコンパイルと評価などに使用できます。

コンパイラーに加えて、Roslynチームは、パブリックコンパイラーAPIの上にVisual Studio C＃およびVB IDE機能も再構築しています。したがって、コンパイラAPIは、IntelliSenseやExtract MethodリファクタリングなどのVisual Studio設計時ツールを構築するのに十分なほど豊富です。また、Roslynはコンパイラーの上のレイヤーで、より高レベルの分析またはデータ変換のためのサービスを提供します。たとえば、C＃およびVBのフォーマットルールを使用してコードをフォーマットしたり、ソリューション内の特定のシンボルへのすべての参照を検索したりするためのサービスがあります。

実際、CodeDomに対するRoslynの特別な利点は1つだけではありません。CodeDomが非常に特定のコード生成のニーズを満たす場合、Roslynは、考えられるあらゆる種類のC＃またはVB言語ツールを構築できるフレームワークを提供することにより、言語ツールスペース全体に取り組んでいます。

CodeDomを使用するとコンパイルできますが、コード自体に関する情報（コンパイラエラー以外）を実際に取得することはできません。基本的に、これは「これをコンパイルする」と言うブラックボックスであり、「成功しました」または「失敗しました。ここにいくつかのエラーがあります」と表示されます。

Roslynを使用すると、コードをその場で完全に検査および構築できます。これには、一部のソースコード内のコメントを表示/検査できること、完全な構造に関する詳細情報などが含まれます。Roslynに渡すソースの構文ツリー全体を調べて取得し、詳細な分析を行うことができますまたはそれに変換。

完全で豊富な構文情報があれば、膨大な量の追加制御と柔軟性が得られます。これは、たとえば、C＃コードのブロックをコピーしてVB.NETコードとして貼り付けるサンプルのしくみです。Roslynを使用すると、コンパイルだけでなく、コード自体をきれいに操作することもできます。これにより、ツールがメタ情報（コメントなど）を含む完全な構文を理解し、直接操作できるため、リファクタリングなどの操作を非常に簡単に行うことができるため、多くのツールの生成がはるかに簡単になります。

私が目にする大きな違いの1つ：CodeDomでは、C＃またはVB.NETをコンパイルするたびに、プロセス外で発生します。CSC.exeまたはVBC.exeは、舞台裏の実際のワーカーです。

アーキテクチャ、スケーラビリティ、分離などの点でサービスを構築したい場合（Azureについて言及）、これはあまり良くありません。

Roslynでそれは進行中です。

これが、「サービスとしてのコンパイラ」と呼ばれる理由の1つだと思います。

また、CodeDomは比較的貧弱なAPIであり、多くの機能がありません。また、ほとんどがVisual Studio UIデザイナーの自動コード生成をサポートするように設計されているため、実際には最新ではありません。Roslynはコンパイラーを書いている人たちによって書かれているので、はるかにうまくいくと思います。それが違いを生むことを願っています。

PS：CSC.exeおよびVBC.exeとの1つの注目すべき違い：Roslynは純粋な.NET（およびCCIを使用）のようです。

Roslynを使用すると、プロセス全体をより細かく制御できます。たとえば、文字列を分析し、追加のコードを生成することもできます（分析に基づいてコンパイルプロセス内でオンザフライで）。

CodeDomは「コンパイラーを使用するだけ」ですが、Roslynは「（サブ）パーツへのフルアクセスを持つサービスとしてのコンパイラー」です... Roslynを使用すると、「コンパイラーの内部」にいて、コンパイラーの観点からコードがどのように見えるかを確認できます現在不可能である方法で物事を変更できるようにします。

たとえば、Roslynを使用してC＃を拡張できます。これは非常に便利で、AOP実装の現在の状態よりもはるかに優れています。

Roslynの現在の状態と、Roslynが提供するさまざまなレベルのアクセスおよび制御の概要については、http：//msdn.microsoft.com/en-us/hh500769を参照してください。

更新

マイクロソフトは、追加の機能と多くのAPI変更/追加を備えた新しいCTPを利用できるようにしました。詳細はこちらをご覧ください。