我們首先來看看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() }

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，做好被新代碼替換掉的準備。

關于ASP.NET Core認證與授權相關可以參考我寫的下一篇文章 ASP.NET Core集成現有系統授權?

原文地址：http://www.cnblogs.com/cgzl/p/7795121.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的向ASP.NET Core迁移的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。