在运行时找不到的方法
我有一个ASP.Net c＃项目试图访问另一个项目中的类中的方法。 它适用于类中的前半部分方法，但不适用于我最近添加的类中的另一半方法。 他们编译，但他们在运行时抛出一个未找到exception的方法。
有没有人有我可以尝试的想法？ 我试过了：
- 重新创建
.sln文件 - 在我认识的另一个类库项目中进行修改。 似乎错误在我的主项目中调用另一个项目中的方法。
“找不到方法”是一个非常具体的错误，这意味着它所期望的方法（即在编译时存在）根本就不存在。 这通常意味着您正在部署的文件与您认为的文件不同 – 具体而言，我会打赌您正在部署旧版本的库（缺少您的添加项）。
根据您的想法检查部署到Web服务器的dll。
我遇到过同样的问题。 在我的情况下，它是由添加可选参数引起的。 所以首先你会：
referencingAssembly：
referencedAssembly.DoStuff(firstArgument, secondArgument)
referencedAssembly：
public void DoStuff(string firstArgument, string secondArgument) { //stuff to do }
然后向该方法添加一个可选参数，但在调用它时不提供该参数。
referencingAssembly：
referencedAssembly.DoStuff(firstArgument, secondArgument)//unchanged
referencedAssembly：
public void DoStuff(string firstArgument, string secondArgument, string thirdArgument = "default value") { //stuff to do }
在本地，这将构建并运行正常，因为新构建的referencingAssembly.dll将引用DoStuff（字符串，字符串，字符串）方法。 但是当你只部署更改的referencedAssembly时（想想：添加的参数是可选的，并且referncingAssembly仍然有效），旧版本的referencingAssembly将抛出一个MethodNotFound，因为它寻找一个带有签名DoStuff（字符串，字符串）的方法，这是由于我们添加了额外的（可选）参数，因此不再出现在referencedAssembly中。
可能的解决方案可能是过载：
referencedAssembly：
public void DoStuff(string firstArgument, string secondArgument)//original method { DoStuff(firstArgument, secondArgument, "default value") } public void DoStuff(string firstArgument, string secondArgument, string thirdArgument)//new overload of the method { //stuff to do }
或部署新构建的referencingAssembly（将引用具有签名DoStuff的方法（字符串，字符串，字符串））。
有同样的问题，在我的情况下，在webconfig中将optimizeCompilations设置为false解决了问题
我遇到过这种问题，但能够解决它。 我清空了bin和debug文件夹，并尝试重新构建项目。 它起作用了，至少对我而言。 或者尝试清理解决方案并尝试重建它。 但是，当然，发布部分代码可能会更有帮助。
我遇到了一个非常类似的问题，发现已经为GAC安装了旧版本的程序集。 卸载该版本后，项目编译并正确运行。 因此，请检查GAC（ C:\Windows\Assembly ）以确保它没有列在那里。
我也遇到了同样的exception，虽然我的问题不同，但我的库中有一个方法最初看起来像这样：
public void WriteMessage(string msg) { ... }
并且有一些新的修改请求，它变成了：
public void WriteMessage(string msg, int code = 100) { ... }
之后，我用新编译的二进制文件更新了使用这个库的项目，它开始抛出这个exception。
经过多次尝试，没有任何工作，甚至项目清理，重建，删除和重新添加引用，然后我尝试修改项目的方法调用：
... library.WriteMessage('hello!'); ...
至：
... library.WriteMessage('hello!', 100); ...
然后编译了项目，它解决了问题，之后我又将其改回：
... library.WriteMessage('hello!'); ...
现在它神奇地修复了所有内容，也许某些缓存的元数据留在某处未被更新，并且通过改变调用该方法的方式，以某种方式清楚地提醒它该方法的签名是不同的，但并没有那么不同。
希望这可以帮助遇到我遇到的同样问题的人。
看，这一定是最奇怪的原因，但经过一整个上午尝试一切，从头开始重建项目等，我注意到唯一可以避免问题的是我的库有不同的程序集名称。
我从脑海中得到了一个可怕的建议，我已经在GAC中安装了以前的dll版本，但我已经检查过了，此外，这绝不是我的意图。 但是跟着那条路径我发现了这个dll（以及项目中的所有其他人！）安装在C：\ Program Files（x86）\ Microsoft Visual Studio 10.0 \ Common7 \ IDE !!!!!!
啊啊！ 猜猜我是唯一一个搞砸了这一点的人，但我不知道为什么，我只是觉得我可以在别人如此不幸的遥远可能性中让别人感到沮丧！
当我运行带有nuget包托管dll的应用程序时，我遇到了同样的问题。 事实certificate，当我尝试从nuget包管理器更新dll时，它没有更新我的测试层。 我建议你查看你所指的dll版本。 转到VS中的ObjectBrower并检查dll并检查引用位置：确保您指的是最新的dll。
解决方案中的两个项目：项目A和项目B.两个项目都使用nuget包“DoStuff”，但不同版本的DoStuff包：
- project A引用DoStuff的1.1版。
- 项目B引用DoStuff的1.0版本。
- 项目B参考项目A.
版本1.1有一个新方法，在项目A中使用。当项目B使用项目A时，你会得到这个MethodNotFoundException，因为项目B的DoStuff版本不知道A正在讨论什么项目。
为了防止这种情况，如果项目使用相同nuget包的不同版本，我们就会进行unit testing。 一个相对简单的门挡在过去几年中为我们带来了几个令人头疼的问题。
当我将Action作为参数时，也会发生错误。 我传递了一个方法而没有将它包装在一个新的Action（..）中。
DLL有这个：
public bool ShowMyForm(bool showConnectionWindow, Action onCloseNotify) {...}
测试应用程序称为DLL，如下所示：
private void onFormClose() { MessageBox.Show("Form Closed"); } private void ShowForm() { mydll.ShowMyForm(true, onFormClose ); // bug here: wrap in Action }
当我改变呼叫时
mydll.ShowMyForm(true, new Action(onFormClose) );
exception消失了。 exception文本只是误导 – 方法就在那里，但参数的类型给出了运行时exception。 太糟糕了，它在编译时没有被提取。
我遇到了同样的问题，然后我将方法名称更改为其他名称，并更改了引用。 然后它很棒。 我不知道问题是什么，但在某些情况下更改方法名称时，看起来有一个错误并不适用于整个系统
我的案子与其他案件略有不同; 但它可能对某人有所帮助。 我刚刚在库中添加了一个可选参数，并使用库从GUI获取该消息。
问题是由GUI引起的，其中一个库引用了相同的库，但其中一个库不是最新的。
我有
- GUI引用LibA和LibZ
- LibA引用LibZ
所以我刚刚删除了LibA和GUI的所有“bin”和“obj”文件夹，确保在两者中都有更新的LibZ DLL，并且一切都恢复了。
在我的情况下，我部署到.NET 3.0 PC（Windows XP），而编译目标是.NET 3.5。 我真的很想知道为什么没有更基本的警告……
问题一直是从System.Runtime.Serialisation使用DataContract。
我遇到了同样的问题，即使我清理并重建了没有帮助的解决方案。 当我发布应用程序时，旧版本的DLL在bin文件夹中。 所以我在assemblyinfo文件中更改了程序集版本。 最后它的工作。 bin文件夹中提供了新版本。
当我将解决方案复制到另一台机器上的其他位置时，我遇到了这个问题。 Build文件夹只需要更改。 不要问我原因，但解决方案是在build文件夹中构建的（我们将这个文件夹称为A）然后将旧的副本从文件夹B复制到文件夹C.在运行时它找不到我的最新代码，因为它是查看文件夹C中的旧版本。在“构建”选项卡中的解决方案的属性中，我将“输出路径”更改为文件夹B.然后在文件夹B中构建了最新版本，将其复制到文件夹C并再次运行。
我不知道的是为什么我们首先有文件夹C. 我有一个codedUI测试解决方案，文件夹C是“C：\ Users \\ Documents \ MyCodedUISolution \ TestResults \ _ 2017-04-20 11_31_29 \ Out”。 这是用于什么以及为什么它被创建，我不知道，但是如果旧的代码被复制到这里因为您更改输出路径或您移动解决方案而不将输出路径更改为所需的那么您就遇到了麻烦。
在我的例子中，我已经将方法的返回类型从IQueryable更改为IEnumerable。
我重新编译并上传了包含该方法的DLL，但没有使用调用该方法的代码的DLL。 因此调用DLL仍然期望具有先前返回类型的方法并且无法找到它。
我无法用任何建议的答案修复它。 我找不到任何旧版本的自定义程序集。 我用“Everything”工具随处搜索。 在调试模式下，它显示了正确的程序集版本，但仍然无法找到该方法。
在.csproj文件中启用自动绑定为我修复了它
true
我的目标是在我的项目中使用.NET Framework 4.5包。 如果项目中的所有程序包都以.NET Framework 4.5.1或更高版本为目标，则不需要上述设置。
这可能是一个迟到的回应：但一种可能的补救方法是清理Temporary ASP.NET文件夹：即，C：\ Windows \ Microsoft.NET \ Framework \ vX.X.XXXXX \ Temporary ASP.NET Files
删除与您的网站相关的文件夹，然后重建解决方案。