以前工作的asp.net webforms应用程序现在抛出这个错误:

系统。MissingMethodException:方法未找到

DoThis方法在同一个类上,它应该可以工作。

我有一个通用的处理程序,这样:

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

    public void DoThis(){ ... }
}

当前回答

我在同一个程序集中引用了一个文件,而不是一个单独的dll,就发生了这种情况。一旦我从项目中排除了该文件,然后又将其包含进来,一切都工作得很好。

其他回答

I had a similar scenario where I was getting this same exception being thrown. I had two projects in my web application solution, named, for sake of example, DAL and DAL.CustSpec. The DAL project had a method named Method1, but DAL.CustSpec did not. My main project had a reference to the DAL project and also a reference to another project named AnotherProj. My main project made a call to Method1. The AnotherProj project had a reference to the DAL.CustSpec project, and not the DAL project. The Build configuration had both the DAL and DAL.CustSpec projects configured to be built. After everything was built, my web application project had the AnotherProj and DAL assemblies in its Bin folder. However, when I ran the website, the Temporary ASP.NET folder for the website had the DAL.CustSpec assembly in its files and not the DAL assembly, for some reason. Of course, when I ran the part that called Method1, I received a "Method not found" error.

为了修复这个错误,我必须从DAL更改AnotherProj项目中的引用。CustSpec到只是DAL,删除了临时ASP中的所有文件。NET Files文件夹,然后重新运行网站。从那以后,一切都开始运转了。我还确保了DAL。在“生成配置”中取消选中CustSpec项目后,没有生成该项目。

我想我要分享这个,也许它能在未来帮助到其他人。

肯定是微软的参考bug。

我清理,重建了我所有的库,仍然有同样的问题,无法解决这个问题。

我所做的就是关闭Visual Studio应用程序,然后重新打开它。这招奏效了。

令人沮丧的是,这么简单的一个问题却要花这么长时间来解决,因为你不会想到它会是这样的。

可能的情况是

不匹配的nuget组件版本

问题详解

我们有一个解决方案生成了多个nuget包。

packageA 1.0中的类A

packageB 1.0中的B类

A参考B

所以当A和B都有更新时,我们必须更新packageA和packagb,但问题是我的团队成员之一没有更新packagb

现在PackageA 1.1仍然依赖于PackageB 1.0,但PackageB没有B类的更新版本

因此,它无法找到方法

解决方案

移动两个包到+1版本 在这种情况下,我移动了

PackageA 1.1 -> PackageA 1.2 .

包装0 . 1.1

但为了使事情更加对称,可以将两者移动到相同的版本

PackageA 1.1 -> PackageA 1.2 .

PackageB 1.0 -> PackageB 1.2

我在同一个程序集中引用了一个文件,而不是一个单独的dll,就发生了这种情况。一旦我从项目中排除了该文件,然后又将其包含进来,一切都工作得很好。

使用Costura。Fody 1.6 & 2.0: 在浪费了大量时间寻找所有其他潜在解决方案都不起作用的类似错误之后,我发现我嵌入的一个旧版本的DLL位于我运行新编译的.exe的同一目录中。显然,它首先在同一目录中查找本地文件,然后向内查找其嵌入式库。删除旧的DLL起作用了。

需要明确的是,我的引用并不是指向一个旧的DLL,而是旧DLL的副本位于我测试应用程序的目录中,该目录与编译应用程序的系统不同。