dynamic가 익명 대상에 부딪혀 발생한 문제에 대한 초보적인 연구 결론

문제는 조 씨의 블로그에서 본 것이다.
dynamic 형식의 보기 모형이 익명 대상을 만났을 때
문제를 본 후 나의 직감적인 첫 번째 반응은 이 문제가 반드시 특정한 조건하에서 반드시 촉발되는 버그와 ASP라고 느꼈다.NET MVC는 괜찮아요.그러나 당시에는 비교적 게으르기 때문에 몇 차례 시험을 한 후에 잠시 내버려두었다.나중에 스웨키.우 학생은 문제에 대한 연구를 추진했고 다음과 같이 지적했다.
"dynamic로 어떤 프로그램에서 동적 형식을 집중적으로 정의한 후에 익명 형식의 대상을 사용하여 값을 부여한 다음에 다른 프로그램 집합에서 이 동적 형식의 익명 대상의 속성에 접근하면 이 이상이 발생합니다. 같은 프로그램의 집중 접근에서 문제가 발생하지 않습니다."
오늘 드디어 이 문제를 잘 연구할 시간이 생겼습니다. 우선 저는 스웨키에 따라.우 학생의 단서는 간단한 실험을 해서 이 문제를 재현했다.그리고 추가 조건을 끊임없이 제거하여 가장 간단하게 문제를 재현할 수 있는 코드를 얻었다(사실 익명 형식과 상관없다).

namespace BugTest2

{

  public static class Test

  {



    private class Value

    {

      public string Title = "Hello World";

    }



    public static dynamic GetValue()

    {

      return new Value();

    }



  }





  public class Program

  {

    static void Main( string[] args )

    {



      var d = Test.GetValue();

      Console.WriteLine( d.Title );





      Console.ReadLine();



    }

  }

}

문제는 여기서 명백하다. 다이내믹을 통해 현재 상하문에서 볼 수 없는 구성원을 방문할 때 이 이상을 일으킬 수 있다.
그렇다면 왜 익명 유형에 문제가 생길까?C#의 컴파일러가 항상 익명 형식을 인터넷으로 컴파일하기 때문이다.이로써 익명 형식이 크로스 프로그램 집합이dynamic를 통해 접근할 때 반드시 이 문제가 발생할 것이다.
 
어떻게 해결합니까?
사실 문제는 C#의 컴파일러가 항상 익명 형식을 인터넷 형식으로 컴파일한다는 데 있다.C#이public의 익명 형식을 컴파일할 수 있는 방법을 당분간 찾지 못했습니다.그래서 이 문제는 현재로서는 조씨의 그 보조적인 방법만 사용할 수 있지만 To Public으로 이름을 바꾸는 것이 더 적절하다고 제안합니다. 왜냐하면 그 방법으로 문제를 해결하는 본질은 Public이라는 유형에 있기 때문입니다.
 
왜 초보적인 연구 결론이라고 합니까?
비록 나는 C#이dynamic 대상에게 발생한 그 코드들을 반나절 동안 연구했지만 여전히 이상 촉발의 근본적인 위치를 찾지 못했기 때문에 현재의 결론은 시험과 관찰에 세워져 있고 코드를 실현하지 못했다는 증거로 삼지 못했다...
원망이야...
 
응응, 시스템.CSharp.RuntimeBuilder.CSharpGetMemberBinder라는 유형이 관건이 될 것 같은데...