System.MissingMethodException: Không tìm thấy phương thức?


244

Những gì đã từng làm việc trong ứng dụng biểu mẫu web asp.net của tôi bây giờ ném lỗi này:

System.MissingMethodException: Không tìm thấy phương thức

Các DoThisphương pháp là trên cùng lớp và nó sẽ làm việc.

Tôi có một trình xử lý chung như vậy:

public class MyHandler: IHttpHandler
{
    public void Processrequest(HttpContext context)
    {
      // throws error now System.MissingMethodException: Method not found?
      this.DoThis(); 
    }

    public void DoThis()
    {
    //
    }
}

bạn có thể gửi thêm một số mã, bởi vì mã này không hợp lệ.
mironych

2
somepagegì Như "âm thanh" đã lưu ý, mã này không hợp lệ. Vui lòng cung cấp cho chúng tôi một đoạn mã hoàn chỉnh thể hiện vấn đề.
Amy

Câu trả lời:


387

Đây là một vấn đề có thể xảy ra khi có một phiên bản cũ của DLL vẫn còn tồn tại ở đâu đó xung quanh. Đảm bảo rằng các tập hợp mới nhất được triển khai và không có tập hợp cũ trùng lặp nào được ẩn trong các thư mục nhất định. Đặt cược tốt nhất của bạn sẽ là xóa mọi mục được xây dựng và xây dựng lại / triển khai lại toàn bộ giải pháp.


62
Đặc biệt, hãy chắc chắn rằng một phiên bản cũ không có trong GAC.
ladenedge

7
Ngoài ra, nếu bạn đang làm việc trong trường hợp không may khi bạn có một thư viện phụ thuộc vào thư viện, thì phụ thuộc vào thư viện, v.v. Sau đó, hãy đảm bảo Dọn dẹp / Xây dựng lại tất cả các thư viện phụ thuộc với cùng một phiên bản nào, NHibernate trong trường hợp của tôi ...
Serj Sagan

2
Nâng cấp khung mục tiêu .NET cho dự án cũng có thể sửa lỗi. Tôi đã nâng cấp dự án MVC4 / Web API 1 nhắm mục tiêu .NET 4.5. Sau khi nâng cấp tất cả các phụ thuộc MVC, API Web và Entity Framework, tôi gặp phải lỗi tương tự; việc thay đổi khung đích thành .NET 4.5.1 đã khiến lỗi không còn nữa.
Serge K

1
Nó xảy ra với tôi khi tôi chỉ triển khai một tệp exe đã thay đổi và không triển khai một trình trợ giúp vì nó không có bất kỳ thay đổi mã nào - nhưng nó đã được xây dựng lại. Tôi đã triển khai dll xây dựng lại và lỗi đã biến mất. Tôi đã thực hiện các triển khai khác mà không triển khai lại một dll không thay đổi khác và không có vấn đề gì nên tôi vẫn không chắc chắn chính xác những gì đã xảy ra ở đây. Tôi đoán điều an toàn cần làm là triển khai bất kỳ tệp được xây dựng lại nào, bất kể nó có thay đổi mã cơ bản hay không.
Hồ Hồ Hồ

14
Tôi thấy hữu ích khi mở cửa sổ Gỡ lỗi -> Windows -> Mô-đun khi gỡ lỗi để xem nơi lắp ráp được tải từ đâu.
JamesD

31

⚠️ sai NuGet Package Version ⚠️

Tôi đã có một dự án đơn vị thử nghiệm được kéo vào các công ty của chúng tôi nội EF NuGet truy cập dữ liệu gói và kéo vào một gói bên ngoài có phiên bản là cách đằng sau những phiên bản hiện tại.

Vấn đề là cài đặt Nuget cho gói được đặt thành least version; và phiên bản cũ hơn đã thắng và được sử dụng trong các hoạt động ....

Do đó, nó âm thầm có phiên bản sai cho một hội đồng phổ biến được sử dụng bởi cả gói và ứng dụng.


💡 Giải pháp 💡

Bằng cách Cài đặt / cập nhật gói trong Nuget để sử dụng và [lấy] mới nhất , đã khắc phục sự cố.


1
CÁi này đã sửa nó giúp tôi. Việc quản lý các gói cho giải pháp không hiệu quả, nhưng tôi phải cập nhật từng dự án riêng lẻ.
aoakeson

Dự án thử nghiệm đơn vị của tôi đã tham khảo một phiên bản mới hơn dự án thực tế của tôi
Rhyous

26

Tôi đã giải quyết vấn đề này bằng cách cài đặt phiên bản .NET Framework chính xác trên máy chủ. Trang web đang chạy theo phiên bản 4.0 và bản lắp ráp mà nó đang gọi được biên dịch cho 4.5. Sau khi cài đặt .NET Framework 4.5 và nâng cấp trang web lên 4.5, tất cả đều hoạt động tốt.


2
Một số vấn đề với mục tiêu biên dịch .NET 3.5 và đã cài đặt .NET 3. Tôi thực sự tự hỏi tại sao không có cảnh báo cơ bản nào khi khởi động ...
Martin Meeser

Đối với phiên bản .NET Framework> 4.0, bạn cần chỉ định đơn vị lưu trữ chứng khoán (SKU), nó chỉ ra phiên bản của .NET Framework mà ứng dụng nhắm mục tiêu. docs.microsoft.com/en-us/dotnet/framework/configure-apps/iêu
bgcode

21

Khởi động lại Visual Studio thực sự đã sửa nó cho tôi. Tôi nghĩ rằng đó là do các tập tin lắp ráp cũ vẫn còn sử dụng và thực hiện "Clean Build" hoặc khởi động lại VS nên khắc phục nó.


5

Tôi đã có điều này xảy ra với tôi với một tệp được tham chiếu trong cùng một hội đồng, không phải là một dll riêng. Khi tôi loại trừ tệp khỏi dự án và sau đó đưa nó trở lại, mọi thứ đều hoạt động tốt.


5

Tôi vừa chạy vào đây trong một dự án .NET MVC. Nguyên nhân sâu xa là các phiên bản xung đột của các gói NuGet. Tôi đã có một giải pháp với một số dự án. Mỗi dự án có một số gói NuGet. Trong một dự án, tôi đã có một phiên bản của gói Ghi nhật ký ngữ nghĩa thư viện doanh nghiệp và trong hai dự án khác (tham chiếu đầu tiên) tôi đã có các phiên bản cũ hơn của cùng một gói. Tất cả đều biên dịch không có lỗi, nhưng nó đã báo lỗi "Phương pháp không tìm thấy" bí ẩn khi tôi cố gắng sử dụng gói.

Cách khắc phục là xóa các gói NuGet cũ khỏi hai dự án, để nó chỉ được bao gồm trong một dự án thực sự cần nó. (Ngoài ra tôi đã xây dựng lại toàn bộ giải pháp.)


5

Kiểm tra tài liệu tham khảo của bạn!

Hãy chắc chắn rằng bạn luôn chỉ đến cùng các thư viện của bên thứ 3 (không chỉ tin tưởng các phiên bản, nhìn vào đường dẫn) trên các dự án giải pháp của bạn.

Ví dụ: Nếu bạn sử dụng iTextSharp v.1.00.101 trong một dự án và bạn NuGet hoặc tham khảo iTextSharp v1.00.102 ở một nơi khác, bạn sẽ nhận được các loại lỗi thời gian chạy bằng cách nào đó mắc vào mã của bạn.

Tôi đã thay đổi tham chiếu của mình sang iTextSharp trong cả 3 dự án để trỏ đến cùng một DLL và mọi thứ đều hoạt động.


Đối với tôi, nó hoạt động tốt để làm sạch dự án và xóa và thêm một số tài liệu tham khảo một lần nữa.
Honza P.

Đây là một vấn đề đặc biệt với VS 2017 vì nó thường cung cấp cho bạn thêm một tham chiếu đặt đường dẫn nguồn vào thư mục đầu ra của một dự án khác trong giải pháp, chứ không phải thư mục đầu ra của cụm tham chiếu.
Ông TA

4

Nếu phát triển với máy chủ NuGet của riêng bạn, hãy đảm bảo các phiên bản lắp ráp đều giống nhau:

[assembly: AssemblyVersion("0.2.6")]
[assembly: AssemblyFileVersion("0.2.6")]
[assembly: AssemblyInformationalVersion("0.2.6")]

Làm thế nào tôi nên kiểm tra nó?
SerG

Tôi nghĩ trong nupkg.
sennett


3

Bạn đã thử tắt và bật lại chưa? Đùa sang một bên, khởi động lại máy tính của tôi là những gì thực sự đã lừa tôi và không được đề cập trong bất kỳ câu trả lời nào khác.


3

Tôi vừa gặp vấn đề này và hóa ra đó là do tôi đã tham khảo phiên bản trước của DLL từ dự án UI của mình. Do đó, khi biên dịch nó là hạnh phúc. Nhưng khi chạy nó đã sử dụng phiên bản trước của DLL.

Kiểm tra tài liệu tham khảo trên tất cả các dự án khác trước khi cho rằng bạn cần xây dựng lại / dọn dẹp / triển khai lại các giải pháp của mình.


2

Trong trường hợp của tôi, đó là một vấn đề sao chép / dán. Tôi bằng cách nào đó đã kết thúc với một hàm tạo RIÊNG TƯ cho hồ sơ ánh xạ của mình:

using AutoMapper;

namespace Your.Namespace
{
    public class MappingProfile : Profile
    {
        MappingProfile()
        {
            CreateMap<Animal, AnimalDto>();
        }
    }
}

(lưu ý đến "công khai" bị thiếu trước ctor)

được biên dịch hoàn toàn tốt, nhưng khi AutoMapper cố gắng khởi tạo hồ sơ, nó không thể (dĩ nhiên!) tìm thấy hàm tạo!


@RenaudGauthier có thể tôi đã đọc sai điều gì đó trong câu trả lời của Jon Skeets, nhưng anh ta nói rằng các lớp không có công cụ sửa đổi truy cập là nội bộ, và trong các bình luận, anh ta nói theo nghĩa đen là "Không phải vậy. Nếu bạn tuyên bố một nhà xây dựng và không chỉ định khả năng truy cập, nó sẽ ở chế độ riêng tư. Xem phần 10.3.5 của thông số C # ". Vì vậy, tôi đoán rằng nhà xây dựng của tôi là riêng tư? Xin hãy sửa tôi nếu tôi nhầm. Và vâng, câu trả lời của tôi nằm ngoài ngữ cảnh, tôi đến đây từ một câu hỏi khác (không cung cấp câu trả lời cho tôi). Tôi sẽ thêm một liên kết đến câu trả lời của tôi ở đó quá.
DaBeSoft

Bạn hoàn toàn đúng, đừng bận tâm đến tôi, tôi đã xóa bình luận vô dụng.
Renaud Gauthier

1

Tôi đã có một kịch bản tương tự khi tôi bị ném ngoại lệ tương tự. Tôi đã có hai dự án trong giải pháp ứng dụng web của mình, được đặt tên, ví dụ, DAL và DAL.CustSpec. Dự án DAL có một phương thức có tên là Phương thức 1, nhưng DAL.CustSpec thì không. Dự án chính của tôi có một tài liệu tham khảo cho dự án DAL và cũng là một tài liệu tham khảo cho một dự án khác có tên AnotherProj. Dự án chính của tôi đã thực hiện một cuộc gọi đến Phương thức1. Dự án AnotherProj có tham chiếu đến dự án DAL.CustSpec chứ không phải dự án DAL. Cấu hình Build có cả dự án DAL và DAL.CustSpec được cấu hình để xây dựng. Sau khi mọi thứ được xây dựng, dự án ứng dụng web của tôi có các hội đồng AnotherProj và DAL trong thư mục Bin của nó. Tuy nhiên, khi tôi chạy trang web, thư mục ASP.NET tạm thời cho trang web có tập hợp DAL.CustSpec trong các tệp của nó chứ không phải tập hợp DAL, đối với một số lý do. Tất nhiên, khi tôi chạy phần có tên Phương thức 1, tôi đã nhận được lỗi "Phương pháp không tìm thấy".

Điều tôi phải làm để khắc phục lỗi này là thay đổi tham chiếu trong dự án AnotherProj từ DAL.CustSpec thành DAL, xóa tất cả các tệp trong thư mục Tệp ASP.NET tạm thời, sau đó chạy lại trang web. Sau đó, mọi thứ bắt đầu làm việc. Tôi cũng đảm bảo rằng dự án DAL.CustSpec không được xây dựng bằng cách bỏ chọn nó trong Cấu hình xây dựng.

Tôi nghĩ rằng tôi sẽ chia sẻ điều này trong trường hợp nó giúp người khác trong tương lai.


1

Tôi đã gặp tình huống tương tự trong trang web ASP.NET của tôi. Tôi đã xóa các tập tin được xuất bản, khởi động lại VS, làm sạch và xây dựng lại dự án. Sau lần xuất bản tiếp theo, lỗi đã biến mất ...


1

Tôi đã giải quyết vấn đề này bằng cách tạo một giá đỡ với các thay đổi của mình và chạy 'scorch' của TFS Power Tools trong không gian làm việc của tôi ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Sau đó, tôi đã giải quyết các thay đổi và biên dịch lại dự án. Bằng cách này, bạn sẽ dọn sạch bất kỳ 'bữa tiệc treo' nào có thể xuất hiện trong không gian làm việc của bạn và sẽ khởi động với một "bữa tiệc mới". Tất nhiên, điều này đòi hỏi bạn phải sử dụng TFS.


1

Cũng có thể vấn đề xảy ra với một tham số hoặc kiểu trả về của phương thức được báo cáo bị thiếu và phương thức "mất tích" mỗi se là ổn.

Đó là những gì đã xảy ra trong trường hợp của tôi và thông điệp sai lệch khiến tôi mất nhiều thời gian hơn để tìm ra vấn đề. Hóa ra việc lắp ráp cho loại tham số có phiên bản cũ hơn trong GAC, nhưng phiên bản cũ hơn thực sự có số phiên bản cao hơn do sự thay đổi trong sơ đồ đánh số phiên bản được sử dụng. Việc xóa phiên bản cũ hơn / cao hơn khỏi GAC đã khắc phục sự cố.


1

Sử dụng Costura.Fody 1.6 & 2.0:
Sau khi lãng phí rất nhiều thời gian để xem xét loại lỗi tương tự này với tất cả các giải pháp tiềm năng khác không hoạt động, tôi thấy rằng một phiên bản cũ hơn của DLL mà tôi đang nhúng nằm trong cùng thư mục tôi đang chạy mới được biên dịch .exe từ. Rõ ràng nó tìm kiếm một tệp cục bộ trong cùng thư mục trước, sau đó nhìn vào thư viện nhúng của nó. Xóa DLL cũ làm việc.

Để rõ ràng, không phải là tài liệu tham khảo của tôi đã trỏ đến một DLL cũ, đó là một bản sao của một DLL cũ nằm trong thư mục mà tôi đang kiểm tra ứng dụng của mình từ một hệ thống riêng biệt từ đó được biên dịch.


1

Trong trường hợp của tôi, đó là một thư mục với các DLL cũ cùng tên mà các tệp đó được tham chiếu trong tệp .csproj của tôi mặc dù đường dẫn được cung cấp rõ ràng do đó chúng được bao gồm bằng cách nào đó do đó một số phiên bản của cùng một DLL bị xung đột.



1

Trong trường hợp của tôi, MissingMethodException dành cho một phương thức nằm trong cùng một tệp!

Tuy nhiên, tôi vừa thêm gói NuGet sử dụng .Net Standard2 vào dự án nhắm mục tiêu 4.7.1 của mình, điều này đã gây ra xung đột phiên bản cho System.Net.Http (4.7.1: phiên bản 4.0.0.0, gói NuGet sử dụng .NET Tiêu chuẩn 2 muốn 4.2.0.0). Đây có vẻ là vấn đề đã biết nên tốt hơn trong 4.7.2 (xem chú thích 2) .

Tôi đã sử dụng một chuyển hướng ràng buộc như thế này trong tất cả các dự án khác của mình, bởi vì có những trường hợp ngoại lệ ngay khi nó cố tải 4.2.0.0 mà tôi không có:

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>

Ngoại trừ trong một dự án này, dường như nó chỉ cố tải System.Net.Http trong khi gọi một hàm cục bộ sử dụng System.Net.Http.HttpResponseMessage làm tham số hoặc kiểu trả về (tham số trong khi gỡ lỗi, trả về kiểu khi tôi chạy các bài kiểm tra không có trình gỡ lỗi, cũng hơi lạ). Và thay vì hiển thị một thông báo rằng nó không thể tải phiên bản 4.2.0.0 của System.Net.Http, nó trả về ngoại lệ này.


0

Điều này đã xảy ra với tôi khi sử dụng MVC4 và tôi đã quyết định sau khi đọc chủ đề này để đổi tên đối tượng đang ném lỗi.

Tôi đã làm sạch và xây dựng lại và lưu ý rằng nó đã bỏ qua hai dự án. Khi tôi xây dựng lại một trong số chúng, đã xảy ra lỗi khi tôi bắt đầu một chức năng và chưa hoàn thành nó.

Vì vậy, VS đã tham khảo một mô hình mà tôi đã viết lại mà không hỏi tôi có muốn làm điều đó không.


0

Chỉ trong trường hợp nó giúp được bất cứ ai, mặc dù đó là một vấn đề cũ, vấn đề của tôi hơi kỳ quặc.

Tôi đã có lỗi này trong khi sử dụng Jenkins.

Cuối cùng phát hiện ra rằng ngày hệ thống được đặt thủ công thành một ngày trong tương lai, điều này khiến dll được biên dịch với ngày đó trong tương lai. Khi ngày được đặt trở lại bình thường, MSBuild giải thích rằng tệp mới hơn và không yêu cầu biên dịch lại dự án.


0

Tôi gặp phải vấn đề này và điều mà đối với tôi là một dự án đang sử dụng Danh sách trong không gian tên example.Sensors và một loại khác đã triển khai giao diện ISensorInfo. Lớp Type1SensorInfo, nhưng lớp này sâu hơn một lớp trong không gian tên tại example.Sensors.Type1. Khi cố gắng giải tuần tự Type1SensorInfo vào danh sách, nó đã ném ngoại lệ. Khi tôi thêm bằng cách sử dụng example.Sensors.Type1 vào giao diện ISensorInfo, không có ngoại lệ nào nữa!

namespace Example
{
    public class ConfigFile
    {
        public ConfigFile()
        {
            Sensors = new List<ISensorInfo<Int32>>();
        }
        public List<ISensorInfo<Int32>> Sensors { get; set; }
     }
   }
}

**using Example.Sensors.Type1; // Added this to not throw the exception**
using System;

namespace Example.Sensors
{
    public interface ISensorInfo<T>
    {
        String SensorName { get; }
    }
}

using Example.Sensors;

namespace Example.Sensors.Type1
{
    public class Type1SensorInfo<T> : ISensorInfo<T>
    {
        public Type1SensorInfo() 
    }
}

0

Tôi đã có một điều tương tự xảy ra khi tôi có một số quy trình MSBuild đang chạy trong nền bị lỗi một cách hiệu quả (chúng có các tham chiếu đến các phiên bản mã cũ). Tôi đã đóng VS và giết tất cả các quy trình MSBuild trong trình thám hiểm quy trình và sau đó biên dịch lại.


0

Tôi đã có một dự án thử nghiệm tham chiếu 2 dự án khác mà mỗi dự án tham chiếu các phiên bản khác nhau (ở các vị trí khác nhau) của cùng một dll. Điều này làm bối rối trình biên dịch.


0

Trong trường hợp của tôi, Spotify.exe đã sử dụng cùng một cổng mà dự án api web của tôi muốn sử dụng trên máy phát triển. Số cổng là 4381.

Tôi bỏ Spotify và mọi thứ hoạt động tốt trở lại :)


0

Tôi gặp vấn đề này khi phương thức yêu cầu một tham số mà tôi không chỉ định


0

Trong trường hợp của tôi, không có thay đổi mã nào cả và đột nhiên một trong các máy chủ bắt đầu nhận được điều này và chỉ có ngoại lệ này (tất cả các máy chủ có cùng mã, nhưng chỉ có một máy bắt đầu gặp sự cố):

System.MissingMethodException: Method not found: '?'.

Cây rơm:

Server stack trace: 
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request)
   at myAccountSearch.AccountSearchClient.myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request)
   at myAccountSearch.AccountSearchClient.searchtPhone(String ID, String HashID, searchtPhone Phone1)
   at WS.MyValidation(String AccountNumber, String PhoneNumber)

Vấn đề tôi tin là đã bị hỏng AppPool - chúng tôi đã tự động tái chế AppPool diễn ra hàng ngày vào lúc 3 giờ sáng và vấn đề bắt đầu lúc 3 giờ sáng và sau đó kết thúc vào lúc 3 giờ sáng ngày hôm sau.


0

Phải là một lỗi tham chiếu từ Microsoft.

Tôi đã dọn dẹp, xây dựng lại trên tất cả các thư viện của mình và vẫn gặp vấn đề tương tự và không thể giải quyết vấn đề này.

Tất cả những gì tôi đã làm là đóng Ứng dụng Visual Studio và mở lại. Điều đó đã lừa

Thật là bực bội khi một vấn đề đơn giản như vậy có thể mất nhiều thời gian để khắc phục bởi vì bạn sẽ không nghĩ rằng nó sẽ là một thứ như thế.


0

Trong trường hợp của tôi, dự án của tôi đã được tham khảo Microsoft.Net.Compilers.2.10.0. Khi tôi chuyển nó sang Microsoft.Net.Compilers.2.7.0, lỗi đã biến mất. Thật là một lỗi bí ẩn với nhiều nguyên nhân như vậy.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.