系统.MissingMethodException:方法未找到

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

这是一个可能发生的问题，当有一个旧版本的DLL仍然徘徊在某处。确保部署了最新的程序集，并且某些文件夹中没有隐藏重复的旧程序集。最好的办法是删除所有构建的项目，重新构建/重新部署整个解决方案。

⚠️错误Nuget包版本⚠️

我有一个单元测试项目，它拉入了我们公司内部的EF Nuget数据访问包，而代码拉入了一个外部包，该包的版本远远落后于当前版本。

问题是顶级包的Nuget设置被设置为 least version ;较低级别/旧版本获胜，并且在操作期间使用....

因此，对于包和应用都使用的通用程序集，它会无声地得到错误的版本。

---

解决方案

通过在Nuget中设置/更新包来使用和[get]最新的，修复了这个问题。

我通过在服务器上安装正确的。net Framework版本解决了这个问题。该网站在4.0版本下运行，它调用的程序集是在4.5版本下编译的。安装。net Framework 4.5并将网站升级到4.5后，一切正常。

重新启动Visual Studio实际上为我修复了它。我认为这是由仍在使用的旧汇编文件引起的，并且执行"清洁构建"或重新启动VS应该修复它。

检查你的推荐信!

确保你在你的解决方案项目中始终指向相同的第三方库(不要只相信版本，看看路径)。

例如，如果你在一个项目中使用iTextSharp v.1.00.101，而你在其他地方NuGet或引用iTextSharp v1.00.102，你将会得到这些类型的运行时错误，这些错误以某种方式慢慢地进入你的代码。

我在所有3个项目中更改了对iTextSharp的引用，以指向相同的DLL，一切都工作了。

also..尝试"清理"您的项目或解决方案并重新构建!

我在同一个程序集中引用了一个文件，而不是一个单独的dll。一旦我从项目中排除文件，然后再次包含它，一切都很好。

我刚刚在一个。net MVC项目中遇到了这个问题。根本原因是NuGet包版本冲突。我有几个项目的解决方案。每个项目都有一些NuGet包。在一个项目中，我使用了Enterprise Library Semantic Logging包的一个版本，而在另外两个项目(引用第一个)中，我使用了同一个包的旧版本。所有的编译都没有错误，但是当我试图使用这个包时，它给出了一个神秘的"Method not found"错误。

修复是从两个项目中删除旧的NuGet包，这样它就只包含在一个实际需要它的项目中。(我也做了一个完整的重建整个解决方案)

如果使用自己的NuGet服务器开发，请确保汇编版本都是相同的:

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

你试过关机再开机吗?抛开玩笑不谈，重启电脑才是真正让我成功的方法，其他答案中都没有提到这一点。

我刚刚遇到这个问题，事实证明，这是因为我从我的UI项目引用了以前版本的DLL。因此，在编译时它是快乐的。但是在运行时，它使用的是以前版本的DLL。

在假设需要重新构建/清理/重新部署解决方案之前，检查所有其他项目的引用。

问题也可能是报告丢失的方法的参数或返回类型，而"丢失的"方法本身是好的。

这就是发生在我身上的事情，误导的信息让我花了更长的时间才弄清楚问题所在。结果是，参数类型的程序集在GAC中有一个较旧的版本，但是由于所使用的版本编号方案发生了变化，较旧的版本实际上具有更高的版本号。从GAC中删除旧的/更高的版本修复了这个问题。

在我的情况下，这是一个复制/粘贴问题。我以某种方式结束了我的映射配置文件的PRIVATE构造函数:

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

(注意函数前面缺少"public")

编译得很好，但是当AutoMapper试图实例化配置文件时，它(当然!)找不到构造函数!

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

要明确的是，这并不是我的参考指向一个旧的DLL，而是一个旧DLL的副本在我从一个独立的系统上测试我的应用程序的目录中。

在我的例子中，MissingMethodException是针对同一个文件中的方法!

然而，我刚刚在我的4.7.1目标项目中添加了一个使用。net Standard2的NuGet包，这导致了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仅而调用使用System.Net.Http.HttpResponseMessage作为参数或返回类型的本地函数(调试期间的参数，当我运行测试时返回类型没有调试器，也有点奇怪)。而不是显示一个消息，它无法加载System.Net的4.2.0.0版本。Http，它返回这个异常。

我有一个类似的场景，我得到这个相同的异常被抛出。在我的web应用程序解决方案中，我有两个项目，命名为DAL和DAL. custspec。DAL项目有一个名为Method1的方法，但是DAL。CustSpec没有。我的主要项目引用了DAL项目，也引用了另一个名为AnotherProj的项目。我的主要项目调用了Method1。anotherproject项目有一个对DAL的引用。CustSpec项目，而不是DAL项目。Build配置同时具有DAL和DAL。配置要构建的CustSpec项目。一切构建完成后，我的web应用程序项目在其Bin文件夹中有AnotherProj和DAL程序集。然而，当我运行网站时，临时ASP。. NET文件夹的网站有DAL。由于某种原因，在其文件中的CustSpec程序集，而不是DAL程序集。当然，当我运行调用Method1的部分时，我收到了一个"Method not found"错误。

我要做的是修复这个错误是从DAL更改anotherproject项目中的引用。CustSpec到只是DAL，删除了临时ASP中的所有文件。. NET Files文件夹，然后重新运行该网站。在那之后，一切都开始运转了。我还确保DAL。没有通过在构建配置中取消选中来构建CustSpec项目。

我想我应该分享这个，以防它在未来帮助别人。

我在ASP中遇到了同样的情况。网的网站。我删除了发布的文件，重新启动VS，清理并重新构建项目。在下一次发布后，错误消失了……

我通过用我的更改制作一个shelvesset并在我的工作空间(https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f)运行TFS Power Tools 'scorch'来解决这个问题。然后我取消了这些修改，重新编译了这个项目。这样你就可以清理掉你工作空间里的"聚会"，然后重新开始。当然，这需要使用TFS。

一定是来自Microsoft的参考错误。

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

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

这么简单的一个问题要花这么长时间才能解决，因为你不会想到它会是那样的事情，这真是令人沮丧。

在我的情况下，我的项目是参考Microsoft.Net.Compilers.2.10.0。当我把它切换到Microsoft.Net.Compilers.2.7.0时，错误消失了。多么神秘的错误，原因如此多样。

在我的情况下，它是一个具有相同名称的旧dll的文件夹，这些dll在我的.csproj文件中被引用，尽管路径是明确给出的，但它们以某种方式包含在内，因此相同dll的几个版本存在冲突。

如果问题是由GAC中的旧版本程序集引起的
这有助于:如何:从全局程序集缓存中删除程序集。

这可能已经提到过了，但对我来说，问题是项目引用了2个nuget包，每个nuget包引用了另一个nuget包的不同版本。

:

Project -> Nuget A -> Nuget X 1.1

Project -> Nuget B -> Nuget X 1.2

两个版本的Nuget X都有从Project中调用的相同的扩展方法。

当我更新Nuget A &到引用相同版本的Nuget X的版本，错误消失了。

在更新各种Nuget包后遇到此错误。检查Visual Studio错误列表(或构建输出)是否有类似以下的警告:

发现同一依赖项的不同版本之间存在冲突组装。在Visual Studio中，双击此警告(或选择它)，按"Enter"键)修复冲突;否则，添加以下内容绑定将重定向到应用程序中的"运行时"节点配置文件:
…

在Visual Studio中双击此警告会自动调整我的web中的各种bindingRedirect包版本。配置并解决了错误。

可能是

不匹配的nuget汇编版本

Problem In Detail

我们有不止一个解决方案生成的nuget包。

packageA 1.0中的A类

packageB 1.0中的B类

A引用B

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

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

，因此无法找到

方法。解决方案

移动两个包到+1版本在本例中，我移动了

PackageA 1.1 ->PackageA 1.2

PackageB 1.0 ->PackageB 1.1

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

PackageA 1.1 ->PackageA 1.2

PackageB 1.0 ->PackageB 1.2

这发生在我使用MVC4时，我决定在阅读此线程后重命名抛出错误的对象。

我做了一个清理和重建，并注意到它跳过了两个项目。当我重新构建其中一个函数时，出现了一个错误，我启动了一个函数，但没有完成它。

所以VS引用了一个我重写的模型，而没有问我是否想这样做。

以防对任何人有所帮助，虽然这是一个老问题，但我的问题有点奇怪。

我在使用Jenkins时遇到了这个错误。

最终发现系统日期被手动设置为未来日期，这导致dll以该未来日期编译。当日期被设置回正常时，MSBuild解释为文件更新，不需要重新编译项目。

我遇到了这个问题，它对我来说是一个项目是使用列表的例子。传感器名称空间和另一个类型实现了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() 
    }
}

当我有许多MSBuild进程在后台运行时发生了同样的事情，这些进程实际上已经崩溃了(它们引用了旧版本的代码)。我关闭了VS并杀死了进程资源管理器中的所有MSBuild进程，然后重新编译。

我有一个测试项目，它引用了2个其他项目，每个项目引用了相同dll的不同版本(在不同的位置)。