微軟在推出來.net core的同時爲了方便一些原有的項目可以方便遷移，同時推出了Asp.net core。
Asp.net core其實就是仍然基於.net Full Framework（最低要求Framework 4.6.2）的項目, 但同時保留了.net core一些新的設置理念，比如Asp.net core默認使用Kestrel作爲Http請求的監聽器，而不是使用原來龐大的Https.sys。
Kestrel不僅僅是微軟下一代的跨平臺Http請求監聽器，同時還提供了比Https.sys更輕量級以及更快速的Http請求處理。
另除此之外，Asp.net core與原來的Web設計另一個最大的區別在於Asp.net core(及.net core)完全拋棄了原來的使用管道模式來接收以及處理HttpRequest。在Asp.net core中允許處理中間件(Middleware)來對所有的HttpRequest來進行請求，當請求被接收到時，Asp.net core會調用註冊的中間件（按照註冊的順序）對HttpRequest進行處理。這樣做相比與原來使用HttpApplication的管道方式而言，其優勢在於完全由開發人員決定HttpRequest需要執行怎麼樣的處理，沒有多餘的其他步驟。而原來的方式既使開發人員不希望對一個HttpRequest進行任何處理，但HttpApplication仍然會按照管道的設置依次創建HttpModel -> 激活HttpHandler -> 處理Session等。據.net core團隊給出來的性能測試數據來看，Asp.net core(.net core)相比與原來的Web（.net framework 4.6）程序性能提升了2300%.
而.net core其實就是保留了上面所說的優勢的同時支持跨平臺運行。.net core的系統是可以真正運行在除Windows以外的其他平臺的。輕量級、跨平臺、模塊化是.net core整體的設計理念，同時也是微軟產品理念轉變的一個體現。.net core雖然有千般好，但是我們當前仍然沒有直接使用它，因爲它現在有一個致使的“缺陷”那就是生態環境，由於.net core的API已經完全重寫，雖然當前已經提供了.NET Faremwork 90%以上的API，但是仍然會造成一些開發上的不便，當然這還不是最大的問題，最大的問題在於一些第三方Nuget包仍然不支持.net core。這樣就會造成一些項目無法直接遷移或是遷移成本太高的問題。
如何創建一個Asp.net core的項目
說了這麼多，我們來看一下在創建項目時Asp.net core和.net core有什麼不同吧，我們以Vistual studio 2017上創建項目爲例，首先打開VS2017後點擊創建項目-> Asp.net core web應用，這時會彈出模版選擇的窗口。
在這個選擇窗口中我們可以看到在左上角的那個下拉列表中可以選擇.net framework以及.net core。當我們選擇.net framewrok時創建出來的項目工程即爲asp.net core。項目創建成功後可以在項目的屬性中看到使用的Framework版本是4.6.2。但是項目文件的組織結構已經和.net core的項目結構一樣了。
Asp.net core項目的"坑"
近期在對新的項目進行性能測試時發現系統的內存佔用似乎只能使用到1.5G。經過多次測試以及代碼檢查終於發現新創建出來的Asp.net core的項目默認的目標平臺是X86而不是AnyCPU。當嘗試在VS中新目標平臺改爲AnyCPU時發現項目不能運行，拋出異常"無法加載 DLL“libuv”: 找不到指定的模塊。 (異常來自 HRESULT:0x8007007E)。"，無奈只能將項目的目標平臺改爲X64，然後發現在開發環境已經一切正常，但是當將代碼部署到Azure App Service上時系統仍然不能訪問，異常和上面的相同。最後檢查了項目的工程文件(*.proj)然後發現雖然PlatformTarget一項中已經改爲X64，但是在PlatformTarget的屬性中Platform仍然是AnyCPU，手動修改工程文件將AnyCPU改爲X64後一切正常