推送更新页面时自动编译的 ASP.NET 站点上出现随机 401 错误
我们有一个部署在多个 IIS 服务器上的 asp.net 网站。该网站是按需编译的，而不是预编译的 Web 应用程序。
通常情况下，部署进展顺利，但时不时地，我们会在其中一台服务器上的某个已部署页面上收到 401 错误。除了通常是访问量较高的页面这一事实之外，哪个页面或哪个服务器没有什么特别的。
纠正此问题的唯一方法是再次部署同一页面。
文件本身的 ACL 看起来很好，因此我们认为，重新编译特定页面时，临时 ASP.NET 文件文件夹中存在文件锁定问题。
有没有人以前见过这种情况或有任何建议如何避免这种情况？
注意：这似乎是在我们迁移到 .net 4.0 后才发生的，
据我所知，我们收到了 401.3 Denied by resource ACL http://support.microsoft.com/kb/907273 但我无法证实这一点。
We have an asp.net web site that is deployed on several IIS servers. The site is compile-on-demand as opposed to a pre-compiled web application.
Normally deployments go fine but every now and again we get a 401 for one of the deployed pages on one of the servers. There is nothing special about which page or which server apart from the fact that it's generally the higher traffic pages that it happens to.
The only way to rectify this is to deploy the same page again.
The ACLs look fine on the files themselves so the thought is that there is a file locking issue in the Temporary ASP.NET Files folder when the specific page is re-compiled.
Has anyone seen this before or have any suggestions how to avoid this?
Note: This only seems to have happened since we moved to .net 4.0
As far as I can tell we are getting a 401.3 Denied by resource ACL http://support.microsoft.com/kb/907273
But I have not been able to confirm this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这些类型的锁一直是实时站点部署的一个问题。难以复制的原因是，在服务器上复制/编译时，您正处于请求中间，这最终会使 IIS 感到困惑。
我们在 4 层架构上实施蓝/绿部署策略，该架构拥有超过 4 台服务器的网站在顶层。由于部署架构的复杂性，我们需要一种在不干扰“实时”站点流量的情况下进行部署的方法。遵循 Fowler 的建议（但方式不完全相同），我们提出了一个解决方案，这意味着我们在每台服务器上有 2 个站点（蓝色和绿色，或者在我们的示例中为站点 A 和站点 B）。实时站点具有适当的主机标头，一旦我们部署并测试到非实时站点，我们就会翻转两个站点的标头，以便曾经实时的站点现在是非实时站点，反之亦然。结果是，可以在数小时内以最高的信心完成稳健的部署。
这当然会使您的配置和部署稍微复杂化，但这是值得的。我想这是不言而喻的，您想要编写部署和主机头交换的脚本。
Those kinds of locks have always been a problem with live site deployment. The reason it's hard to replicate is because you are mid-request when copying/compiling on the server, and this ends up confusing IIS.
We operate a Blue/Green deployment strategy on a 4 tier architecture which has a web site over 4 servers at the top tier. Due to the complexity the architecture introduced for deployments, we needed a way to deploy without disturbing any traffic to the "live" site. Following Fowler's advice, but not quite in the same way, we came up with a solution that means we have 2 sites on each server (a blue and a green, or in our case site A and site B). The live site has the appropriate host header, and once we have deployed and tested to the non-live site, we then flip the headers of the 2 sites so that what was once live is now the non-live site, and vice-versa. The effect is, a robust deployment that can be done in hours and with the highest level of confidence.
This of course complicates your configuration and deployment slightly, but it's worth the effort. I guess it kind of goes without saying that you want to script both the deployment, and the host header swapping.
当我部署到服务器时，我会将站点关闭一分钟（或者无论部署需要多长时间） - 在此期间，由于重新编译页面，因此它可能会关闭，因此不会造成太大影响。您可以通过在应用程序的根目录中创建一个名为 app_offline.aspx 的文件（长度至少需要 512 个字符）来完成此操作，创建该文件后，您可以将资源复制到文件夹中，并且知道不会出现任何锁定问题。然后，当复制完成后，删除 app_offline 文件。
When i deploy to a server i bring the site down for a minute (or however long the deployment takes) - it may be down anyway during this time as pages are recompiled so it is not too much of a hit. You can do this by creating a file in the root of the app called app_offline.aspx (it needs at least 512 characters in length) once that file is created you can then copy the resources ot the folder knowing there will not be any locking issues. then when the copy is complete remove the app_offline file.
对于那些想要实现 .net 网站部署而没有这些问题的用户，一种选择是首先将新网站文件复制到新文件夹中（而不是活动网站）。然后，您只需在所有复制完成后将 IIS 更改为指向新文件夹即可。
对于我们这些资源较为有限的人来说，这可以在单个服务器环境中完成，而无需每个网站使用多个服务器。
在我的工作中，我们编写 Power shell 脚本来部署网站。 powers shell 脚本创建一个带有时间戳的新目录，将新部署复制到那里，然后告诉 IIS 将网站指向新目录（使旧目录“孤立”，但仍然存在）。
如果我们真的搞砸了，我们可以通过将 IIS 指向之前的日期戳目录来简单地恢复。否则，如果一切正常，我们可以删除旧文件夹。
这种技术很有效，因为您永远不会在使用文件时对其进行写入。然而，它仍然导致零停机时间。您将看到的唯一效果是每当您更改代码隐藏或程序集时发生的正常 .net“预热”。
For those that want to achieve a .net website deployment without these issues, one option is to copy the new website files into a new folder first ( not the active website). Then you just change IIS to point to the new folder after all copying is complete.
This can be done in a single server environment for those of us on more limited resources without multiple servers per website.
At my work we write power shell scripts to deploy websites. The powers shell script creates a new directory with a time stamp, copies the new deployment there, then tells IIS to point the website to the new directory (leaving the old directories "orphaned" but still there).
If we really messed something up, we can simply revert by pointing IIS back at the previous date stamp directory. Otherwise if everything tests ok, we can delete the old folder.
This technique works well because you are never writing over a file while it is in use. However it still results in zero downtime. The only effect you will see is the normal .net "warm up" that occurs anytime you change the code behinds or assemblies.
我有几个建议建议部署新环境的答案。这是我们长期考虑的事情，但是当我们定期仅部署一两个文件而没有出现问题时，很难证明额外的工作是合理的。我真的更感兴趣的是找出到底发生了什么以及为什么。
就解决方法而言，这在事后听起来可能很明显，简单的 app_pool 回收可以解决权限问题，并且比测试问题并重新部署文件直到问题消失要容易得多。
I had several answers suggesting a new environment to deploy. This is something we have been considering for the long term but it's hard to justify the extra work when we regularly deploy only one or two files without a problem. I was really more interested in finding out what is actually happening and why.
In terms of a workaround, and this might sound obvious after the fact, a simple app_pool recycle solves the permissions issue and is much easier than testing for the issue and redeploying the file until the problem goes away.