我最近为一个客户开发了一个MVC应用程序，他们希望在同一台服务器上安装一些应用程序。
我更像是一个开发人员而不是服务器pipe理员，但我的本能是在IIS中build立一个新的站点，并拥有自己的子域绑定。
然而，客户端希望在默认站点中创build一个指向应用程序的虚拟目录。 所以，例如，你会有：
COMPANY.COM/APP1和COMPANY.COM/APP2
而不是：
APP1.COMPANY.COM和APP2.COMPANY.COM
这确实奏效了; 然而，它与标准HTTP标记中的相对URL冲突，这个问题很快就解决了。
将多个Web应用程序作为单独的网站托pipe在同一台服务器上还是作为默认网站中的虚拟目录更好？ 虚拟目录方法有什么缺陷吗？
我不是判断虚拟目录的方法，这对我来说是新的，我想确保它现在或将来不会造成问题。
我一直试图坚持个人网站的应用程序。 你可以更好地控制所有的东西，如果你正在运行ASP.NET，你不会遇到web.config级联的问题，这很容易。 另外，您对应用程序池有更细致的控制，并且实际上可以观察每个应用程序的性能。 这是所有的偏好。
无论如何，最好的答案可能是您在网站级别应用绑定，而不是应用级别。 因此，如果每个应用程序都需要自己的URL或SSL而不是非SSL，则您必须查看各个站点。
另外，正如你所提到的，你几乎必须考虑部署机制。 任何相对URL的使用都会破坏很多东西。
最后：为什么他们不想使用子域？ 如果你问我，它提供了很好的干净的RESTfulish资源分离。
我想说这取决于…应用程序是否非常相似，因为您可以在较高级别上进行单个更改，并将级联到每个虚拟目录，而不影响任何单个应用程序的function。 如果你有一个单独的网站为每个应用程序，那么你将需要分别pipe理每个网站的设置（证书，知识产权，端口等），这可能是一个头痛，如果有很多，但他们是完全独立的网站，所以设置不会影响另一个应用程序。 真正的工作是由工作进程/应用程序池来完成的，所以无论是哪种设置，您都可以为多个应用程序共享同一个应用程序池，或者为每个应用程序分别安装一个。