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

我在同一个程序集中引用了一个文件，而不是一个单独的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项目后，没有生成该项目。

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

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

如果使用自己的NuGet服务器开发，请确保程序集版本都相同:

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

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

你试过把它关掉再打开吗?玩笑归玩笑，重启电脑才是真正让我成功的方法，其他答案中都没有提到。

我刚刚在一个。net MVC项目中遇到了这个问题。根本原因是NuGet包的版本冲突。我有几个项目的解决方案。每个项目都有一些NuGet包。在一个项目中，我使用了企业库语义日志包的一个版本，而在另外两个项目(引用了第一个项目)中，我使用了同一包的旧版本。它编译时没有错误，但是当我尝试使用这个包时，它给出了一个神秘的“Method not found”错误。

解决办法是从两个项目中删除旧的NuGet包，这样它就只包含在真正需要它的一个项目中。(我也对整个解决方案做了一个干净的重建。)

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

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

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

重新启动Visual Studio实际上为我解决了这个问题。我认为这是由于旧的程序集文件仍然在使用造成的，执行“清洁构建”或重新启动VS应该会修复它。

只是为了帮助任何人，虽然这是一个老问题，我的问题有点奇怪。

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

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

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

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

我解决了这个问题，我做了一个搁置我的变化和运行TFS电动工具“烧焦”在我的工作空间(https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f)。然后我取消了更改并重新编译项目。 这样你就可以清理你工作空间里的“挂着的聚会”，并重新开始一个新的聚会。 当然，这要求您使用TFS。

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

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

在假设您需要重新构建/清理/重新部署解决方案之前，请检查所有其他项目的参考资料。

检查你的推荐信!

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

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

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

我有一个测试项目，它引用了另外两个项目，每个项目引用了同一个dll的不同版本(在不同的位置)。这使编译器感到困惑。

在我的案例中，spotify.exe使用的端口与我的web api项目想要在开发机器上使用的端口相同。端口号为4381。

我退出了Spotify，一切又恢复正常了:)

也有可能问题出在报告丢失的方法的参数或返回类型上，而“丢失”方法本身没有问题。

这就是我的情况，误导性的信息让我花了更长的时间来解决问题。事实证明，用于参数类型的程序集在GAC中有一个较旧的版本，但由于所使用的版本编号方案的更改，旧版本实际上具有更高的版本号。从GAC中删除旧版本/更高版本可以解决这个问题。

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

using AutoMapper;

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

(注意演员面前少了一个“公众”)

它编译得非常好，但是当AutoMapper尝试实例化概要文件时，它不能(当然!)找到构造函数!

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

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

当方法需要一个我没有指定的参数时，我就遇到了这个问题

在我的情况下，根本没有代码更改，突然一个服务器开始得到这个，只有这个异常(所有服务器都有相同的代码，但只有一个开始有问题):

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

栈:

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)

我认为这个问题是AppPool被破坏了——我们每天凌晨3点自动回收AppPool，这个问题从凌晨3点开始，然后在第二天凌晨3点自行结束。

肯定是微软的参考bug。

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

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

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

在我的例子中，我的项目引用了Microsoft.Net.Compilers.2.10.0。当我把它切换到Microsoft.Net.Compilers.2.7.0时，错误消失了。有这么多原因的一个多么神秘的错误。

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

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

为了子孙后代，我在使用azure持久函数/持久任务框架时遇到了这个问题。原来我在本地安装了一个过时的azure函数运行时版本。更新它解决了这个问题。

在我的例子中，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，它返回这个异常。

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

So:

项目-> Nuget A -> Nuget X 1.1

项目-> Nuget B -> Nuget X 1.2

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

当我将Nuget A和B更新到引用相同版本的Nuget X时，错误就消失了。

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

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

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

我在测试同事编写的一些代码时遇到了这个异常。以下是异常信息的摘要:

方法未找到:“System.Threading.Tasks.Task1< microsoft . entityframeworkcore . changetrackingentityentry1 <System_Canon>> . System_Canon . changetrackingentityentry1” Microsoft.EntityFrameworkCore.DbSet“1. addasync…

这是在Visual Studio 2019中针对. net Core 3.1的类库中。修复方法是在DbSet上使用Add方法而不是AddAsync。

可能的情况是

不匹配的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

我使用了一种在上面的回复中没有提到的方法来解决这个问题。

在我的例子中，调用类方法的项目的目标项目框架设置不正确。

(调用项目的目标框架不正确。被调用的类/方法的目标框架是正确的，我保持不变)。