以NTFS联结作为Web根的IIS 7站点可能有哪些缺点？

13

我正在尝试提出一种以尽可能少的站点干扰来部署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的想法，因为可能会发生不必要的应用程序域或应用程序池搅动，但我对此一无所知在负载下更改站点的配置物理路径时会发生什么情况）

需要明确的是，我唯一关心的是最终用户的体验。我的目的是避免对他们造成干扰，而不是给我带来麻烦。

iis ntfs symbolic-link version-control junction

— Jayrdub
source

1

重置Web根目录。这样一来，任何回收（不要以为会发生）和应用程序池重新启动都是：a）可能不是“不必要的”，并且b）帮助工作进程维护有关其内容和缓存状态的现实想法。当然，这是一个聪明的解决方案，但是聪明很少意味着稳定。找出大多数人的工作，然后再做。

— TristanK 2011年

这是一个很好的问题，我一直在寻找答案。我所见过的只是在负载平衡器下的滚动部署（我没有），或者是简单的文件复制/ svn到webroot（我不喜欢）。

— jayrdub's

1

因此，请尝试首先重新定位Web根目录。

— TristanK 2011年

3

一种以尽可能少的站点干扰来部署ASP.NET代码的方法。

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

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

— 乔尔·科尔
source

该网络操作将导致站点的工件长时间处于歧义状态。那就是我想避免的确切情况。我试图消除webroot下的程序集具有不同版本的时间。

— jayrdub's

1

不必担心“涉及的额外工作和脚本”，我们是完全自动化的

— jayrdub 2011年

我想是公平的，干扰和需要的工作并不是一回事

— Mark Henderson

我指的是对我网站的最终用户造成的干扰

— jayrdub 2011年

2

我在网络根目录后面创建了一个名为 _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中表达这一点，所以如果有人对此有任何反馈，请告诉我们！

— 格雷格
source

0

这将不起作用，因为IIS可能认为web.config已被另一个程序更改。IIS可能会抛出System.Configuration.ConfigurationErrorsException异常。我建议编写某种脚本来仅更改站点的主目录。

— 科里
source