我试图想出一种尽可能less的网站干扰部署ASP.NET代码的方法。 一个想法是build立一个NTFS路口c:\www\example.com在哪里提供服务
c:\www\example.com -> c:\www\example.com_r1234
然后，在部署新代码时，将其复制到c:\www\site.com_r1235 ，并将路口redirect到
c:\www\example.com -> c:\www\example.com_r1235
所以我的问题是什么影响这可能对IIS中的当前请求？ 从IIS对变化的反应（如果有的话）来看，还有什么其他的缺点呢？ 对于网站的最终用户来说，这是否像我希望的那样无缝？
（我曾经考虑过通过命令行来改变站点的web根目录，但是我真的不喜欢重新configurationIIS的想法，因为可能发生的任何不必要的应用程序域或应用程序池混乱，但我不知道很多当站点的configuration物理path在负载下发生变化时会发生什么情况）
要清楚的是，我唯一关心的是我的最终用户的体验。 我的目的是为了避免他们的干扰，对我来说不方便。
一种尽可能less的站点干扰部署ASP.NET代码的方法。
看起来这个目标和你提出的解决scheme是不一致的，因为你现在有一大堆额外的工作或脚本涉及到每个部署。
我所看到的一件事是在生产服务器上安装一个svn客户端，生产站点是源控制树上特定位置/分支的签出副本。 这样至less你只需要更新更改文件的新部署。
我在我的web根目录下创build了一个名为_images的文件夹
C:\DEV\_IMAGES
然后复制一堆gif文件到它。 然后我使用我的根创build一个NTFS符号链接
C:\DEV\PROJECT\ROOT mklink /D webimages ..\_images
在Visual Studio 2010中，我“显示所有文件”然后刷新…并将新的“webimages”包含到我的项目中。 我现在可以指向…
img src='webimages/icon.gif'
当我运行应用程序，它也可以在我的本地机器上正常工作。
我不知道，如果它在真正的服务器（IIS 7）上工作，直到基础设施得到处理，有没有人知道为什么这不会在生产工作的任何问题？
我觉得只要权利在那里，它应该如何，如果是这样，简化Web应用程序之间共享文件夹（所有types）的好方法。
我还没有尝试在TFS中expression过，所以如果有人对此有任何反馈，请告诉我们！
这将无法正常工作，因为IIS可能认为web.config已被另一个程序更改。 IIS可能会抛出一个System.Configuration.ConfigurationErrorsExceptionexception。 我会build议编写一些脚本来改变网站的主目录。