プロパティ/メソッドのインライン化とリフレクションへの影響

Question

My answer SOの質問の1つは、JITコンパイラでプロパティをインライン展開するとリフレクションが機能しなくなると主張するValentin Kuzubによってコメントされました。次のように

場合は、次のとおり

class Foo 
{ 
    public string Bar { get; set; } 

    public void Fuzz<T>(Expression<Func<T>> lambda) 
    { 
    } 
} 

Fuzz(x => x.Bar); 

Fuzz関数は、ラムダ式を受け取り、プロパティを見つけるためにリフレクションを使用します。拡張子がHtmlHelperのMVCではよくあることです。

私は反射が、それがインライン化され、typeof(Foo).GetProperty("Bar")がまだ有効PropertyInfoを返しますBarへの呼び出しであるようBarプロパティは、インライン化されます場合でも、作業を停止することはないと思います。

これを確認してください、または方法のインライン展開が間違っていますか？

Answer 1

JITコンパイラは実行時に動作し、アセンブリに格納されているメタデータ情報を書き換えることはできません。リフレクションはこのメタデータにアクセスするためにアセンブリを読み取ります。したがって、JITコンパイラからリフレクションへの影響はありません。

編集： 実際には、C＃コンパイラ自体がコンパイル時にいくつかの情報を "インライン"するときに、いくつかの場所があります。たとえば、定数、列挙型、およびデフォルトの引数は "インライン"なので、リフレクション中にアクセスすることはできません。しかし、あなたの特定の事件には必ずしも関連しません。

Answer 2

私は個人的に@Sergeyに同意：

はインライン化がJITコンパイラ側で発生したが、メタデータが前に生成され、それがどのような方法で反射にinpactべきではないと考えます。私はそれについて考えるとき、1

Answer 3

うんもっと私はあなたが

public Count 
{ 
get {return m_Count;} 
set { m_Count=value; 
     GetCurrentPropertyNameUsingReflectionAndNotifyItChanged();} 
} 

のように使用する反射ベースの方法を使用していた場合の唯一の方法のインライン化プロパティが正しい仕事のようになりINotifyPropertyChangedのインターフェースを失敗する可能性が推測それのような方法で、良い質問で

メタデータがアセンブリ内に存在し、プロパティ名が実際にそこから取得されることをお勧めします。

私たちはどちらも考えました。

Answer 4

表現木は、表現そのものではなく、表現（抽象構文木）の表現であるため、とにかくインラインにすることはできません。

デリゲートは、たとえインラインであっても、そのプロパティで呼び出されるメソッドとターゲットに関するデータを保持します。