System.MissingMethodException：找不到方法？

发布于 2024-12-14 23:38:59 字数 450 浏览 0 评论 0原文

以前工作的 ASP.NET WebForms 应用程序现在抛出此错误：

System.MissingMethodException：找不到方法

DoThis 方法位于同一个类上，它应该可以工作。

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

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

    public void DoThis(){ ... }
}

原文

Previous working asp.net webforms app now throws this error:

System.MissingMethodException: Method not found

The DoThis method is on the same class and it should work.

I have a generic handler as such:

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

    public void DoThis(){ ... }
}

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

感情废物 2024-12-21 23:39:00

更新各种 Nuget 包后遇到此错误。检查 Visual Studio 错误列表（或生成输出）是否有类似于以下内容的警告：

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

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

回复收藏 0 原文

看轻我的陪伴 2024-12-21 23:39:00

可能的情况可能是

nuget 汇编版本不匹配

详细问题

我们有多个 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 ->套餐A 1.2

套餐B 1.0 -> PackageB 1.1，

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

PackageA 1.1 ->套餐A 1.2

套餐B 1.0 ->套餐B 1.2

回复收藏 0 原文

虫児飞 2024-12-21 23:39:00

我使用 MVC4 时发生过这种情况，阅读此线程后我决定重命名引发错误的对象。

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

因此，VS 引用了我重写的模型，而没有询问我是否愿意这样做。

回复收藏 0 原文

执手闯天涯 2024-12-21 23:39:00

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

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

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

回复收藏 0 原文

兰花执着 2024-12-21 23:39:00

我遇到了这个问题，对我来说，一个项目正在使用位于 Example.Sensors 命名空间中的 List，而另一种类型实现了 ISensorInfo 接口。类 Type1SensorInfo，但该类在命名空间中更深一层，位于Example.Sensors.Type1。当尝试将 Type1SensorInfo 反序列化到列表中时，它引发了异常。当我将 using Example.Sensors.Type1 添加到 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() 
    }
}

I ran into this issue, and what it was for me was one project was using a List which was in Example.Sensors namespace and and another type implemented the ISensorInfo interface. Class Type1SensorInfo, but this class was one layer deeper in the namespace at Example.Sensors.Type1. When trying to deserialize Type1SensorInfo into the list, it threw the exception. When I added using Example.Sensors.Type1 into the ISensorInfo interface, no more exception!

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 原文

血之狂魔 2024-12-21 23:39:00

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

回复收藏 0 原文

花之痕靓丽 2024-12-21 23:38:59

当旧版本的 DLL 仍然存在于某处时，就会出现此问题。确保部署最新的程序集，并且某些文件夹中没有隐藏重复的旧程序集。您最好的选择是删除每个构建项目并重建/重新部署整个解决方案。

回复收藏 0 原文

千纸鹤带着心事 2024-12-21 23:38:59

⚠️ 错误的 Nuget 包版本 ⚠️

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

问题在于，顶级包的 Nuget 设置被设置为最低版本；并且较低级别/旧版本获胜，并且在操作期间使用了......

因此，它默默地获得了两个包使用的通用程序集的错误版本和应用程序。

回复收藏 0 原文

守望孤独 2024-12-21 23:38:59

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

回复收藏 0 原文

猛虎独行 2024-12-21 23:38:59

重新启动 Visual Studio 实际上为我解决了这个问题。我认为这是由仍在使用的旧程序集文件引起的，执行“Clean Build”或重新启动 VS 应该可以修复它。

回复收藏 0 原文

尘世孤行 2024-12-21 23:38:59

检查您的参考资料！

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

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

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

回复收藏 0 原文

土豪 2024-12-21 23:38:59

另外..尝试“清理”您的项目或解决方案并再次重建！

回复收藏 0 原文

吲‖鸣 2024-12-21 23:38:59

我刚刚在 .NET MVC 项目中遇到了这个问题。根本原因是 NuGet 包的版本冲突。我有几个项目的解决方案。每个项目都有一些 NuGet 包。在一个项目中，我有一个版本的企业库语义日志记录包，在其他两个项目（引用第一个）中，我有同一包的旧版本。一切编译都没有错误，但当我尝试使用该包时，它给出了一个神秘的“找不到方法”错误。

修复方法是从两个项目中删除旧的 NuGet 包，以便它仅包含在实际需要它的一个项目中。（我还对整个解决方案进行了彻底的重建。）

回复收藏 0 原文

似狗非友 2024-12-21 23:38:59

我遇到过这种情况，是在同一个程序集中引用了一个文件，而不是一个单独的 dll。一旦我从项目中排除该文件然后再次包含它，一切就正常了。

回复收藏 0 原文

坠似风落 2024-12-21 23:38:59

如果使用您自己的 NuGet 服务器进行开发，请确保程序集版本全部相同：

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

If developing with your own NuGet server, make sure the assembly versions are all the same:

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

回复收藏 0 原文

沉默的熊 2024-12-21 23:38:59

您是否尝试过关闭然后再次打开？撇开笑话不谈，重新启动我的计算机实际上对我有用，并且在任何其他答案中都没有提到。

回复收藏 0 原文

绝情姑娘 2024-12-21 23:38:59

我刚刚遇到了这个问题，结果发现这是因为我从 UI 项目中引用了 DLL 的早期版本。所以，编译的时候是开心的。但运行时它使用的是以前版本的DLL。

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

回复收藏 0 原文

泪眸﹌ 2024-12-21 23:38:59

一定是微软的参考错误。

我清理并重建了所有库，但仍然遇到同样的问题并且无法解决此问题。

我所做的就是关闭 Visual Studio 应用程序并再次打开它。这就成功了。

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

回复收藏 0 原文

说谎友 2024-12-21 23:38:59

我遇到了这个问题的一种新颖的表现形式，它与几个现有的答案相关，但与其中任何一个都不完全相同。

我们的一个顶级应用程序引用了一个内部包，随后又引用了该包中的一个程序集。我们将此参考版本称为 1.0。

在运行时，它加载了一个插件，该插件也引用了相同的内部包（以及包中的程序集），但它是更新的版本，我们将此引用版本称为 2.0。

2.0 版在运行时路径中的任何地方都不可用。我们有一个程序集加载重定向，它通过从与直接引用发生的自动加载不同的位置加载引用的 1.0 版本来满足依赖关系。

针对应用程序中类型实现的接口的扩展方法发出的缺少成员异常。问题是，当运行时尝试查找扩展方法时，它从程序集的第二次加载中找到了命名空间。类型差异是由程序集的特定实例决定的，即使两者是相同的版本（最终是同一文件在磁盘上的两个不同副本）。

修复方法是相同的，协调涉及的版本。在这种情况下，我们还可以调整现有的解析代码，以不重新加载已加载的程序集。

回复收藏 0 原文

一指流沙 2024-12-21 23:38:59

我遇到过类似的情况，我也遇到了同样的异常。我的 Web 应用程序解决方案中有两个项目，例如，名为 DAL 和 DAL.CustSpec。 DAL 项目有一个名为 Method1 的方法，但 DAL.CustSpec 没有。我的主项目引用了 DAL 项目，还引用了另一个名为 AnotherProj 的项目。我的主项目调用了 Method1。 AnotherProj 项目引用了 DAL.CustSpec 项目，而不是 DAL 项目。构建配置同时配置了要构建的 DAL 和 DAL.CustSpec 项目。一切构建完成后，我的 Web 应用程序项目的 Bin 文件夹中包含 AnotherProj 和 DAL 程序集。但是，当我运行该网站时，由于某种原因，该网站的临时 ASP.NET 文件夹的文件中包含 DAL.CustSpec 程序集，而不是 DAL 程序集。当然，当我运行调用 Method1 的部分时，我收到了“找不到方法”错误。

要修复此错误，我必须做的是将 AnotherProj 项目中的引用从 DAL.CustSpec 更改为 DAL，删除 Temporary ASP.NET Files 文件夹中的所有文件，然后重新运行网站。之后，一切开始运转。我还通过在构建配置中取消选中 DAL.CustSpec 项目来确保它没有被构建。

我想我会分享这个，以防它将来对其他人有帮助。

回复收藏 0 原文

情痴 2024-12-21 23:38:59

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

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

回复收藏 0 原文

鹿! 2024-12-21 23:38:59

就我而言，这是一个复制/粘贴问题。我不知何故最终为我的映射配置文件提供了一个私有构造函数：（

using AutoMapper;

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

注意构造函数前面缺少的“public”），

它编译得很好，但是当 AutoMapper 尝试实例化配置文件时，它不能（当然！）找到构造函数！

In my case it was a copy/paste problem. I somehow ended up with a PRIVATE constructor for my mapping profile:

using AutoMapper;

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

(take note of the missing "public" in front of the ctor)

which compiled perfectly fine, but when AutoMapper tries to instantiate the profile it can't (of course!) find the constructor!

回复收藏 0 原文

离去的眼神 2024-12-21 23:38:59

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

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

回复收藏 0 原文

缱倦旧时光 2024-12-21 23:38:59

就我而言，我的项目引用了 Microsoft.Net.Compilers.2.10.0。当我将其切换到 Microsoft.Net.Compilers.2.7.0 时，错误消失了。原因多种多样，真是一个神秘的错误。

回复收藏 0 原文

那些过往 2024-12-21 23:38:59

就我而言，MissingMethodException 是针对同一文件中的方法！

但是，我刚刚向我的 4.7.1 目标项目添加了一个使用 .Net Standard2 的 NuGet 包，这导致了 System.Net.Http 的版本冲突（4.7.1：版本 4.0.0.0，使用 .NET 的 NuGet 包）标准 2 需要 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>

除了在这个项目中，它似乎尝试加载系统.Net.Http 仅同时调用使用 System.Net.Http.HttpResponseMessage 作为参数或返回类型的本地函数（调试期间的参数，在没有调试器的情况下运行测试时的返回类型，也有点奇怪）。它不会显示无法加载 4.2.0.0 版本的 System.Net.Http 的消息，而是返回此异常。

In my case, the MissingMethodException was for a method that was in the same file!

However, I had just added a NuGet package that uses .Net Standard2 to my 4.7.1-targeting project, which caused a version conflict for System.Net.Http (4.7.1: version 4.0.0.0, the NuGet package using .NET Standard 2 wants 4.2.0.0). This seem to be known issues that should be better in 4.7.2 (see note 2).

I had used a binding redirect like this in all other my projects, because there were exceptions as soon as it tried to load the 4.2.0.0 which I didn't have:

  <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>

Except in this one project, where it seems it tries to load System.Net.Http only while calling a local function that uses a System.Net.Http.HttpResponseMessage as it's parameter or return type (parameter during debugging, return type when I run the tests without the debugger, also a bit strange). And instead of showing a message that it could not load the 4.2.0.0 version of System.Net.Http, it returns this exception.

回复收藏 0 原文

扛起拖把扫天下 2024-12-21 23:38:59

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

回复收藏 0 原文

对岸观火 2024-12-21 23:38:59

我通过使用我的更改制作搁置集并在工作区中运行 TFS Power Tools 'scorch' 解决了这个问题 (https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f）。然后我取消了更改并重新编译了项目。
这样，您就可以清理工作空间中可能存在的所有“悬挂派对”，并开始一个新的派对。
当然，这要求您使用 TFS。

回复收藏 0 原文