TypeLoadException에 '구현되지 않음'이 표시되지만 구현되었습니다.

테스트 시스템에 매우 이상한 버그가 있습니다. 오류는 다음과 같습니다

System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from assembly 'ActiveViewers (...)' does not have an implementation.

이유를 이해할 수 없습니다. SetShort에서이 DummyItem클래스 및 난 단지 확인이 문제를 버전 배포 / 아니라고 확인하기 위해 이벤트 로그에 쓰기로 버전을 다시 컴파일했습니다. 이상한 점은 호출 코드가 SetShort메소드를 호출하지도 않는다는 것 입니다.

참고 -이 답변이 도움이되지 않으면 시간을내어 사람들이 추가 한 다른 답변을 아래로 스크롤하십시오.

짧은 답변

한 어셈블리의 인터페이스에 메소드를 추가 한 다음 다른 어셈블리의 구현 클래스에 메소드를 추가하지만 새 버전의 인터페이스 어셈블리를 참조하지 않고 구현 어셈블리를 재 구축하는 경우에 발생할 수 있습니다.

이 경우 DummyItem은 다른 어셈블리의 인터페이스를 구현합니다. SetShort 메서드는 최근 인터페이스와 DummyItem에 모두 추가되었지만 DummyItem을 포함하는 어셈블리는 이전 버전의 인터페이스 어셈블리를 참조하여 다시 작성되었습니다. 따라서 SetShort 메소드는 효과적으로 존재하지만 매직 소스가 없으면 인터페이스의 동등한 메소드에 연결됩니다.

긴 대답

이 문제를 재현하려면 다음을 시도하십시오.

1. 클래스 라이브러리 프로젝트를 작성하십시오. InterfaceDef, 하나의 클래스 만 추가하고 빌드하십시오.

   public interface IInterface
   {
       string GetString(string key);
       //short GetShort(string key);
   }

2. 두 번째 클래스 라이브러리 프로젝트를 만듭니다 (구현 (별도의 솔루션 사용), InterfaceDef.dll을 프로젝트 디렉토리에 복사하고 파일 참조로 추가, 하나의 클래스 만 추가, 빌드)

   public class ImplementingClass : IInterface
   {
       #region IInterface Members
       public string GetString(string key)
       {
           return "hello world";
       }
   
       //public short GetShort(string key)
       //{
       //    return 1;
       //}
       #endregion
   }

3. 세 번째 콘솔 프로젝트 인 ClientCode를 작성하고 두 개의 dll을 프로젝트 디렉토리에 복사 한 후 파일 참조를 추가하고 다음 코드를 Main 메소드에 추가하십시오.

    IInterface test = new ImplementingClass();
    string s = test.GetString("dummykey");
    Console.WriteLine(s);
    Console.ReadKey();

4. 코드를 한 번 실행하면 콘솔에 "hello world"라고 표시됩니다

5. 두 개의 dll 프로젝트에서 코드의 주석 처리를 제거하고 다시 빌드하십시오. 두 개의 dll을 ClientCode 프로젝트로 다시 복사 한 후 다시 빌드하고 다시 시도하십시오. ImplementingClass를 인스턴스화하려고 할 때 TypeLoadException이 발생합니다.

asker 자신의 답변에서 이미 언급 한 것 외에도 다음을 주목할 가치가 있습니다. 이것이 발생하는 이유는 클래스가 해당 메소드를 구현하지 않고 인터페이스 메소드와 동일한 서명을 가진 메소드를 가질 수 있기 때문입니다. 다음 코드는이를 보여줍니다.

public interface IFoo
{
    void DoFoo();
}

public class Foo : IFoo
{
    public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
    void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}

Foo foo = new Foo();
foo.DoFoo();               // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo();              // This calls the interface method

내 응용 프로그램에 오류 메시지의 메소드가 사용하는 클래스를 정의하는 다른 어셈블리에 대한 참조가 없을 때 이것을 얻었습니다. PEVerify를 실행하면 "시스템이 지정된 파일을 찾을 수 없습니다."라는 오류가 발생했습니다.

나는 같은 메시지를 보았고 여기에 우리가 발견 한 것이 있습니다 : 우리는 프로젝트에서 타사 dll을 사용합니다. 새로운 릴리스가 나온 후 우리는 새로운 dll 세트를 가리 키도록 프로젝트를 변경하고 성공적으로 컴파일했습니다.

런타임 중에 인터페이스 클래스 중 하나를 설치하려고 할 때 예외가 발생했습니다. 우리는 다른 모든 참조가 최신 상태인지 확인했지만 여전히 운이 없습니다. 오류 메시지에서 메소드의 리턴 유형이 참조되지 않은 새 어셈블리의 완전히 새로운 유형이라는 것을 발견하기 위해 (오브젝트 브라우저 사용) 잠시 시간이 필요했습니다.

어셈블리에 대한 참조를 추가했는데 오류가 사라졌습니다.

• 오류 메시지는 오해의 소지가 있었지만 올바른 방향 (올바른 방법, 잘못된 메시지)을 다소 가리 켰습니다.
• 문제의 방법을 사용하지 않았지만 예외가 발생했습니다.
• 어떤 질문이 나에게로 이어질까요 : 어떤 경우 에이 예외가 발생하면 컴파일러가 왜 그것을 선택하지 않습니까?

다음 시나리오에서이 오류가 발생했습니다.

• 어셈블리 A와 B 모두 System.Web.Mvc 버전 3.0.0.0을 참조했습니다.
• 어셈블리 A는 어셈블리 B를 참조했으며 System.Web.Mvc에서 클래스를 반환하는 메서드를 사용하여 어셈블리 B의 인터페이스를 구현 한 클래스를 가졌습니다.
• 어셈블리 A가 System.Web.Mvc 버전 4.0.0.0으로 업그레이드 됨
• 어셈블리 C는 아래 코드를 실행했습니다 (FertPin.Classes.Contact는 어셈블리 A에 포함됨).

var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));

나를위한 수정은 어셈블리 B의 System.Web.Mvc 참조를 4.0.0.0으로 업그레이드하는 것입니다. 지금 분명해 보인다!

원래 포스터 덕분에!

다른 경우에는이 버전의 서명 된 어셈블리가 잘못된 경우이 오류가 발생할 수 있습니다. 이 원인에 대한 일반적인 증상은 아니지만 여기에있는 시나리오가 있습니다.

• asp.net 프로젝트에는 어셈블리 A와 어셈블리 B가 포함되며 B는 강력하게 이름이 지정됩니다.

• 어셈블리 A는 Activator.CreateInstance를 사용하여 어셈블리 C를로드합니다 (즉, 별도로 빌드 된 C에 대한 참조가 없음)

• C는 현재 존재하는 것보다 이전 버전의 어셈블리 B를 참조하여 빌드되었습니다.

누군가에게 도움이되기를 바랍니다-이것을 알아내는 데 오랜 시간이 걸렸습니다.

이 오류도 발생했으며 x86 어셈블리를 참조하는 모든 CPU 어셈블리를 참조하는 모든 CPU exe에 의해 발생했습니다.

예외는 MyApp.Interfaces (Any CPU)를 파생시키는 MyApp.Implementations (Any CPU)의 클래스에 대한 메소드에 대해 불평했지만 fuslogvw.exe에서 MyApp의 숨겨진 '잘못된 형식으로 프로그램을로드하려고 시도했습니다'예외를 발견했습니다. .CommonTypes (x86) 둘 다 사용됩니다.

나는 이것으로 계속 돌아온다 ... 여기에있는 많은 답변들은 문제가 무엇인지 설명하는 데 큰 도움이된다.

이에 대한 해결책은 프로젝트 공개 디렉토리에서 bin 파일을 수동으로 삭제하는 것입니다. 모든 참조를 정리하고 프로젝트가 최신 DLL을 사용하도록합니다.

IIS를 버리는 경향이 있기 때문에 게시 도구 삭제 기능을 사용하지 않는 것이 좋습니다.

이 오류 메시지에 대한 또 다른 난해한 해결책이 있습니다. 대상 프레임 워크를 .Net 4.0에서 4.6으로 업그레이드했으며, 단위 테스트 프로젝트에서 빌드하려고 할 때 "System.TypeLoadException ... 구현이 없습니다"오류가 발생했습니다. 또한 " 'BuildShadowTask'작업이 예기치 않게 실패했습니다. 여기에 조언이 도움이되지 않았으므로 "BuildShadowTask"를 검색 하고 MSDN에서 게시물을 발견 하여 텍스트 편집기를 사용하여 단위 테스트 프로젝트의 csproj 파일 에서이 줄을 삭제했습니다.

<ItemGroup>
  <Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>

그 후, 두 가지 오류가 사라지고 프로젝트가 구축되었습니다.

Autofac과 많은 동적 어셈블리 로딩을 사용하는 상황 에서이 오류가 발생했습니다.

Autofac 해결 작업을 수행하는 동안 런타임에서 어셈블리 중 하나를로드하지 못했습니다. 오류 메시지에이 (가) 불만을 표시했습니다 Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Windows Server 2012 R2 VM에서 실행할 때 증상이 발생했지만 Windows 10 또는 Windows Server 2016 VM 에서는 발생 하지 않았습니다 .

ImplementationAssemblySystem.Collections.Immutable1.1.37을 참조 IMyInterface<T1,T2>하고 별도 의 인터페이스로 정의 된 인터페이스 구현이 포함 되어 DefinitionAssembly있습니다. DefinitionAssembly참조System.Collections.Immutable 1.1.36.

IMyInterface<T1,T2>"구현되지 않은" 메소드 는 type의 매개 변수 IImmutableDictionary<TKey, TRow>를가집니다.System.Collections.Immutable 집니다.

System.Collections.Immutable프로그램 디렉토리에있는 실제 사본 은 버전 1.1.37입니다. 내 Windows Server 2012 R2 VM에서 GAC에는 System.Collections.Immutable1.1.36 의 복사본이 포함되었습니다. Windows 10 및 Windows Server 2016에서 GAC에는System.Collections.Immutable 1.1.37 되었습니다. GAC에 이전 버전의 DLL이 포함 된 경우에만로드 오류가 발생했습니다.

따라서 어셈블리로드 실패의 근본 원인은에 대한 참조가 일치하지 않았기 때문입니다 System.Collections.Immutable. 인터페이스 정의와 구현은 동일한 모양의 메소드 서명을 가지고 있지만 실제로는 다른 버전의System.Collections.Immutable 했습니다. 따라서 런타임은 구현 클래스가 인터페이스 정의와 일치하는 것으로 간주하지 않았습니다.

내 응용 프로그램 구성 파일에 다음 바인딩 리디렉션을 추가하면 문제가 해결되었습니다.

<dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>

나는 "다이아몬드"모양의 프로젝트 의존성으로 이것을 얻었습니다.

• 프로젝트 A는 프로젝트 B와 프로젝트 D를 사용합니다.
• 프로젝트 B는 프로젝트 D를 사용합니다.

프로젝트 B를 제외하고 프로젝트 A를 다시 컴파일하여 프로젝트 B가 이전 버전의 프로젝트 D dll을 "주입"할 수있었습니다.

ASP.NET 프로젝트에 의존하는 프로젝트 (및 어셈블리 이름)의 이름을 바꿀 때이 문제가 발생했습니다. 웹 프로젝트의 유형은 종속 어셈블리에서 인터페이스를 구현했습니다. 빌드 메뉴에서 클린 솔루션을 실행하더라도 이전 이름의 어셈블리는 bin폴더에 남아 있었고 웹 프로젝트가 실행될 때

var types = AppDomain.CurrentDomain.
   GetAssemblies().
   ToList().
   SelectMany( s => s.GetTypes() /* exception thrown in this call */ )
;

위의 예외는 웹 유형 구현의 인터페이스 메소드가 실제로 구현되지 않았다고 불평하면서 발생했습니다. 웹 프로젝트 bin폴더 에서 어셈블리를 수동으로 삭제하면 문제가 해결되었습니다.

어셈블리 중 하나에 대한 단위 테스트 중 코드 적용을 이전에 활성화했을 때도이 오류가 발생했습니다. 어떤 이유로 Visual Studio는 새로운 버전의 인터페이스를 구현하도록 업데이트했지만이 특정 DLL의 이전 버전을 "버퍼링"했습니다. Code Coverage를 비활성화하면 오류가 제거되었습니다.

이 오류는 Assembly.LoadFrom (String)을 사용하여 어셈블리를로드하고 Assembly.Load (Byte [])를 사용하여 이미로드 된 어셈블리를 참조하는 경우에도 발생할 수 있습니다.

예를 들어 기본 응용 프로그램의 참조 된 어셈블리를 리소스로 포함했지만 앱이 특정 폴더에서 플러그인을로드합니다.

LoadFrom을 사용하는 대신 Load를 사용해야합니다. 다음 코드가 작업을 수행합니다.

private static Assembly LoadAssemblyFromFile( String filePath )
{
    using( Stream stream = File.OpenRead( filePath ) )
    {
        if( !ReferenceEquals( stream, null ) )
        {
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read( assemblyData, 0, assemblyData.Length );
            return Assembly.Load( assemblyData );
        }
    }
    return null;
}

관리되는 C ++과 관련된이 유형의 문제점에 대한 또 다른 설명.

특별한 서명이있는 관리되는 C ++를 사용하여 작성된 어셈블리에 정의 된 인터페이스를 스텁하려고하면 스텁이 작성 될 때 예외가 발생합니다.

이는 Rhino Mocks 및 아마도을 사용하는 모의 프레임 워크에 해당 System.Reflection.Emit됩니다.

public interface class IFoo {
  void F(long bar);
};

public ref class Foo : public IFoo {
public:
  virtual void F(long bar) { ... }
};

인터페이스 정의에는 다음과 같은 서명이 있습니다.

void F(System.Int32 modopt(IsLong) bar)

C ++ 유형 long은 System.Int32(또는 단순히 intC #으로) 매핑됩니다 . Ryenino Mocks 메일 링리스트에 Ayende Rahien이 말한대로modopt 문제 를 일으키는 것은 다소 모호한 것입니다 .

방금 MVC3에서 MVC5로 솔루션을 업그레이드하고 단위 테스트 프로젝트에서 동일한 예외를 받기 시작했습니다.

오래된 파일을 찾는 모든 참조를 확인한 결과, 단위 테스트 프로젝트에서 Mvc에 대한 bindingRedirects를 수행해야한다는 것을 알게되었습니다.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

필자의 경우 WinForms Toolbox를 재설정하는 데 도움이되었습니다.

Form디자이너를 열 때 예외가 발생했습니다 . 그러나 코드 컴파일 및 실행이 가능했으며 코드가 예상대로 작동했습니다. UserControl참조 라이브러리 중 하나에서 인터페이스를 구현하는 로컬에서 예외가 발생했습니다 . 이 라이브러리가 업데이트 된 후 오류가 발생했습니다.

이것은 UserControlWinForms Toolbox에 나열되어 있습니다. 아마도 Visual Studio는 오래된 버전의 라이브러리에 대한 참조를 유지했거나 어딘가에 오래된 버전을 캐싱하고 있었을 것입니다.

이 상황에서 어떻게 회복했는지는 다음과 같습니다.

1. WinForms Toolbox를 마우스 오른쪽 버튼으로 클릭 Reset Toolbox하고 상황에 맞는 메뉴를 클릭하십시오 . 도구 상자에서 사용자 정의 항목이 제거됩니다.
   필자의 경우 도구 상자 항목이 기본 상태로 복원되었습니다. 그러나 도구 상자에 포인터 화살표가 없습니다.
2. Visual Studio를 닫습니다.
   제 경우에는 Visual Studio가 위반 예외로 종료되어 중단되었습니다.
3. Visual Studio를 다시 시작하십시오.
   이제 모든 것이 순조롭게 진행되고 있습니다.

FWIW, 존재하지 않는 참조 된 어셈블리 버전으로 리디렉션 된 구성 파일이있을 때이 문제가 발생했습니다. 승리를위한 퓨전 기록!

프레임 워크의 버전 4.5에있는 어셈블리 'C'에 클래스가 있고 프레임 워크의 버전 4.5.1에있는 어셈블리 'A'에 인터페이스를 구현하고 어셈블리의 기본 클래스로 사용하기 때문에이 오류가 발생했습니다. 'B'는 프레임 워크의 버전 4.5.1에도있었습니다. 어셈블리 'B'를로드하는 중에 시스템에서 예외가 발생했습니다. 또한 세 가지 어셈블리 모두에서 .net 4.5.1을 대상으로하는 nuget 패키지를 설치했습니다. 어떤 이유로, Nuget 참조가 어셈블리 'B'에 표시되지 않았지만 성공적으로 빌드되었습니다.

실제 문제는 어셈블리가 인터페이스를 포함하는 다른 버전의 너겟 패키지를 참조하고 있었고 인터페이스 서명이 버전간에 변경되었다는 것이 밝혀졌습니다.

필자의 경우에는 이전 mylib에 리포지토리 외부의 형제 폴더에 있는 프로젝트를 참조한 적이 v1.0있습니다.

|-- myrepo
|    |-- consoleApp
|    |-- submodules
|         |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)

나중에 나는 그것을 올바르게하고 자식 서브 모듈을 통해 그것을 사용했다 v2.0. consoleApp그러나 하나의 프로젝트 가 제대로 업데이트되지 않았습니다. 여전히 v1.0내 자식 프로젝트 외부의 오래된 프로젝트를 참조하고있었습니다 .

혼란 스럽지만 , *.csproj분명히 잘못 되었지만 가리키는 v1.0Visual Studio IDE는 v2.0프로젝트 의 경로를 보여 주 었습니다 ! 인터페이스와 클래스를 검사하는 F12v2.0 도 버전으로 이동했습니다.

컴파일러가 bin 폴더에 배치 한 어셈블리는 v1.0 버전이므로 두통이 있습니다.

IDE가 나에게 거짓말한다는 사실은 오류를 깨닫기가 더 어려워졌습니다.

해결책 : 프로젝트 참조를 삭제 ConsoleApp하고 읽었습니다.

일반 팁 : 모든 어셈블리를 처음부터 다시 컴파일하고 (가능한 경우 너겟 패키지에는 사용할 수 없음) bin\debug폴더 에서 날짜 시간 스탬프를 확인하십시오 . 오래된 날짜의 어셈블리가 문제입니다.

나는 거의 같은 문제에 직면했다. 이 오류의 원인이 머리를 긁고있었습니다. 나는 모든 방법이 구현되었는지 확인했다.

인터넷 검색 에서이 링크를 다른 사람과 얻었습니다. @Paul McLink 의견을 바탕으로이 두 단계로 문제가 해결되었습니다.

1. Visual Studio를 다시 시작하십시오.
2. 청소, 빌드 (재 구축)

그리고 오류가 사라졌습니다 .

VS 플러그인 재시작

감사합니다 폴 :)

희망이 사람 이이 오류를 겪는 데 도움이되기를 바랍니다 :)

단위 테스트를 실행하는 동안이 문제가 발생했습니다. 응용 프로그램이 제대로 실행되었으며 오류가 없었습니다. 필자의 경우 문제의 원인은 테스트 프로젝트의 빌드를 해제했기 때문입니다. 내 테스트 프로젝트를 빌드하면 문제가 해결되었습니다.

Visual Studio Pro 2008에서 두 프로젝트가 같은 이름의 어셈블리, 하나의 클래스 lib SDF.dll 및 어셈블리 이름이 sdf.exe 인 lib를 참조하는 어셈블리를 만들 때 이것을 보았습니다. 참조 어셈블리의 이름을 변경하면 예외가 사라졌습니다.

이것은 단순히 구현 프로젝트가 오래되었다는 것을 의미합니다. 인터페이스가 포함 된 DLL이 다시 작성되었지만 구현 dll은 오래되었습니다.

여기 에이 오류가 있습니다.

extern방법을 추가 했지만 붙여 넣기에 결함이 있습니다. 는 DllImportAttribute아웃 주석 줄에 넣어되었다.

/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")] 
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);

소스에 속성이 실제로 포함되어 있는지 확인하면 문제가 해결되었습니다.

x86 빌드 유형이 선택되어 bin이 bin 대신 bin \ x86 아래에있게되므로 WCF 서비스에서 이것을 얻었습니다. CPU를 선택하면 재 컴파일 된 DLL이 올바른 위치로 이동했습니다 (처음에 이런 일이 어떻게되는지 자세히 설명하지 않겠습니다).

나는 같은 문제가 있었다. 주 프로그램에서로드 한 어셈블리에 "로컬 복사"가 true로 설정된 일부 참조가 있음을 알았습니다. 이러한 로컬 참조 사본은 동일한 폴더에서 다른 참조의 "로컬 복사"가 false로 설정되어 존재하지 않는 다른 참조를 찾고있었습니다. "실수로"복사 된 참조를 삭제 한 후 기본 프로그램이 올바른 참조 위치를 찾도록 설정되어 오류가 사라졌습니다. 분명히 참조의 로컬 사본은 주 프로그램에 존재하는 원래 사본 대신 로컬 사본이 사용 되었기 때문에 호출 순서를 망쳤습니다.

가져 오기 메시지는 필요한 어셈블리를로드 할 링크가 없기 때문에이 오류가 발생한다는 것입니다.

필자의 경우 TypeBuilder유형을 만드는 데 사용하려고했습니다 . TypeBuilder.CreateType이 예외를 던졌습니다. 결국 인터페이스 구현을 돕는 메소드를 MethodAttributes.Virtual호출 할 때 속성 에 추가해야한다는 것을 깨달았습니다 TypeBuilder.DefineMethod. 이 플래그가 없으면 메소드가 인터페이스를 구현하지 않고 대신 동일한 서명을 가진 새 메소드를 지정하기 때문입니다 (을 지정하지 않아도 MethodAttributes.NewSlot).

부록으로 : 이것은 가짜 어셈블리를 생성하는 데 사용 된 너겟 패키지를 업데이트하는 경우에도 발생할 수 있습니다. 너겟 패키지의 V1.0을 설치하고 가짜 어셈블리 "fakeLibrary.1.0.0.0.Fakes"를 작성한다고 가정하십시오. 다음으로, 새로운 버전의 nuget 패키지 (예 : 인터페이스에 새로운 메소드를 추가 한 v1.1)로 업데이트합니다. Fakes 라이브러리는 여전히 v1.0의 라이브러리를 찾고 있습니다. 가짜 조립품을 제거하고 재생하기 만하면됩니다. 그것이 문제라면, 아마도 문제가 해결 될 것입니다.

최근 Windows 업데이트 후이 오류가 발생했습니다. 인터페이스에서 상속하도록 설정된 서비스 클래스가 있습니다. 인터페이스에는 C #의 새로운 기능인 ValueTuple을 반환하는 서명이 포함되어 있습니다.

내가 추측 할 수있는 것은 Windows 업데이트가 새로운 업데이트를 설치했지만 바인딩 명시 적으로 업데이트하는 등 명시 적으로 참조한다는 것입니다. 결국 결과는 메소드의 서명을 "표준"으로 변경하는 것입니다.