我昨天进行了网站部署，今天早上检查我的ELMAH日志时，我发现有几个“找不到方法”的例外情况。基本上，在这个部署中，我们从类的构造函数中删除了一些参数，并修改了所有调用代码，以便不传递额外的参数（如果我们传递的代码超过它可以采用的话，代码将无法编译......）
我的部署过程如下：
我们在下午12:30部署了什么，但直到晚上8点才看到第一个例外。我可以看到几个用户实际上经历了网站的“路径”，最终在晚上8点没有工作。
我检查了ASP临时文件夹的内容，我可以看到问题DLL的2个副本 - 一个是10月21日的版本，另一个是昨天的版本。我已经检查了GAC，但它不在那里。
我真的很困惑发生了什么。为什么它没有从其“bin”文件夹加载我的网站的DLL？为什么它会在一段随机的时间后恢复到旧的？
我从未在基于Webforms的网站上遇到任何此类问题。
Edit1 ：我已经通过停止应用程序池，删除临时ASP文件的内容然后再次启动应用程序池来解决此问题。
EDIT2 ： 我刚检查了ELMAH日志，昨天也发生了同样的错误。我不明白怎么做。我删除了临时ASP文件文件夹，发现没有DLL在那里
我再次查看该文件夹，10月20日的旧DLL就在那里。我不明白这是从哪里来的。我们在发布期间替换了有问题的DLL，同时停止了应用程序池并清空了Temporary ASP Files文件夹。
答案 0 :(得分：1)
您使用的解决方案令人困惑并且非常难以跟踪其问题，因为我们在使用DLL，配置文件等资源时具有继承层次结构....因此，您必须使用Visual Studio发布器工具来避免部署困难。 注意 ASP.NET MVC是“bin-deployable” - 在服务器上设置也没有什么太聪明 - 只需将通配符ISAPI过滤器指向ASP.NET
答案 1 :(得分：0)
我发现了这个问题：有一个插件文件夹，其中包含问题DLL的副本（旧版本比网站的 bin 文件夹中的最新版本）。它似乎随机选择运行这个DLL而不是最新的 - 在清除临时ASP文件后大约6个小时，问题将重新出现。由于现在更新正确的文件似乎已经自行排序，并且问题并非一夜之间发生。谢谢大家。
答案 2 :(得分：0)
在项目中添加另一个程序集的引用时，可以指定程序集是否应每次在本地复制它，或者是否编译项目。
参考文献＆gt;＆gt;程序集窗口的属性要么改变新版本路径的路径，要么设置＆＃34; 复制本地＆＃34;属性为False，这可能是导致此问题的原因，如果您不在本地复制程序集，则可能导致此问题。