12

言語に依存しない（少なくとも特定の範囲内で）ソースコード生成のSystem.CodeDom名前空間を調べていますが、の使用を思いとどまらせる情報がいくつか見つかりましたCodeDom。

この初期のブログ投稿で説明されている省略の一部は、これまでに修正されていると思います。ステートメントCodeDomを作成する方法を提供していないように見えるswitchという事実は、パフォーマンスの低下を可能にしますか？-生成されたタイプのパブリックインターフェイスを醜くしないでの回避策。同じことが自動C＃プロパティとコレクション初期化子にも当てはまります。

ただし、ファイナライザーを作成できない、拡張メソッドを宣言できない、ジェネリック参照型の制約が直接サポートされていないなど、他の省略は実際には回避できません。

CodeSnippetTypeMember言語に依存しないため、他の方法でリテラルソースコードスニペットを使用または挿入することで提案されたソリューションは満足のいくものではないことに注意してください。これにより、リテラルコードスニペットCodeDomではなく使用のポイント全体が削除さString.Formatれます。

最後に、このSOの質問では、「CodeDomは失敗であり、式ツリー（または「ステートメント」ツリー）が前進する」とさえ示唆されていますが、式ツリーから実際にソースコードを取得する方法については説明がありません（クラスは式ツリーで宣言できないという制限のほかに。

CodeDomはまだソースコードを生成するための選択の方法ですか、それとも現在のBCLは、私が思いもよらなかった名前のあいまいな置換を提供しますか？

4

2 に答える 2

4

CodeDom は今日の BCL で依然として最良のソリューションだと思いますが、 Roslyn プロジェクトはかなり進んでおり、すでにいくつかの CTP を開始しています。目標は、コンパイラをサービスとして利用できるようにすることであり、単純な API を使用してコード生成とコード検査のシナリオを可能にします。

プロジェクトでプレリリース ビットを使用できる場合は、Roslyn CTPを参照してください。これは、関連する (時代遅れではありますが、まだいくつかの良い情報です) StackOverflow の質問です: Microsoft Roslyn vs. CodeDom。そして最後に、コード生成に Roslyn を使用する方法について説明した記事: Roslyn CTP を使用した .NET でのコード生成

于 2013-02-10T11:13:14.107 に答える
3

いいえ。CodeDom は、実行するコードを生成するのに役立ちます。テキストも生成する機能は、コンパイラがテキストを必要とするために必要な、偶然の副産物にすぎません。テキストが本当に気になるなら、CodeDom を嫌う理由はたくさんありますが、フレームワークには何の助けにもなりません。

他のソリューションも同様に、実行可能コードの生成に重点を置いています。Reflection.Emit は .NET のユニバーサル言語である IL を生成しますが、適切な逆コンパイラ (ILSpy、Reflector など) が役立つことは確かですが、単純な逆コンパイル方法は提供しません。Linq.Expressions は純粋な実行可能コードであり、通常、完全なプログラムを生成するのには役立ちません。Roslyn は、テキストを既に持っていることに大きく偏っています。

おそらく最善の方法は、テキストを特定の言語にするという要件を廃止することです。すべての .NET コンパイラは同じ種類の出力を持ち、すべて IL にコンパイルされます。これにより、選択肢を1 つの言語に限定することが実行可能なアプローチになります。それ以外の場合、それが合理的な制限であるかどうかは、あなたの質問からは明らかではありません。CodeDom の制限を解決しようとしたプロジェクトは思い浮かびません。codeplex.com で入手できる、CodeDom をターゲットとする種類のプロジェクトは、代わりに、CodeDom を使用するコードに必要な冗長性の苦痛を最小限に抑えようとします。

于 2013-02-10T11:54:26.267 に答える