以前工作的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(){ ... }
}
当前回答
我也有同样的事情发生，当我有许多MSBuild进程在后台运行时，它们实际上已经崩溃了(它们引用了旧版本的代码)。我关闭VS并在进程资源管理器中杀死所有MSBuild进程，然后重新编译。
其他回答
在我的例子中，我的项目引用了Microsoft.Net.Compilers.2.10.0。当我把它切换到Microsoft.Net.Compilers.2.7.0时，错误消失了。有这么多原因的一个多么神秘的错误。
在我的案例中，spotify.exe使用的端口与我的web api项目想要在开发机器上使用的端口相同。端口号为4381。
我退出了Spotify，一切又恢复正常了:)
在我的例子中，MissingMethodException是针对同一个文件中的一个方法!
然而，我刚刚添加了一个使用. net Standard2的NuGet包到我的4.7.1-targeting项目中，这导致了System.Net.Http的版本冲突(4.7.1:版本4.0.0.0，使用. net Standard2的NuGet包需要4.2.0.0)。这似乎是已知的问题，应该更好的4.7.2(见注2)。
我在所有其他项目中都使用了这样的绑定重定向，因为一旦它试图加载4.2.0.0，就会出现异常:
<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>
除了在这个项目中，它似乎只是在调用使用System.Net.Http.HttpResponseMessage作为参数或返回类型的本地函数时试图加载System.Net.Http(调试期间的参数，在没有调试器的情况下运行测试时的返回类型，这也有点奇怪)。而不是显示消息，它无法加载4.2.0.0版本的System.Net。Http，它返回这个异常。
我遇到了这个问题，对我来说，它是一个项目，在例子中使用一个列表。传感器命名空间和另一种类型实现了ISensorInfo接口。类Type1SensorInfo，但是这个类在Example.Sensors.Type1的命名空间中更深一层。当试图将Type1SensorInfo反序列化到列表中时，会抛出异常。当我使用Example.Sensors添加时。输入1到ISensorInfo接口，没有更多的异常!
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()
}
}
使用Costura。Fody 1.6 & 2.0: 在浪费了大量时间寻找所有其他潜在解决方案都不起作用的类似错误之后，我发现我嵌入的一个旧版本的DLL位于我运行新编译的.exe的同一目录中。显然，它首先在同一目录中查找本地文件，然后向内查找其嵌入式库。删除旧的DLL起作用了。
需要明确的是，我的引用并不是指向一个旧的DLL，而是旧DLL的副本位于我测试应用程序的目录中，该目录与编译应用程序的系统不同。
