将 NTFS 结点作为 Web 根的 IIS 7 站点可能存在哪些缺点？

Question

我试图想出一种方法来部署 ASP.NET 代码，同时尽可能减少站点干扰。一种想法是建立从 NTFS 连接点提供服务的站点，c:\www\example.com其中

c:\www\example.com -> c:\www\example.com_r1234

然后，当部署新代码时，它会被复制到c:\www\site.com_r1235并且连接点重定向到

c:\www\example.com -> c:\www\example.com_r1235

所以我的问题是这可能会对 IIS 中的当前请求产生什么影响？从 IIS 对更改的反应（如果有）的角度来看，这可能还有哪些其他缺点？对于网站的最终用户来说，这会像我希望的那样无缝吗？

（我曾考虑通过命令行更改站点的 Web 根目录，但我真的不喜欢重新配置 IIS 的想法，因为可能会发生任何不必要的应用程序域或应用程序池流失，但我不太了解在负载下更改站点的配置物理路径时会发生什么）

需要明确的是，我在这里唯一关心的是我的最终用户的体验。我的目的是为他们避免干扰，而不是为我提供方便。

Answer 1

一种在尽可能减少站点干扰的情况下部署 ASP.NET 代码的方法。

似乎这个目标和您提出的解决方案不一致，因为现在每个部署都涉及大量额外的工作或脚本。

我看到的一件事是在生产服务器上安装 svn 客户端，而生产站点是源代码控制树上特定位置/分支的签出副本。这样至少您只需为新部署更新更改的文件。