咨询：保留部分Classic ASP，用ASP.NET MVC/Core改造旧应用的可行性

当然可以！完全不用一次性重写整个Classic ASP应用——这种渐进式的迁移方式非常适合时间和预算有限的场景，还能让你边做边学习ASP.NET MVC/Core。下面给你梳理几个落地性强的方案：

1. 同一IIS站点下混合部署 #

你可以在同一个IIS站点中同时保留Classic ASP文件（.asp）和ASP.NET MVC/Core项目：

• 新增页面直接用ASP.NET MVC/Core开发，路由规则由MVC/Core的路由系统处理；
• 旧的Classic ASP页面继续保持原样运行；
• 用IIS的URL重写模块来区分请求：比如把所有/new/开头的请求转发到ASP.NET应用，其余请求交给Classic ASP处理。

⚠️ 注意：Classic ASP和ASP.NET的默认会话（Session）是相互独立的，如果需要共享用户状态，可以考虑：

• 用数据库存储会话数据，让两者都从数据库读取；
• 把必要的用户信息存在Cookie中（注意加密），两边都解析Cookie获取信息。

2. 逐步迁移核心逻辑到.NET类库 #

把Classic ASP里复杂的业务逻辑（比如数据处理、计算逻辑）抽离出来，写成C#/VB.NET的类库（.NET Framework或.NET Core都可以），然后让Classic ASP通过COM调用这个类库，或者让ASP.NET MVC/Core直接引用：

• 先把新增功能的业务逻辑用.NET实现，再扩展到旧功能的迁移；
• 如果用.NET Core类库，Classic ASP可以通过调用ASP.NET Core Web API的方式来使用这些逻辑（用VBScript的XMLHTTP对象发送请求）。

这种方式能逐步解耦Classic ASP的业务代码，让你慢慢熟悉.NET的开发模式，同时不影响现有功能。

3. 新增页面用ASP.NET MVC/Core，旧页面做跳转/反向代理 #

如果不想在同一个站点部署，也可以把ASP.NET MVC/Core应用部署在独立的IIS站点：

• 用户访问旧系统的新增功能入口时，直接跳转到ASP.NET MVC/Core的对应页面；
• 两者共用同一个数据库，保证数据一致性；
• 或者用反向代理工具，让旧站点的特定路径请求转发到新应用。

4. 视图层兼容改造（仅限ASP.NET MVC） #

如果你选择ASP.NET MVC（而非Core），可以尝试用工具让Classic ASP的视图（HTML+VBScript）和MVC视图做有限兼容，不过这个方案局限性较大，更适合小范围页面的快速改造。

总结 #

最推荐的是方案1+方案2的组合：先在同一站点混合部署，新增功能用ASP.NET MVC/Core开发，同时逐步把旧的业务逻辑迁移到.NET类库。这种方式既能快速上线新功能，又能慢慢完成系统迭代升级，完全匹配你的时间和预算要求。

内容的提问来源于stack exchange，提问作者mak101