我们有一个部署在多个 IIS 服务器上的 asp.net 网站。该网站是按需编译的，而不是预编译的 Web 应用程序。
通常情况下，部署进展顺利，但时不时地，我们会在其中一台服务器上的某个已部署页面上收到 401 错误。除了通常是访问量较高的页面这一事实之外，哪个页面或哪个服务器没有什么特别的。
纠正此问题的唯一方法是再次部署同一页面。
文件本身的 ACL 看起来很好，因此我们认为，重新编译特定页面时，临时 ASP.NET 文件文件夹中存在文件锁定问题。
有没有人以前见过这种情况或有任何建议如何避免这种情况？
注意：自从我们迁移到 .net 4.0 后，这似乎才发生
据我所知，我们收到了 401.3 Denied by Resource ACLhttp://support.microsoft.com/kb/907273 http://support.microsoft.com/kb/907273但我无法证实这一点。
这些类型的锁一直是实时站点部署的一个问题。难以复制的原因是，在服务器上复制/编译时，您正处于请求中间，这最终会使 IIS 感到困惑。
我们经营一家蓝/绿部署 http://martinfowler.com/bliki/BlueGreenDeployment.html采用 4 层架构的策略，该架构在顶层有一个超过 4 台服务器的网站。由于部署架构的复杂性，我们需要一种在不干扰“实时”站点流量的情况下进行部署的方法。遵循 Fowler 的建议（但方式不完全相同），我们提出了一个解决方案，这意味着我们在每台服务器上有 2 个站点（蓝色和绿色，或者在我们的示例中为站点 A 和站点 B）。实时站点具有适当的主机标头，一旦我们部署并测试到非实时站点，我们就会翻转两个站点的标头，以便曾经实时的站点现在是非实时站点，反之亦然。结果是，可以在数小时内以最高的信心完成稳健的部署。
这当然会使您的配置和部署稍微复杂化，但这是值得的。我想这是不言而喻的，您想要编写部署和主机头交换的脚本。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
