如何将传统VB.NET WebService迁移到.NET Core实现AWS Lambda或Docker部署

首先澄清认知误区：.NET Core/.NET 5+ 官方正式支持VB.NET，支持周期和C#保持一致，完全可以用VB.NET开发跨平台的ASP.NET Core应用，部署到AWS Lambda、Docker等平台。

方案1：VB.NET直接迁移到ASP.NET Core #

• 实现逻辑：新建VB.NET的ASP.NET Core Web API项目（优先选择.NET 6、.NET 8这类LTS版本），剥离原有ASMX服务中[WebMethod]标记的业务逻辑，将其改写为API控制器的Action方法，入参、出参、核心业务代码基本可以直接复用。如需部署到AWS Lambda，只需引入Amazon.Lambda.AspNetCoreServer NuGet包配置入口即可；如需Docker部署，直接使用微软官方提供的ASP.NET Core VB运行时基础镜像编写Dockerfile打包即可。
• 优势：无需改动核心业务逻辑，迁移成本最低，出现逻辑bug的风险最小，不需要精通VB.NET只要能看懂代码即可完成调整。
• 劣势：VB.NET的生态资料、开发人员可选范围比C#窄，后续长期迭代的维护成本略高。

方案2：全量C#重写 #

• 实现逻辑：先梳理原有ASMX服务所有接口的请求参数、返回结构、业务逻辑规则，新建C# ASP.NET Core Web API项目，逐一把VB.NET实现的业务逻辑翻译为C#代码，完成开发后做全量接口对比测试，确保新API和原有WebService行为完全一致。部署到Lambda、Docker的生态支持对C#更完善，相关配置更简单。
• 优势：C#生态成熟，后续功能迭代、问题排查的效率更高，长期维护成本更低。
• 劣势：人工翻译代码耗时久，容易在翻译过程中引入逻辑错误，需要投入较多的测试资源保障正确性。

方案3：半自动工具转换+人工校验 #

• 实现逻辑：使用官方.NET升级助手对原有VB.NET Framework项目做自动升级尝试，工具会自动完成大部分语法转换、项目结构调整、ASMX到ASP.NET Core的初步适配，转换完成后人工校验业务逻辑，修复工具转换错误的部分即可。如果仅需要转换业务代码片段，也可以用代码转换工具做单方法转换后人工核对。
• 优势：比完全人工重写节省大量重复劳动的时间，迁移效率更高。
• 劣势：工具无法覆盖所有老旧VB.NET语法和.NET Framework专属API的转换场景，需要投入时间修复转换后的错误。

选型建议 #

• 如果该API后续迭代需求极少，仅需要满足跨平台部署要求，优先选择方案1，上线最快风险最低。
• 如果该API需要长期迭代更新新功能，优先选择方案2或方案3，长期维护成本更低。
• 时间紧张且有转C#需求的情况下，可先尝试方案3的自动转换，能大幅减少迁移工作量。

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