TypeLoadException nói 'không triển khai', nhưng nó được triển khai

Tôi đã có một lỗi rất kỳ lạ trên máy thử nghiệm của chúng tôi. Lỗi là:

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

Tôi không thể hiểu tại sao. SetShortcó trong DummyItemlớp và tôi thậm chí đã biên dịch lại một phiên bản ghi vào nhật ký sự kiện chỉ để đảm bảo rằng đó không phải là vấn đề triển khai / phiên bản. Điều kỳ lạ là mã gọi thậm chí không gọi SetShortphương thức.

LƯU Ý - Nếu câu trả lời này không giúp ích cho bạn, vui lòng dành thời gian để cuộn qua các câu trả lời khác mà mọi người đã thêm vào.

Câu trả lời ngắn

Điều này có thể xảy ra nếu bạn thêm một phương thức vào một giao diện trong một cụm, sau đó đến một lớp triển khai trong một cụm khác, nhưng bạn xây dựng lại cụm thực hiện mà không cần tham khảo phiên bản mới của cụm giao diện.

Trong trường hợp này, DummyItem thực hiện một giao diện từ một hội đồng khác. Phương thức SetShort gần đây đã được thêm vào cả giao diện và DummyItem - nhưng tập hợp chứa DummyItem đã được xây dựng lại tham chiếu phiên bản trước của cụm giao diện. Vì vậy, phương thức SetShort có hiệu quả ở đó, nhưng không có nước sốt ma thuật liên kết nó với phương thức tương đương trong giao diện.

Câu trả lời dài

Nếu bạn muốn thử sao chép này, hãy thử như sau:

1. Tạo một dự án thư viện lớp: InterfaceDef, chỉ thêm một lớp và xây dựng:

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

2. Tạo dự án thư viện lớp thứ hai: Triển khai (với giải pháp riêng), sao chép InterfaceDef.dll vào thư mục dự án và thêm dưới dạng tham chiếu tệp, chỉ thêm một lớp và xây dựng:

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

3. Tạo dự án giao diện điều khiển thứ ba: ClientCode, sao chép hai dll vào thư mục dự án, thêm tham chiếu tệp và thêm mã sau vào phương thức chính:

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

4. Chạy mã một lần, giao diện điều khiển nói "xin chào thế giới"

5. Bỏ ghi chú mã trong hai dự án dll và xây dựng lại - sao chép hai dll trở lại dự án ClientCode, xây dựng lại và thử chạy lại. TypeLoadException xảy ra khi cố gắng khởi tạo lớp triển khai.

Ngoài những gì câu trả lời của người hỏi đã nêu, có thể đáng lưu ý những điều sau đây. Lý do điều này xảy ra là vì một lớp có thể có một phương thức có cùng chữ ký với một phương thức giao diện mà không thực hiện phương thức đó. Đoạn mã sau minh họa rằng:

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

Tôi đã nhận được điều này khi ứng dụng của tôi không có tham chiếu đến một hội đồng khác xác định một lớp mà phương thức trong thông báo lỗi được sử dụng. Chạy PEVerify đã đưa ra lỗi hữu ích hơn: "Hệ thống không thể tìm thấy tệp được chỉ định."

Tôi đã bắt gặp cùng một thông điệp và đây là những gì chúng tôi đã tìm thấy: Chúng tôi sử dụng các dll của bên thứ ba trong dự án của chúng tôi. Sau khi bản phát hành mới được phát hành, chúng tôi đã thay đổi dự án của mình để chỉ ra tập hợp các dll mới và được biên dịch thành công.

Trường hợp ngoại lệ đã bị ném khi tôi cố gắng kích hoạt một trong các lớp giao thoa của chúng trong thời gian chạy. Chúng tôi đảm bảo rằng tất cả các tài liệu tham khảo khác đã được cập nhật, nhưng vẫn không gặp may. Chúng tôi cần một thời gian để phát hiện (sử dụng Trình duyệt đối tượng) rằng kiểu trả về của phương thức trong thông báo lỗi là một loại hoàn toàn mới từ một tổ hợp mới, không được ước tính.

Chúng tôi đã thêm một tham chiếu đến lắp ráp và lỗi biến mất.

• Thông báo lỗi khá sai lệch, nhưng chỉ ra ít nhiều đúng hướng (đúng phương pháp, thông báo sai).
• Ngoại lệ bắt đầu ngay cả khi chúng tôi không sử dụng phương pháp được đề cập.
• Điều này dẫn tôi đến câu hỏi: Nếu ngoại lệ này được ném trong mọi trường hợp, tại sao trình biên dịch không chọn nó?

Tôi đã nhận được lỗi này trong kịch bản sau đây.

• Cả hai Hội đồng A và B đều tham chiếu System.Web.Mvc Phiên bản 3.0.0.0
• Hội A tham chiếu hội B và có các lớp thực hiện giao diện từ hội B với các phương thức trả về các lớp từ System.Web.Mvc.
• Hội A được nâng cấp lên System.Web.Mvc Phiên bản 4.0.0.0
• Hội C đã chạy mã bên dưới (FertPin.Class.Contact được chứa trong Hội A):

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

Bản sửa lỗi cho tôi là nâng cấp tham chiếu System.Web.Mvc trong Hội đồng B lên 4.0.0.0. Có vẻ rõ ràng bây giờ!

Để bảo vệ bạn, tất cả các đơn đặt hàng được mã hóa an toàn!

Lần khác bạn có thể gặp lỗi này là nếu bạn có một phiên bản lắp ráp đã ký không chính xác. Đây không phải là triệu chứng bình thường cho nguyên nhân này, nhưng đây là kịch bản mà tôi mắc phải

• một dự án asp.net chứa lắp ráp A và lắp ráp B, B được đặt tên mạnh mẽ

• lắp ráp A sử dụng Activator.CreateInstance để tải lắp ráp C (nghĩa là không có tham chiếu đến C được xây dựng riêng)

• C được xây dựng tham chiếu một phiên bản cũ hơn của lắp ráp B so với hiện tại

hy vọng điều đó sẽ giúp được ai đó - tôi mất nhiều thời gian để tìm ra điều này.

Tôi cũng gặp lỗi này, nguyên nhân là do bất kỳ CPU nào tham chiếu Bất kỳ hội đồng CPU nào lần lượt tham chiếu một cụm x86.

Ngoại lệ đã phàn nàn về một phương thức trên một lớp trong MyApp.Imcellenceations (Any CPU), dẫn xuất MyApp.Interfaces (Any CPU), nhưng trong fuslogvw.exe tôi đã tìm thấy một 'cố gắng tải chương trình với định dạng không chính xác' từ MyApp .CommonTypes (x86) được cả hai sử dụng.

Tôi tiếp tục quay lại vấn đề này ... Nhiều câu trả lời ở đây làm rất tốt việc giải thích vấn đề là gì nhưng không phải làm thế nào để khắc phục nó.

Giải pháp cho vấn đề này là xóa thủ công các tệp bin trong thư mục dự án đã xuất bản của bạn. Nó sẽ dọn sạch tất cả các tham chiếu và buộc dự án sử dụng các DLL mới nhất.

Tôi không đề xuất sử dụng chức năng xuất bản công cụ Xóa vì điều này có xu hướng làm mất IIS.

Tôi có một giải pháp bí truyền khác cho thông báo lỗi này. Tôi đã nâng cấp khung mục tiêu của mình từ .Net 4.0 lên 4.6 và dự án thử nghiệm đơn vị của tôi đã cho tôi lỗi "System.TypeLoadException ... không có lỗi triển khai" khi tôi cố gắng xây dựng. Nó cũng đưa ra một thông báo lỗi thứ hai về cùng một phương thức được cho là không được triển khai có nội dung "Nhiệm vụ 'BuildShadowTask' bị lỗi bất ngờ." Không có lời khuyên nào ở đây có vẻ hữu ích, vì vậy tôi đã tìm kiếm "BuildShadowTask" và tìm thấy một bài đăng trên MSDN dẫn tôi sử dụng trình soạn thảo văn bản để xóa các dòng này khỏi tệp csproj của dự án thử nghiệm đơn vị.

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

Sau đó, cả hai lỗi đã biến mất và dự án được xây dựng.

Tôi đã gặp lỗi này trong bối cảnh tôi đang sử dụng Autofac và rất nhiều tải lắp ráp động.

Trong khi thực hiện thao tác phân giải Autofac, bộ thực thi sẽ không tải được một trong các cụm. Thông báo lỗi phàn nàn rằng Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Các triệu chứng xảy ra khi chạy trên máy chủ Windows Server 2012 R2, nhưng không xảy ra trên máy ảo Windows 10 hoặc Windows Server 2016.

ImplementationAssemblyđã tham chiếu System.Collections.Immutable1.1.37 và chứa các triển khai của IMyInterface<T1,T2>giao diện, được xác định riêng biệt DefinitionAssembly. DefinitionAssemblytham chiếu System.Collections.Immutable1.1.36.

Các phương thức IMyInterface<T1,T2>mà "không được thực hiện" có các tham số kiểu IImmutableDictionary<TKey, TRow>, được xác định trong System.Collections.Immutable.

Bản sao thực tế System.Collections.Immutableđược tìm thấy trong thư mục chương trình là phiên bản 1.1.37. Trên máy chủ Windows Server 2012 R2 VM của tôi, GAC chứa bản sao System.Collections.Immutable1.1.36. Trên Windows 10 và Windows Server 2016, GAC chứa bản sao System.Collections.Immutable1.1.37. Lỗi tải chỉ xảy ra khi GAC chứa phiên bản cũ hơn của DLL.

Vì vậy, nguyên nhân gốc rễ của lỗi tải lắp ráp là các tham chiếu không khớp System.Collections.Immutable. Định nghĩa và triển khai giao diện có chữ ký phương thức trông giống hệt nhau, nhưng thực sự phụ thuộc vào các phiên bản khác nhau System.Collections.Immutable, điều đó có nghĩa là thời gian chạy không xem xét lớp thực hiện để khớp với định nghĩa giao diện.

Thêm chuyển hướng ràng buộc sau vào tệp cấu hình ứng dụng của tôi đã khắc phục sự cố:

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

Tôi đã nhận được điều này với một phụ thuộc dự án hình "kim cương":

• Dự án A sử dụng Dự án B và Dự án D
• Dự án B sử dụng Dự án D

Tôi đã biên dịch lại dự án A nhưng không phải Dự án B, cho phép Dự án B "tiêm" phiên bản cũ của Dự án D dll

Tôi gặp phải điều này khi tôi đổi tên một dự án (và tên lắp ráp), phụ thuộc vào một dự án ASP.NET. Các loại trong dự án web thực hiện giao diện trong hội đồng phụ thuộc. Mặc dù thực thi Clean Solution từ menu Build, nhưng cụm với tên trước đó vẫn nằm trong binthư mục và khi dự án web của tôi thực thi

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

ngoại lệ trên đã bị ném, phàn nàn rằng các phương thức giao diện trong các loại web triển khai không thực sự được triển khai. Xóa thủ công lắp ráp trong binthư mục của dự án web đã giải quyết vấn đề.

Tôi cũng đã gặp lỗi này khi trước đó tôi đã bật Mã bảo hiểm trong quá trình kiểm tra đơn vị cho một trong các hội đồng. Vì một số lý do, Visual Studio đã "đệm" phiên bản cũ của DLL cụ thể này mặc dù tôi đã cập nhật nó để triển khai phiên bản mới của giao diện. Vô hiệu hóa Bảo hiểm Mã đã thoát khỏi lỗi.

Lỗi này cũng có thể được gây ra nếu một tập hợp được tải bằng cách sử dụng Association.LoadFrom (String) và đang tham chiếu một tập hợp đã được tải bằng cách sử dụng Association.Load (Byte []).

Chẳng hạn, bạn đã nhúng các tập hợp được tham chiếu của ứng dụng chính dưới dạng tài nguyên nhưng ứng dụng của bạn tải các trình cắm từ một thư mục cụ thể.

Thay vì sử dụng LoadFrom, bạn nên sử dụng Load. Các mã sau đây sẽ thực hiện công việc:

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

Một cách giải thích khác cho loại vấn đề này liên quan đến quản lý C ++.

Nếu bạn cố gắng sơ khai một giao diện được xác định trong một hội đồng được tạo bằng C ++ được quản lý có chữ ký đặc biệt, bạn sẽ có ngoại lệ khi sơ khai được tạo.

Điều này đúng với Rhino Mocks và có lẽ bất kỳ khung mô phỏng nào sử dụng System.Reflection.Emit.

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

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

Định nghĩa giao diện có chữ ký sau:

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

Lưu ý rằng kiểu C ++ longánh xạ tới System.Int32(hoặc đơn giản là inttrong C #). Đó là điều hơi mơ hồ modoptđang gây ra vấn đề như Ayende Rahien đã nêu trong danh sách gửi thư của Rhino Mocks .

Tôi vừa nâng cấp một giải pháp từ MVC3 lên MVC5 và bắt đầu nhận được ngoại lệ tương tự từ dự án thử nghiệm Đơn vị của tôi.

Đã kiểm tra tất cả các tài liệu tham khảo tìm kiếm các tập tin cũ, cuối cùng tôi phát hiện ra tôi cần thực hiện một số ràng buộc cho Mvc, trong dự án thử nghiệm đơn vị của tôi.

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

Trong trường hợp của tôi, nó đã giúp thiết lập lại Hộp công cụ WinForms.

Tôi đã có ngoại lệ khi mở một Formtrong các nhà thiết kế; tuy nhiên, biên dịch và chạy mã là có thể và mã hoạt động như mong đợi. Ngoại lệ xảy ra ở một địa phương UserControltriển khai giao diện từ một trong các thư viện được tham chiếu của tôi. Lỗi xuất hiện sau khi thư viện này được cập nhật.

Điều này UserControlđã được liệt kê trong Hộp công cụ WinForms. Có lẽ Visual Studio giữ một tài liệu tham khảo về một phiên bản lỗi thời của thư viện hoặc đang lưu trữ một phiên bản lỗi thời ở đâu đó.

Đây là cách tôi phục hồi từ tình huống này:

1. Nhấp chuột phải vào Hộp công cụ WinForms và nhấp vào Reset Toolboxtrong menu ngữ cảnh. (Thao tác này sẽ xóa các mục tùy chỉnh khỏi Hộp công cụ).
   Trong trường hợp của tôi, các mục Hộp công cụ đã được khôi phục về trạng thái mặc định; tuy nhiên, mũi tên con trỏ bị thiếu trong Hộp công cụ.
2. Đóng Visual Studio.
   Trong trường hợp của tôi, Visual Studio bị chấm dứt ngoại lệ vi phạm và bị hủy bỏ.
3. Khởi động lại Visual Studio.
   Bây giờ mọi thứ đang chạy trơn tru.

FWIW, tôi đã nhận được điều này khi có một tệp cấu hình được chuyển hướng đến một phiên bản không tồn tại của một hội đồng tham chiếu. Nhật ký kết hợp cho chiến thắng!

Tôi đã gặp lỗi này vì tôi có một lớp trong một cụm 'C' trên phiên bản 4.5 của khung, triển khai một giao diện trong cụm 'A' trên phiên bản 4.5.1 của khung và đóng vai trò là lớp cơ sở để lắp ráp 'B' cũng trên phiên bản 4.5.1 của khung. Hệ thống đã ném ngoại lệ trong khi cố gắng tải lắp ráp 'B'. Ngoài ra, tôi đã cài đặt một số gói nuget nhắm mục tiêu .net 4.5.1 trên cả ba cụm. Vì một số lý do, mặc dù các tham chiếu nuget không hiển thị trong cụm 'B', nó đã được xây dựng thành công.

Hóa ra vấn đề thực sự là các hội đồng đã tham khảo các phiên bản khác nhau của gói nuget có giao diện và chữ ký giao diện đã thay đổi giữa các phiên bản.

Trong trường hợp của tôi, trước đây tôi đã tham chiếu một mylibdự án trong một thư mục anh chị em bên ngoài repo - hãy gọi nó v1.0.

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

Sau đó tôi đã làm đúng và sử dụng nó thông qua một mô hình con git - hãy gọi nó v2.0. consoleAppTuy nhiên, một dự án đã không được cập nhật đúng cách. Nó vẫn đang tham khảo v1.0dự án cũ bên ngoài dự án git của tôi.

Thật khó hiểu , mặc dù *.csprojđã sai và chỉ vào v1.0, Visual Studio IDE đã chỉ ra đường dẫn như v2.0dự án! F12 để kiểm tra giao diện và lớp cũng đã đi đến v2.0phiên bản.

Việc lắp ráp được đặt vào thư mục bin bởi trình biên dịch là v1.0phiên bản, do đó đau đầu.

Thực tế là IDE đã nói dối tôi khiến tôi càng khó nhận ra lỗi.

Giải pháp : Đã xóa các tham chiếu dự án từ ConsoleAppvà tập hợp lại chúng.

Mẹo chung: Biên dịch lại tất cả các cụm từ đầu (nếu có thể, tất nhiên không thể cho các gói nuget) và kiểm tra tem datetime trong bin\debugthư mục. Bất kỳ hội đồng cũ ngày là vấn đề của bạn.

Tôi đã đối mặt với vấn đề gần như tương tự. Tôi đã gãi đầu những gì gây ra lỗi này. Tôi đã kiểm tra chéo, tất cả các phương pháp đã được thực hiện.

Trên Googling tôi đã nhận được liên kết này trong số khác. Dựa trên nhận xét @Paul McLink, hai bước này đã giải quyết vấn đề.

1. Khởi động lại Visual Studio
2. Làm sạch, xây dựng (xây dựng lại)

và lỗi đã biến mất .

Khởi động lại Plugin VS

Cảm ơn Paul :)

Hy vọng điều này sẽ giúp ai đó gặp phải lỗi này :)

Tôi cũng gặp phải vấn đề này trong khi điều hành những điều không may mắn của mình. Ứng dụng chạy tốt và không có lỗi. Nguyên nhân của vấn đề trong trường hợp của tôi là do tôi đã tắt tòa nhà của các dự án thử nghiệm. Tái hiện việc xây dựng các sản phẩm thử nghiệm của tôi đã giải quyết các vấn đề.

Tôi đã thấy điều này trong Visual Studio Pro 2008 khi hai dự án xây dựng các hội đồng có cùng tên, một dự án lib SDF.dll và một tham chiếu lib với tên tập hợp sdf.exe. Khi tôi thay đổi tên của hội đồng tham chiếu, ngoại lệ biến mất

Điều này đơn giản có nghĩa là dự án thực hiện đã lỗi thời trong trường hợp của tôi. DLL chứa giao diện đã được xây dựng lại nhưng dll thực hiện đã cũ.

Đây là lỗi của tôi.

Đã thêm một externphương thức, nhưng dán của tôi bị lỗi. Đã DllImportAttributenhận được trên một dòng nhận xét.

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

Đảm bảo thuộc tính thực sự được bao gồm trong nguồn đã khắc phục sự cố.

Tôi đã nhận được điều này trong dịch vụ WCF do đã chọn loại bản dựng x86, khiến các thùng rác nằm dưới bin \ x86 thay vì bin. Chọn bất kỳ CPU nào khiến các DLL được biên dịch lại đi đến đúng vị trí (tôi sẽ không đi sâu vào chi tiết về cách điều này xảy ra ở vị trí đầu tiên).

Tôi đã từng gặp vấn đề tương tự. Tôi nhận ra rằng hội đồng của tôi, được tải bởi chương trình chính, đã có một số tham chiếu với "Sao chép cục bộ" được đặt thành đúng. Các bản sao tham chiếu cục bộ này đang tìm kiếm các tham chiếu khác trong cùng một thư mục, không tồn tại vì "Sao chép cục bộ" của các tham chiếu khác được đặt thành false. Sau khi xóa các tham chiếu được sao chép "vô tình", lỗi đã biến mất vì chương trình chính được đặt để tìm vị trí chính xác của các tham chiếu. Rõ ràng các bản sao cục bộ của các tài liệu tham khảo đã làm rối loạn trình tự gọi vì các bản sao cục bộ này đã được sử dụng thay vì các bản gốc có trong chương trình chính.

Thông báo mang về nhà là lỗi này xuất hiện do liên kết bị thiếu để tải lắp ráp cần thiết.

Trong trường hợp của tôi, tôi đã cố gắng sử dụng TypeBuilderđể tạo một loại. TypeBuilder.CreateTypeđã ném ngoại lệ này. Cuối cùng tôi nhận ra rằng tôi cần thêm MethodAttributes.Virtualvào các thuộc tính khi gọi TypeBuilder.DefineMethodmột phương thức giúp thực hiện một giao diện. Điều này là do không có cờ này, phương thức không thực hiện giao diện, mà thay vào đó là một phương thức mới có cùng chữ ký (thậm chí không có chỉ định MethodAttributes.NewSlot).

Là một phụ lục: điều này cũng có thể xảy ra nếu bạn cập nhật gói nuget đã được sử dụng để tạo ra một cụm giả mạo. Giả sử bạn cài đặt V1.0 của gói nuget và tạo một cụm giả mạo "fakeL Library.1.0.0.0.Fakes". Tiếp theo, bạn cập nhật lên phiên bản mới nhất của gói nuget, giả sử v1.1 đã thêm một phương thức mới vào giao diện. Thư viện Fakes vẫn đang tìm kiếm v1.0 của thư viện. Đơn giản chỉ cần loại bỏ lắp ráp giả và tái tạo nó. Nếu đó là vấn đề, điều này có thể sẽ khắc phục nó.

Tôi đã nhận được lỗi này sau khi cập nhật Windows gần đây. Tôi đã có một lớp dịch vụ được thiết kế để kế thừa từ một giao diện. Giao diện chứa chữ ký trả về ValueTuple, một tính năng khá mới trong C #.

Tất cả những gì tôi có thể đoán là bản cập nhật windows đã cài đặt một bản mới, nhưng thậm chí còn tham chiếu rõ ràng, cập nhật các chuyển hướng ràng buộc, v.v ... Kết quả cuối cùng chỉ là thay đổi chữ ký của phương thức thành một thứ "chuẩn" tôi đoán bạn có thể nói.