有人说.net在国内的氛围越来越不行了，看博客园文章的浏览量也起不来。是不是要转java呢？ 没有必要扯起语言的纷争，java也好c#都只是语言是工具，各有各的使用场景。以前是c#非开源以及不能在linux上使用，没有被互联网公司考虑，但它仍然有它的用途。这几年国内互联网公司进入蓬勃发展时期，所有才有这样的趋势。但并不代表c#不能做互联网应用，可以说在接下来的一年内.net core将会成为一个很好的趋势，结合容器以及微服务架构会成为互联网公司另一个比较好的选择。
作为现在在用.net的公司，如果有机会可以考虑与时俱进，在真实项目中将.net core用起来。
我们首先来看看asp.net core有哪些优势？
- 跨平台：可以部署到linux服务器上
- 内置一套对云和部署环境非常友好的配置模块
- 内置依赖注入
- iis或者kestrel（或者其它自定义）
- 轻量级、高性能、模块化的http处理管线
- .net core 是开源的，并且基于nuget发布。 这让我们有了更大的空间去改造和扩展它
- 更易于现代化的项目开发，比如面向容器，微服务架构，对devops更友好
如果你看到这段文字，说明您正使用rss阅读或转自《一棵树-博客园》，原文地址：https://www.cnblogs.com/atree/p/netcore-transfer.html
公司的决策层为什么要做这样的选择？
- 降低成本，提升效率
- 提升公司的技术品牌
- 更好的留住和培养现有的开发团队，以及招募到更好的开发者
在同等用户规模的情况下，选择 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 ()
}
iisintegration其实是将iis做一个反向代理，aspnetcoremodule的任务就是将请求转发给kestrel。
当然你也可以选择用nginx或者 apache来做反向代理，来实现asp.net core在linux上的部署。这里有一篇不错的实践贴（将asp.net core应用程序部署至生产环境中（centos7）
在我们的最小升级方案里面，部署到iis是在生产环境中使用asp.net core是最易实现和成本最低的一种。剩下的，等开发人员对asp.net core掌握的比较牢固，对linux的运维也有一些经验之后可以再尝试往linux上迁移。
新老项目交互的问题
除了刚起步没有任何历史负担的公司，我们大多数所在的公司都处于老系统维护和新系统开发并行的情况。在新系统的开发过程当中，少不了要与老系统打交道。比如最常用的一些其它系统的数据访问，就会面临是重写好，还是调用老系统中的代码比较好的问题。
这里没有明确的答案，取绝于当前业务的发展和我们所拥有的时间来决定 。人和时间够整个系统重写都可以，不够的话我们也只能采用系统嫁接的方式。
根据老系统的结构主要分两种：
- 前后端未分离，就是一个大的网站
- 前后端已分离，前端和移动端直接调用asp.net web api
第一种情况会给系统以及开发增加的复杂度是： 本地代码访问变成api访问之后的引发的问题，这也是多数团队在做服务化时首先遇到的问题。
- 增加额外的api访问代码
- 增加debug的复杂度，不好找原因
第二种情况，已经api化只是没有做拆分。那我们新写的asp.net core api 可以直接被访问。这里的问题是要解决认证授权的问题包括（从客户端到core api，以及从core api到原来的web api)
注：这种方案应该禁止从老的asp.net web api访问 asp.net core的项目。最后应该是停止维护老项目，所有代码在新的asp.net core上进行开发。 proxy的设计应该按照新的框架来设计，实现可以嫁接老的api，做好被新代码替换掉的准备。
