我正在尝试找到一种尽可能少干扰站点的方式来部署 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 的想法，因为可能会发生任何不必要的应用程序域或应用程序池流失，但我不太了解在负载下更改站点配置的物理路径时会发生什么）
需要说明的是，我唯一关心的是最终用户的体验。我的目标是避免给他们带来干扰，而不是给我带来便利。
答案1
一种以尽可能少的站点干扰来部署 ASP.NET 代码的方法。
看起来这个目标和您提出的解决方案不一致，因为现在每次部署都需要做大量额外的工作或编写脚本。
我见过的一种做法是在生产服务器上安装 svn 客户端，生产站点是源代码控制树上特定位置/分支的签出副本。这样，至少您只需更新新部署的已更改文件。
答案2
我在 Web 根目录下创建了一个名为_images
C:\DEV\_IMAGES
然后复制了一堆 gif 文件到其中。然后我使用以下命令在根目录上创建了一个 NTFS 符号链接
C:\DEV\PROJECT\ROOT mklink /D webimages ..\_images
在 Visual Studio 2010 中，我“显示所有文件”，然后刷新...并将新的“webimages”包含到我的项目中。我现在可以指向...
img src='webimages/icon.gif'
当我运行该应用程序时，它在我的本地机器上也能正常运行。
在基础设施能够解决这个问题之前，我不知道它是否可以在真实服务器（IIS 7）上运行，有人知道为什么这在生产中无法运行吗？
我觉得只要有权利就应该这样做，如果是这样的话，这将是简化 Web 应用程序之间共享文件夹（所有类型）的好方法。
我还没有尝试在 TFS 中表达这一点，所以如果有人对此有反馈，请告诉我们！
答案3
这不会起作用，因为 IIS 可能认为 web.config 已被另一个程序更改。IIS 可能会抛出 System.Configuration.ConfigurationErrorsException 异常。我建议编写某种脚本来更改站点的主目录。