当推送更新的页面时，自动编译的asp.net站点上的随机401错误

Question

我们有一个部署在多个IIS服务器上的asp.net网站。该站点是按需编译的，而不是预编译的Web应用程序。

通常情况下部署很顺利，但我们不时会在其中一台服务器上为其中一个已部署的页面获取401。关于哪个页面或哪个服务器除了它通常是更高的流量页面之外没有什么特别的。

解决此问题的唯一方法是再次部署同一页面。

ACL在文件本身上看起来很好，所以想到在重新编译特定页面时Temporary ASP.NET Files文件夹中存在文件锁定问题。

有没有人见过这个或有任何建议如何避免这个？

注意：自从我们转移到.net 4.0

以来，这似乎只发生了

据我所知，我们收到了资源ACL http://support.microsoft.com/kb/907273拒绝的401.3 但我无法证实这一点。

Answer 1

这些类型的锁一直是实时站点部署的问题。难以复制的原因是因为在服务器上复制/编译时你是中等请求，这最终会让IIS感到困惑。

我们在4层架构上运行Blue/Green deployment策略，该架构在顶层有4个服务器的网站。由于部署引入的体系结构的复杂性，我们需要一种部署方式，而不会干扰“实时”站点的任何流量。根据Fowler的建议，但不是以同样的方式，我们想出了一个解决方案，这意味着我们在每个服务器上有2个站点（蓝色和绿色，或者在我们的案例中站点A和站点B）。实际站点具有适当的主机头，一旦我们部署并测试到非实时站点，我们就会翻转2个站点的标题，以便曾经生活的内容现在是非实时站点，反之亦然。其结果是，可以在数小时内完成并且具有最高置信度的强大部署。

这当然会使您的配置和部署稍微复杂化，但值得付出努力。我想有点不用说你想编写部署和主机头交换的脚本。

Answer 2

当我部署到服务器时，我将网站关闭了一分钟（或者部署需要多长时间） - 在此期间它可能会因为重新编译页面而失败，因此它不会太多。您可以通过在应用程序的根目录中创建一个名为app_offline.aspx的文件（它需要至少512个字符长度），然后创建该文件后，您可以复制文件夹中的资源，因为知道不存在任何锁定问题。然后在复制完成后删除app_offline文件。

Answer 3

对于那些想要在没有这些问题的情况下实现.net网站部署的人，可以选择将新网站文件首先复制到新文件夹（而不是活动网站）。然后，只需在完成所有复制后将IIS更改为指向新文件夹。

这可以在一个服务器环境中为我们这些人在更有限的资源上完成，而不是每个网站有多个服务器。

在我的工作中，我们编写了power shell脚本来部署网站。 powers shell脚本创建一个带有时间戳的新目录，在那里复制新部署，然后告诉IIS将网站指向新目录（使旧目录“孤立”但仍然存在）。

如果我们真的搞砸了，我们可以简单地通过将IIS指回上一个日期戳目录来恢复。否则如果一切正常，我们可以删除旧文件夹。

这项技术很有效，因为在使用文件时，您永远不会在文件上进行书写。然而，它仍然导致零停机时间。您将看到的唯一效果是在您更改代码隐藏或程序集时发生的正常.net“热身”。

Answer 4

我有几个答案暗示要部署的新环境。这是我们长期考虑的问题，但是当我们经常只部署一个或两个文件而没有问题时，很难证明额外的工作是合理的。我真的更感兴趣的是找出实际发生的事情和原因。

就解决方法而言，这可能听起来很明显，一个简单的app_pool循环解决了权限问题，并且比测试问题和重新部署文件要容易得多，直到问题消失为止。