asp.net - 为什么我不应该将我的 asp.net 网站或 webapp 部署到 IIS 中域的根目录？

Question

几年前，我记得我在一个域情况下处理多个站点时遇到了困难，其中一个站点被放置在根目录中。

当时我阅读了一篇权威文章，清楚地向我解释了为什么这是一个坏主意，我记得是级联 web.config 问题是主要原因(迫使您取消声明与子项目本质上不相干的冲突引用项目)。从此以后，我总是在自己的虚拟路径中部署任何网站，使用根目录中的单个重定向指向默认网站。

我似乎再也找不到那个权威引用，从那时起部署考虑可能已经改变。

这种情况的优点和更有可能的缺点是什么？我之所以问，是因为与我合作的一家公司不赞成以这种方式分离部署，我认为这不是一个好主意。

Answer 1

简短回答:隔离 . IMO 在不隔离它们的情况下托管不同的网站/网络应用程序的好处是没有意义的。

长答案:

优点:

使用没有特定绑定(bind)(即别名)的单个端口:如果您
无权访问网站绑定(bind)，它很有用

快速部署和动态网站创建:您可以创建一个新的
没有在 IIS 端声明的子站点

共享设置:将网站基础设置应用于所有子站点
(文档、mime 类型等...)

缺点:

应用程序池隔离 :没有身份隔离，没有工作进程
隔离、无故障/恢复隔离等...(超时、内存限制等...)

AppDomain 或生命周期隔离 :你必须照顾你的网站 AppDomains。如果您共享相同的 AppDomain，您将共享相同的生命周期:如果
AppDomain 被卸载，该 AppDomain 下的所有网站都将关闭并重新加载(即，如果您触摸 AppDomain web.config)

架构隔离 :一些Web应用程序开发需要一些
在 IIS 端进行调整，如果您只是调整 IIS 池或网站
对于一个应用程序，它对所有网站都有影响。例如，我考虑 32 位和 64 位设置或通配符映射。

代码与安全隔离 :在同一个工作进程和/或 AppDomain 中运行的应用程序对跨应用程序访问/黑客/攻击的保护较少。您必须更加警惕，以确保来自应用程序的信息无法被其他人读取。

审核 : 审核网站事件和失败可能会更加困难。

Web 应用程序隔离一直是互惠环境的目标，以保护应用程序之间的相互隔离。

从 IIS 7 开始，应用程序池隔离在“应用程序池标识”中走得更远: http://www.adopenstatic.com/cs/blogs/ken/archive/2008/01/29/15759.aspx

我也找到了这篇文章: http://searchsecurity.techtarget.com/tip/Web-application-isolation .

您还应该查看 SharePoint 网站集体系结构。想法是这样的: http://blogs.msdn.com/b/sgoodyear/archive/2011/11/18/9848865.aspx .