向ASP.NET Core迁移

我们首先来看看ASP.NET Core有哪些优势？

跨平台：可以部署到Linux服务器上
内置一套对云和部署环境非常友好的配置模块
内置依赖注入
IIS或者Kestrel（或者其它自定义）
轻量级、高性能、模块化的Http处理管线
.NET Core 是开源的，并且基于nuget发布。这让我们有了更大的空间去改造和扩展它
更易于现代化的项目开发，比如面向容器，微服务架构，对DevOps更友好

公司的决策层为什么要做这样的选择？

降低成本，提升效率
提升公司的技术品牌
更好的留住和培养现有的开发团队，以及招募到更好的开发者

在同等用户规模的情况下，选择 Linux的服务器比Windows Server的性价比更高。在一个产品的整个实现与运营生命周期当中，编码只占了很小的一部分，还有开发与测试环境的初始化与维护，测试与集成，线上环境部署与运维这都会占用不少的时间，通过自动化可以大幅度的减少这些时间。而在.NET Core实现跨平台之后，让自动化的门槛降到最低。你不再需要一个资深的架构师或者专业的DevOps才可以实现，一个有经验肯学习的开发者足以应付。

如何来做升级和改造？

说到真实产品的技术升级和改造，不伤筋动骨，不可能完成。

老系统是 asp.net Web Form
老系统用的是WCF之类的项目
老系统是asp.net MVC或者WEB API

由于对system.web的重依懒，将Web Form迁移到ASP.NET Core几乎是不可能。如果Web Form项目使用了服务器端控件，那已经可以放弃往下走，可以尝试开始一个新的项目逐步替换老的项目。如果没有使用服务器端控件，用handller在返回数据，则可以考虑先将Web Form的项目进行前后端分离或者API 分离，在视图层逻辑不变的情况下重写后端逻辑部分。当然这个代价也不小，所以转型和升级需要准备的事情有很多。

WCF暂时还不能支持.NET Core，虽然微软已经启动WCF的开源和并入.NET基金会，但短时间内WCF迁移到.NET Core还有一段时间。所以如果对WCF依懒比较重，最好暂时不要考虑升级。一些复杂的MVC和WEB API的项目如果依懒比较多，要升级起来也不是一件容易的事情。目前比较可行的方案，还是在新项目上使用.NET Core来实现。

最合适的步骤是先在一些新的项目上采用ASP.NET Core来开发。就语言特性本身来说ASP.NET Core的变化不大，学习成本也不高。但是生产环境不是随便玩的，要从无到有，过程比较艰难，这也是很多小公司到现在还没有在生产上用上.NET Core人原因之一。只有开发人员干着急，我们什么用.NET Core 呢？

与其等待你的总监做这个决定，不如自己先干起来。如果不能从无到有，那么我们可以在原来的系统上换部件：也就是我们的最小升级方案，将.NET Core部署在IIS上。

最小升级方案：将ASP.NET Core部署在IIS上

关于如何把ASP.NET Core的网站或者API部署到IIS上，网上已经有比较多的介绍，可以参考这里。主要是需要先下载一个ASP.NET Core的模块安装之后再进行简单的配置，新手比较容易忽略。如果你的IIS模块里面没有AspNetCoreModule，说明没有安装这个ASP.NET Core模块，需要进行下载安装。

ASP.NET Core所有的项目都必须运行在Kestrel或者一个自定义的Web Server上。

在asp.net core 2.0时，采用默认的 WebHost.CreateDefaultBuilder().Builder() 得到的Host已将将 Kestrel和IISIntegration都添加进来。

public static void Main(string[] args){BuildWebHost(args).Run();
}public static IWebHost BuildWebHost(string[] args){    return WebHost.CreateDefaultBuilder(args).UseStartup<Startup>().UseKestrel(options =>{options.Listen(IPAddress.Loopback, 5000);options.Listen(IPAddress.Loopback, 5001, listenOptions =>{listenOptions.UseHttps("testCert.pfx", "testPassword");});})
.UseIISIntegration()
.Build()
}