您是否应该对 ASP.NET 站点进行编码，以便它们可以存在于 VDIR 中？

Question

在 Visual Studio Web Server 之前的日子里，我们会在 IIS 中托管我们的本地开发人员。如果您有 IIS 的工作站版本，这意味着只有 1 个网站。如果您在多个网站上工作怎么办。简单：在 VDIR 中创建它们，例如http://localhost/ProjectA，http://localhost/ProjectB。

生活在 VDIR 中听起来并不难。确保所有图片/CSS/链接都是相对路径，经常使用“~”。听起来是个好习惯。硬编码图像等，因此它们仅在从“/”提供应用程序时才有效，这听起来像是一种不好的做法。

在您必须建立链接的任何地方都有一些细微差别（大多数情况下不常见）：

• 例如；产品：http://prodserver.com/images/up.jpg -> 开发：http://localhost/ProjectA/images/up.jpg
• 电子邮件中的链接/图片
• flash/javascript/silverlight 从服务器请求包含图片链接的数据
• 指向 PayPal IPN 的完整链接（页面 paypal 也会发布他们的响应）

所以.. 你这样做吗？优点缺点？我错过了其他任何问题吗？

Answer 1

我总是避免使用硬编码的路径、URL 等，除非有特定的理由不这样做。事情不可避免地会发生变化，并且总是会从您的开发站点跳转到生产站点。

通常最令人讨厌的部分是需要引用其他路径的可重用客户端行为，而它们本身可以在应用程序目录结构的页面中重用。

我喜欢响应“globalvars.ashx”（或类似的东西；有很多方法可以处理这个）的想法处理程序，它动态地发出（并允许缓存）有关全局应用程序属性的属性。

假设负责 globalvars.ashx 的处理程序写出这样的结果：

String.Format("var ApplicationProperties = {{ RootPath:{0} }};", Request.ApplicationPath);

理论上，您的 JS 行为可以在任何时候通过 ApplicationProperties.RootPath 引用该属性对象。

Answer 2

简而言之，是的。不这样做的弊大于利。我实际上认为您的前两点也可以通过使用应用程序相对路径（“~”）来缓解，但是，一些场景，如“集成级”（如 PayPal）可能确实很棘手。

但归根结底，如果您需要将应用程序托管在虚拟目录中，如果您从一开始就没有将应用程序编码为对 vdir 友好，那么您几乎肯定会遇到问题。我知道我有。

一些背景/上下文：无论如何，我当前的生产环境几乎总是一个虚拟目录，所以我这样做是必要的。当应用程序被创建为根级网站时，我从来没有遇到过问题。如果反过来，肯定不会是这样。