情况是我对一个类进行了一个小错误修复，所以他们只想部署受影响的dll。他们停止了IIS，用我给他们的新网站替换了网站iis目录的/ bin文件夹中的dll，然后再次启动iis。有多个服务器，但他们只是在一个服务器上进行了尝试。他们仍然在相关服务器的事件日志中看到相同的错误。查看堆栈跟踪，我可以告诉它正在运行旧的DLL。
他们检查了GAC，但没有看到它。
我用反射器检查了dll以验证我给了他们正确的新dll。
这是一个asp.net 2.0网站，服务器是2003.我不知道它最初是如何部署的，但它在C：\ Windows \ Microsoft.NET \ Framework64 \ v2中有一个旧dll的副本。 0.50727 \ Temporary ASP.NET Files \ NAME_services ################## assembly \ dl3 ###################在D：\ xxxx \ Sites \ NAME \ Services \ obj \ Release中。它可以使用其中一个或构建旧的，甚至只是在内存中缓存它？
答案 0 :(得分：12)
压缩你的临时asp.net文件夹内容。不知道为什么更新没有自动编译。
答案 1 :(得分：3)
我们遇到了同样的问题，但是由于并发症很少，我们有许多网站，所以＆＃34;清除所有温度＆＃34;并重新启动IIS对我们来说不是一个好选择。因此，我们需要更加有选择性地强制刷新。
在我们的QA机器上，在...＆＃34; C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files＆＃34; 我做了一个文件浏览器搜索我们试图发布的部分文件名。该文件位于以下文件夹中： C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files \ root \ 4503212x \ ad95664x，所以我停止了应用程序池，删除了文件夹，重新启动了所有部署然后 - 太棒了！
但......我们在部署到生产时遇到了同样的麻烦，而且上面的工作没有用。
长话短说，QA应用程序池设置为＆＃34;启用32位true＆＃34;，但生产设置为＆＃34; False＆＃34;所以prod临时文件驻留在： ＆＃34; C：\的Windows \ Microsoft.NET \ Framework64 \ v4.0.30319＆＃34;而是（\ Framework64 \而不是\ Framework \）。
如果清除临时文件不起作用 - 请仔细检查框架，或者在C：\ Windows \ Microsoft.NET文件夹级别及以下查找要刷新的文件。你可能会感到惊讶。
答案 2 :(得分：0)
您不必停止IIS来部署更新，只需复制它们即可。
此外，如果他们只复制了DLL但你的修复程序是在.aspx文件中，那么它就不会显示出来。你应该真的进行全面部署。
答案 3 :(得分：0)
我们将项目源代码复制到了一个新文件夹，然后重新打开了解决方案。这以某种方式诱使Visual Studio不使用DLL的缓存版本。希望我们知道为什么这样做有效，但是那为我们解决了。