在现有应用程序中集成ASP.Net和（'经典'）ASP

Question

我想了解一下目前ASP应用程序托管ASP.Net部分的最佳方法。

我们有一个用（'经典'）ASP编写的大型复杂应用程序。

部分内容需要重写（遗憾的是重写所有内容并不切实可行），我们将使用ASP.Net。

（原始应用程序根本没有明确使用Session对象）

---

在我看来，有两种方法可以继续托管。

选项1 ：创建一个新的虚拟目录并从那里为应用程序的新重新开发部分提供服务 - 根据需要在ASP和ASP.Net之间前后链接

选项2 ：保留在现有虚拟目录中，并将整个ASP.Net应用程序放在当前ASP目录的子目录中

---

显然选项1 更“清洁”，我有一种温和的偏好，就是这样做。

但是从源代码管理和安装的角度来看，选项2 可能更简单。

• 在源代码管理中，您只需要一个“主干”，当需要进行更改时，这些主干将被检出。
• 在安装时（由Inno Installer在多个地点的专业技术人员完成），技术人员只选择一个虚拟目录，然后全部进入。

---

我有兴趣听听那些已经完成选项1 或选项2 （或者其他方式？）的人。

也有兴趣听听我忽略了这两种方法是否存在问题。

Answer 1

很久以前（大约3年前）我做了类似的项目，客户端有一个经典的ASP网站，他们想在ASP.NET中开发新的功能。我按照第二步，在root中创建了另一个VD，将所有文件放在那里。从源控制管理的角度来看，优势显而易见。但是我必须在我的设置中添加一个额外的步骤来为我的孩子VD设置ASP.NET版本以使其工作。另外，分享会话是另一个问题，我相信你没有遇到问题。

Answer 2

我做到了两个方面：

选项2：我有经典的ASP应用程序并在ASP.NET 2中使用相同的虚拟目录添加新页面，一切正常，但是你需要传递会话信息，我记得我使用了QueryString，你可以看一下{ {3}}。如果你不使用会话，那就更容易了。

选项1：在同一个ASP应用程序中，我使用主应用程序菜单中的链接调用ASP.NET应用程序（另一个虚拟目录）。但在这种情况下，它是逻辑上分开的部分。在这种情况下，我也通过QueryString传递了会话信息。

所以，总而言之，我认为这完全取决于这部分的逻辑与主应用的逻辑有多密切相关。

在选项1的情况下，调试很容易。 如果是选项2，您可以逐页替换。

Answer 3

从编码的角度来看，没有严重的影响。差异主要是美学。我倾向于选项＃2。它允许我选择为asp.net代码提供不同的IIS配置 - 以防我将来需要它。