typeloadexception은 '구현 없음'이라고 말하지만 구현됩니다.

Question

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

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

나는 그 이유를 이해할 수 없다. SetShort 거기에 있습니다 DummyItem 클래스, 그리고 나는 배포/버전 문제가 아닌지 확인하기 위해 이벤트 로그에 쓰기로 버전을 다시 컴파일했습니다. 이상한 점은 호출 코드가 SetShort 방법.

Answer 1

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

짧은 대답

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

이 경우 DummyItem은 다른 어셈블리의 인터페이스를 구현합니다. SetShort 방법은 최근 인터페이스와 DummyItem에 추가되었지만 DummyItem을 포함하는 어셈블리는 이전 버전의 인터페이스 어셈블리를 참조하여 재건되었습니다. 따라서 SetShort 방법은 효과적으로 존재하지만 Magic Sauce는 인터페이스의 동등한 방법과 연결하지 않습니다.

긴 대답

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

1. 클래스 라이브러리 프로젝트 만들기 : 인터페이스 프레이프, 한 클래스 만 추가하고 빌드하십시오.

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

2. 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을 프로젝트 디렉토리에 복사하고 파일 참조를 추가 한 후 다음 코드를 기본 메소드에 추가하십시오.

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

4. 코드를 한 번 실행하면 콘솔은 "Hello World"라고 말합니다.

5. 두 DLL 프로젝트의 코드를 무너 뜨리고 재 구축 - 두 DLL을 ClientCode 프로젝트에 다시 복사하여 재 구축하고 다시 실행해보십시오. typeloadexception은 구현 클래스를 인스턴스화하려고 할 때 발생합니다.

Answer 2

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

Answer 3

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

Answer 4

나는 같은 메시지를 발견했고 여기에 우리가 찾은 내용이 있습니다. 우리는 프로젝트에서 타사 DLL을 사용합니다. 새로운 릴리스가 나온 후 우리는 새로운 DLL 세트를 가리키고 성공적으로 편집하기 위해 프로젝트를 변경했습니다.

런타임 동안 인터페이스 클래스 중 하나를 설립하려고 시도했을 때 예외가 발생했습니다. 우리는 다른 모든 참조가 최신 상태인지 확인했지만 여전히 운이 없습니다. 오류 메시지의 메소드의 리턴 유형이 새로운 보유하지 않은 어셈블리의 완전히 새로운 유형이라는 것을 (객체 브라우저 사용) 발견해야 할 시간이 걸렸습니다.

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

• 오류 메시지는 상당히 오도되었지만 올바른 방향 (올바른 방법, 잘못된 메시지)을 가리 켰습니다.
• 문제의 메소드를 사용하지 않았지만 예외는 Ocurred했습니다.
• 질문으로 이어집니다.이 예외가 발생하면 어떤 경우에도 컴파일러가 픽업하지 않습니까?

Answer 5

다음 시나리오 에서이 오류를 받았습니다.

• 두 어셈블리 A와 B 참조 시스템 .web.mvc 버전 3.0.0.0
• 어셈블리에 참조 된 어셈블리 B가 있으며 System.Web.MVC에서 클래스를 반환하는 메소드가있는 어셈블리 B에서 인터페이스를 구현 한 클래스가 있습니다.
• Assembly System.Web.MVC 버전 4.0.0.0으로 업그레이드
• 어셈블리 C는 아래 코드를 실행했습니다 (Fertpin.classes.Contact는 Assembly A에 포함되어 있습니다.

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

저를위한 수정 사항은 System.Web.MVC 참조를 4.0.0.0으로 업그레이드했습니다. 지금 분명해 보인다!

오리지널 포스터 덕분에!

Answer 6

다른 시간 에이 오류를 얻을 수있는 것은 서명 된 어셈블리의 잘못된 버전이있는 경우입니다. 이 원인의 정상적인 증상은 아니지만 여기에 내가 얻은 시나리오가있었습니다.

• ASP.NET 프로젝트에는 어셈블리 A와 어셈블리 B가 포함되어 있습니다.

• 어셈블리 A는 Activator를 사용합니다. 조립품을로드하기 위해 CreateInstance (즉, C에 대한 참조는 없습니다.

• C는 현재 존재하는 것보다 오래된 어셈블리 B를 참조하여 구축되었습니다.

그것이 누군가를 도울 수 있기를 바랍니다. 이것을 알아내는 데 몇 년이 걸렸습니다.

Answer 7

나도이 오류가 있었는데, 그것은 X86 어셈블리를 참조하는 CPU 어셈블리를 참조하는 CPU EXE에 의해 발생했습니다.

예외는 myapp.interfaces (모든 CPU)를 도출 한 MyApp.implementations (모든 CPU)의 클래스에 대한 방법에 대해 불평했지만 fuslogvw.exe에서는 MyApp의 잘못된 형식 'Excection'Except가있는 숨겨진 시도를 발견했습니다. .commontypes (x86)는 둘 다 사용합니다.

Answer 8

나는 이것으로 계속 돌아온다 ... 여기의 많은 답변은 문제가 무엇인지 설명하는 데 큰 도움이되지만 문제를 해결하는 방법은 아닙니다.

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

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

Answer 9

이 오류 메시지에 대한 또 다른 난해한 솔루션이 있습니다. 대상 프레임 워크를 .NET 4.0에서 4.6에서 4.6에서 4.6으로 업그레이드했으며, 단위 테스트 프로젝트에서 "System.typeloadexception ... 구현이 없습니다"오류가 발생했습니다. 또한 "BuildShadowTask '작업이 예기치 않게 실패한 것과 같은 상상되지 않은 방법에 대한 두 번째 오류 메시지를 제공했습니다. 여기서 조언이 도움이되지 않는 것 같지 않아서 "BuildShadowtask"를 검색하고 발견했습니다. MSDN의 게시물 이로 인해 텍스트 편집기를 사용하여 장치 테스트 프로젝트의 CSPROJ 파일에서 이러한 라인을 삭제했습니다.

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

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

Answer 10

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에서 발생합니다.

ImplementationAssembly 참조 System.Collections.Immutable 1.1.37, a IMyInterface<T1,T2> 인터페이스는 별도로 정의되었습니다 DefinitionAssembly. DefinitionAssembly 참조 System.Collections.Immutable 1.1.36.

의 방법 IMyInterface<T1,T2> "구현되지 않았다"는 유형의 매개 변수가 있습니다. IImmutableDictionary<TKey, TRow>, 정의되어 있습니다 System.Collections.Immutable.

실제 사본 System.Collections.Immutable 프로그램 디렉토리에서 발견 된 것은 버전 1.1.37입니다. 내 Windows Server 2012 R2 VM에 GAC에는 사본이 포함되어 있습니다. System.Collections.Immutable 1.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>

Answer 11

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

• 프로젝트 A 사용 프로젝트 B 및 프로젝트 d
• 프로젝트 B는 프로젝트를 사용합니다. d

프로젝트 B가 아닌 프로젝트 B가 아닌 프로젝트 B는 프로젝트 B를 "주입"할 수있게 해주었다.

Answer 12

프로젝트 (및 어셈블리 이름)를 이름 바꾸면 ASP.NET 프로젝트에 의존했습니다. 웹 프로젝트의 유형은 종속 어셈블리에서 인터페이스를 구현했습니다. 빌드 메뉴에서 깨끗한 솔루션을 실행하더라도 이전 이름을 가진 어셈블리는 bin 폴더 및 내 웹 프로젝트가 실행될 때

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

위의 예외는 던져졌으며, 구현 웹 유형의 인터페이스 방법이 실제로 구현되지 않았다고 불평했습니다. 웹 프로젝트에서 어셈블리를 수동으로 삭제합니다 bin 폴더는 문제를 해결했습니다.

Answer 13

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

Answer 14

관리 된 C ++와 관련된 이러한 유형의 문제에 대한 또 다른 설명.

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

이것은 코뿔소 모의와 아마도 사용하는 모든 조롱 프레임 워크에 해당됩니다. 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 (또는 간단히 int C#). 다소 모호합니다 modopt 그것은 문제를 일으키고 있습니다 Rhino Mocks 메일 링리스트에 Ayende Rahien이 언급 한 바와 같이 .

Answer 15

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

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

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

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;
}

Answer 16

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

오래된 파일을 찾는 모든 참조를 확인한 결과, Everyaly는 단위 테스트 프로젝트에서 MVC에 대한 일부 바인딩 레디렉션을해야한다는 것을 발견했습니다.

<?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>

Answer 17

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

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

이것 UserControl Winforms Toolbox에 나열되었습니다. 아마도 Visual Studio는 구식 버전의 라이브러리를 참조하거나 어딘가에 구식 버전을 캐싱하고있었습니다.

이 상황에서 회복 된 방법은 다음과 같습니다.

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

Answer 18

fwiw, 나는 존재하지 않는 버전의 참조 어셈블리로 리디렉션 된 구성 파일이있을 때 이것을 얻었습니다. 승리를위한 퓨전 로그!

Answer 19

프레임 워크의 버전 4.5에있는 어셈블리 'C'에 클래스가 있었고 프레임 워크의 버전 4.5.1에있는 어셈블리 'A'에서 인터페이스를 구현하고 어셈블리의 기본 클래스 역할을했기 때문에이 오류가 발생했습니다. 프레임 워크의 버전 4.5.1에도 'B'. 어셈블리 'B'를로드하려고하면서 시스템은 예외를 던졌습니다. 또한 3 개의 어셈블리 모두에 .NET 4.5.1을 대상으로 한 NUGET 패키지를 설치했습니다. 어떤 이유로 든 Nuget 참조가 조립 'B'에 표시되지 않았지만 성공적으로 구축되었습니다.

실제 문제는 어셈블리가 인터페이스를 포함하는 다른 버전의 NUGET 패키지를 참조하고 있으며 인터페이스 서명이 버전간에 변경되었음을 알 수 있습니다.

Answer 20

제 경우에는 이전에 a mylib Repo 외부의 형제 자매 폴더로 프로젝트 - v1.0.

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

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

혼란스럽게, 비록 *.csproj 분명히 잘못되었고 가리키고있었습니다 v1.0, Visual Studio Ide는 경로를 v2.0 프로젝트! F12는 인터페이스와 클래스를 검사하기 위해 v2.0 버전도.

컴파일러가 빈 폴더에 배치 한 어셈블리는 v1.0 버전, 따라서 두통입니다.

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

해결책: 삭제 된 프로젝트 참조 ConsoleApp 그리고 그들을 읽었습니다.

일반 팁 : 모든 어셈블리를 처음부터 다시 컴파일하고 (가능한 경우, NUGET 패키지에 대해서는 할 수 없음) DateTime 스탬프를 확인하십시오. bin\debug 폴더. 오래된 날짜의 조립품이 당신의 문제입니다.

Answer 21

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

인터넷 검색에서 나는이 링크를 얻었습니다. @paul mclink 댓글을 바탕 으로이 두 단계 가이 문제를 해결했습니다.

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

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

다시 시작 대 플러그인

감사합니다 폴 :)

이것이이 오류를 겪는 사람에게 도움이되기를 바랍니다. :)

Answer 22

또한 UnitTests를 실행하는 동안이 문제를 해결했습니다. 응용 프로그램은 정상적으로 실행되었으며 오류가 없었습니다. 내 경우 문제의 원인은 시험 프로젝트의 구축을 끄는 것이 었습니다. 내 시험 프로젝트의 건물을 다시 알리면 문제가 해결되었습니다.

Answer 23

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

Answer 24

이것은 단순히 구현 프로젝트가 내 경우에 구식이라는 것을 의미합니다. 인터페이스를 포함하는 DLL이 재건되었지만 구현 DLL은 오래되었습니다.

Answer 25

이 오류에 대한 내 생각은 다음과 같습니다.

추가 된 extern 방법이지만 페이스트에 결함이있었습니다. 그만큼 DllImportAttribute 댓글을 달린 라인을 착용했습니다.

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

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

Answer 26

X86 빌드 유형을 선택하여 WCF 서비스에서 이것을 얻었으므로 빈은 빈 대신 빈 x86 아래에 살게됩니다. CPU를 선택하면 재 컴파일 된 DLL이 올바른 위치로 이동했습니다 (처음부터 어떻게 이런 일이 일어 났는지에 대해서는 자세히 설명하지 않습니다).

Answer 27

나는 같은 문제가 있었다. 나는 메인 프로그램에 의해로드 된 내 어셈블리가 "Copy Local"에 대한 참고 문헌을 True로 설정했다는 것을 알아 냈습니다. 이 로컬 참조 사본은 동일한 폴더에서 다른 참조를 찾고 있었는데, 다른 참조의 "사본 로컬"이 거짓으로 설정 되었기 때문에 존재하지 않았습니다. "우연히"복사 된 참조를 삭제 한 후 메인 프로그램이 올바른 참조 위치를 찾도록 설정 되었기 때문에 오류가 사라졌습니다. 분명히 참고 문헌의 현지 사본은 주 프로그램에 존재하는 원래 사본 대신 에이 로컬 카피가 사용 되었기 때문에 호출 순서를 망쳤습니다.

집에 가져가는 메시지는 필요한 어셈블리를로드하기 위해 누락 된 링크로 인해이 오류가 나타납니다.

Answer 28

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

Answer 29

부록 : 가짜 어셈블리를 생성하는 데 사용 된 NUGET 패키지를 업데이트하는 경우에도 발생할 수 있습니다. Nuget 패키지의 V1.0을 설치하고 Fakes Assembly "Fakelibrary.1.0.0.0.fakes"를 만들어냅니다. 다음으로, 최신 버전의 NUGET 패키지 (v1.1)를 인터페이스에 새로운 메소드를 추가했습니다. Fakes Library는 여전히 도서관의 v1.0을 찾고 있습니다. 가짜 어셈블리를 제거하고 재생하십시오. 그것이 문제라면, 이것은 아마도 그것을 고칠 것입니다.

Answer 30

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

내가 추측 할 수있는 것은 Windows 업데이트가 새 제품을 설치했지만 명시 적으로 참조하고 바인딩 리디렉션 업데이트 등을 설치했다는 것입니다. 최종 결과는 메소드의 서명을 "표준"으로 변경했습니다.