.NET成年了，而後呢？

 

做者｜Lex Li

編輯｜郭蕾

這多是惟一一篇系統回顧 .NET 發展的文章。.NET 的成年禮到了，你會送它什麼？

2014 年 11 月 12 日，美國紐約曼哈頓，多雲，氣溫適宜。微軟公司執行副總裁「紅衣主教」 Scott Guthrie 換好他標誌性的紅色 Polo 衫，爲即將召開的 Connect 大會主題演講作着最後的準備。他從 1997 年畢業加入微軟起便參與 .NET Framework 的研發行動，是 ASP.NET 技術的奠定人。此後 Scott 逐漸轉入管理者的角色，從領導 Web 相關技術研發團隊起步，到掌舵整個開發工具部門，再到近年來執掌 Azure 雲計算平臺相關的龐大事業部。一路走來，他已經經歷了很多相似的會議，像早年的 Professional Developer Conference，後來的 MIX 和最近幾年的 Microsoft Build。不過 2014 年初，Steve Ballmer 將微軟公司的帥印交到 Satya Nadella 手中，一個全新的公司形象呼之欲出。一系列剛剛獲得批准的新工程，即將在本次 Connect 技術大會上對外公佈。

音樂響起，Scott 大步流星走上舞臺，開始闡述過去幾個月來微軟公司在 Mobile First Cloud First 戰略下取得的一系列成就。Azure 雲計算平臺迅速發展壯大，使微軟得以緊追 AWS 這個領頭羊，與其餘虎視眈眈的競爭對手拉開身位。另外一件值得高興的事情，是微軟與主打跨平臺移動開發的 Xamarin 公司將進一步加深合做，共同推進 .NET 技術在移動應用領域的發展，以彌補 Windows Phone 平臺移動市場佔有率不高的短板。

當「創新」、「敏捷」和「開放」這幾個關鍵字眼出如今大屏幕上，敏銳的觀衆必然會聯想到微軟公司的變化。是的，在過去很短期內微軟開始在 Azure 中緊密集成多種開源軟件和 Linux 操做系統，甚至打出了「微軟愛 Linux」的宣傳口號。不只如此，前幾年它又實驗性地公開了一批項目的源代碼，如 ASP.NET MVC 和 Roslyn。那麼下個階段微軟打算怎麼在開放性方面更進一步呢？Scott Guthrie 興奮地宣佈微軟即將發佈一個名爲 .NET Core 的全新開發平臺，這個平臺的所有代碼將基於開源協議徹底公開。話音未落，會場內當即響起一片掌聲。好消息還不只僅這條，Scott 又介紹到，不一樣於前代 .NET Framework，這個 .NET Core 平臺除了支持自家的 Windows，還將支持主流的 Linux 和 OS X（後來更名爲 macOS）等操做系統。會場內再次響起掌聲。

商業公司開源本身的主打產品，從九十年代起已經很多，到後來雖然不算大新聞，卻往往傳爲佳話。例如網景公司從 1998 年 1 月起開源本身的瀏覽器即 Mozilla 項目，到 2014 年已通過去十六年。2006 年起 Sun 公司逐步開源了 Java 的絕大部分源代碼給 OpenJDK 項目，算起來也已通過去了八年。做爲一家和開源社區曾經矛盾重重的商業軟件公司，轉型中的微軟在這個時候又邁出了關鍵的一步。

生於憂患

九十年代初，正是微軟公司經過 Windows 操做系統和 Office 辦公軟件在桌面市場攻城略地望風披靡的時代。兩個 Windows 平臺開發者經常使用的工具也來自微軟：Visual Basic 是一個快速開發工具，只需拖拽控件配合簡單代碼就能作出一個不錯的桌面軟件；Visual C++，語言複雜，框架複雜，好在功能全面，可以覆蓋從系統驅動到複雜應用程序等各類開發場景。所以即便 Delphi 和 PowerBuilder 等第三方工具虎視眈眈，微軟自主開發工具的市場佔有率仍是穩如泰山。

瀏覽器時代的到來和客戶端服務器模式的普及，很快改變了軟件開發的格局。1995 年 Java 和 Java 兩門新興語言的出現，讓更多開發者開始將目光投向了新的領域。在瀏覽器方面，微軟很快推出了 Internet Explorer、J 和 VB 去應對挑戰。在服務器方面，微軟也開發出 IIS 和 ASP 來填補空白。最使人意外的是，微軟向 SUN 公司購買了 Java 的受權，進而推出 Windows 平臺的 JDK 和開發工具 Visual J++。這一系列的動做使微軟得以緊跟競爭對手的步伐。但仔細分析之下它們既沒有造成一個統一的編程模型，也沒有和微軟已有的技術 Win32/COM 進行很好的整合。Visual J++ 的 6.0 版本曾經一度讓人看到全面整合的但願，可是微軟和 SUN 公司之間的法律糾紛讓它止步不前。對於野心勃勃想在桌面軟件領域保持霸主地位同時進入新市場的微軟來講，此刻它急需掌握一個新的開發平臺，來迎接新千年的挑戰。

幾年的低調研發以後，微軟終於在 2000 年公開 .NET 技術，讓廣大 Windows 開發者看到了新氣象：

• 統一的程序運行時（.NET CLR）
• 豐富的開發語言選擇（C#、Visual Basic、C++ 和 J#）
• 統一的公共函數庫（Base Class Libraries）
• 便利的開發框架（Windows Forms 和 ASP.NET WebForms）
• 便利的開發工具（Visual Studio .NET）

這些技術在 2002 年初正式發佈，迅速取代了以前老舊的 VB 6 和 ASP 等技術，也推進了 Windows 平臺的軟件升級換代。那些曾經給微軟形成壓力的第三方技術，如 Delphi、PowerBuilder 也慢慢淡出了你們的視野。

從 2003 年起，微軟按照一個略顯緩慢可是還算緊湊的節奏開始給 .NET 構建一個完整的生態系統：

• 2003 年，Windows Server 2003 發佈，搭載 .NET Framework 1.1。微軟同時發佈了 Visual Studio 2003。這個小版本升級填補了不少 1.0 時代的空白，甚至帶來了 Compact Framework 這樣針對 Windows CE 移動設備的新技術。
• 2005 年，.NET Framework 2.0 和 Visual Studio 2005 發佈，加入虛擬機級別的泛型和 64 位程序開發的支持。與 SQL Server 2005 的深度整合，使得程序開發更有效率。微軟逐漸補全了 .NET 工具鏈上的短板，如此時推出的 MSBuild 構建工具和 MSTest 單元測試框架。
• 2006 年，發佈 .NET Framework 3.0，並引入了 WPF、WCF 和 WF 等新框架。開發複雜軟件系統，不論在界面設計仍是通訊層面都變得更爲簡單和標準化。
• 2007 年，經過 .NET Framework 3.5 和 Visual Studio 2008 微軟又爲開發者帶來了 LINQ 和 AJAX 支持。前者使得 C# 和 VB 語言能在很大程度上取代 SQL，提高了數據查詢方面的開發體驗。後者使得 ASP.NET 網站應用開發跟上了業界潮流。後續發佈的 .NET Framework 3.5.1 進一步加入 Entity Framework 這個實體數據映射引擎。同年微軟還發布了 Silverlight，開始嘗試利用 .NET 技術來進行瀏覽器端應用程序的開發。
• 2010 年以後，微軟又推出了.NET Framework 4.0 和 4.5 等後續版本，在並行計算方面推出了 Task Parallel Library 新框架和 async/await 新語法，不只大大下降了 .NET 平臺多線程軟件開發的複雜度，更是對其餘開發語言的設計產生了深入影響。好比 Java 等其餘開發語言就借鑑了 async/await。

2006 年起 Java 成爲開源項目，伴隨着 Android 手機平臺和 Hadoop/Spark 大數據平臺再現活力。而這個時候的 .NET 技術，已失去它當初剛發佈時的奪目光彩。雖然 Windows 桌面和服務器端的開發者會爲這些穩步更新感到激動，但放眼外面的世界，Ruby on Rails、HTML 五、大數據、移動開發，新技術的潮流一波又一波，都沒有看到微軟 .NET 的身影。2014 年 .NET Core 的開源，給人留下了遐想空間。

篳路藍縷

從網景公司決定開源瀏覽器代碼到 Mozilla 項目正式上線，整個過程歷時三個多月。SUN 開源 Java 的過程更長一些，先是花了大半年的氣力將絕大部分代碼公開，而後 OpenJDK 項目方面慢慢接收。而這都還僅僅是萬里長征第一步。圍繞這些代碼必須打造一個活躍的開源社區，才能保證項目將來的持續發展。因此微軟宣佈要打造一個全新的開源平臺，那麼就註定須要一個漫長的研發過程。

開源項目 Mono 在這個時候伸出了橄欖枝。Mono 最初定位爲 Linux 和 Mac 桌面應用開發平臺。2008 年起，它與 Unity 遊戲引擎的合做惠及數百萬遊戲開發者，同時還經過 Xamarin 這個品牌創建了一套跨平臺移動開發工具，客戶包括 Honeywell、國家儀器、西門子等一萬五千多家公司。溯本追源，竟是 2000 年微軟聯合惠普與英特爾提交給 ECMA 的 .NET 平臺相關技術標準。Mono 項目多年積累的各類經驗，對於微軟工程團隊來講很有借鑑價值，算是慈烏反哺了。

微軟更是快馬加鞭地開始執行如下這些工做：

• .NET Framework 的代碼以前的受權協議有諸多限制，僅僅可以用於代碼調試等有限場合。通過從新受權後，這些代碼以開源協議發佈，使得 Mono 項目能夠加以集成，改進 Mono 和 .NET 的兼容性。
• 在 GitHub 上建立 CoreFX 和 CoreCLR 等代碼倉庫，分期分批地將 .NET 的核心代碼發佈出來。利用 Mono 環境來進行跨平臺的代碼構建，同時創建公開的持續集成服務器，使得 .NET Core 平臺的構建過程徹底公開透明。（固然隨着 .NET Core 工具鏈的成熟，它的構建過程後續再也不須要 Mono 的幫助。）
• 創建獨立運營的 .NET 基金會，接納樂意推進 .NET 技術發展的合做夥伴，同時全局管理 .NET 相關的核心資產和項目。
• 在 GitHub 等平臺上展開公開討論，凝聚共識來創建社區。這樣，一方面規範了微軟代碼的發佈過程，一方面也制定了補丁審覈等基本流程，使得 .NET 相關的核心項目能夠接受來自社區開發者的代碼。

在 .NET Core 的 GitHub 倉庫中，另有一些有趣的討論。從中咱們能夠窺見這個開源進程向前推動的一些動力之源。

一個例子是上面提到的持續集成服務。微軟團隊使用一個比較複雜的私有系統來構建 .NET Framework。這種方式固然不適合 .NET Core 這個開源項目的須要。所以 Mono 團隊的 Alexander Köplinger 在 GitHub 上建議使用 Travis CI 或者 AppVeyor 服務來作搭建一個公開的持續集成平臺，而且提供了一個可用的 AppVeyor 配置腳本。微軟欣然接受了這個建議。固然現在基於開源的 Jenkins 工具微軟新作了一個更爲公開透明的方案。

另外一個例子是，當時 Protobuild 工具被 MonoGame 項目用來生成跨平臺的工程文件，顯示出很大的潛力，因此它的負責人 June Rhodes 向微軟建議採用 Protobuild 來處理 .NET Core 源代碼中的工程文件。微軟團隊詳細闡明瞭他們對於工程文件格式的想法，清楚解釋爲什麼 Protobuild 並不適合 .NET Core 的須要。

固然，還有一些作靜態代碼分析工具的公司或是比較資深的技術顧問，在 GitHub 上發帖來指出微軟代碼中的不足之處和能夠採用的修補方案，巧妙地作起了小廣告。微軟團隊每次也是及時迴應，或是很快地修復了潛在問題，或是指出沒有采納相關建議的緣由。

其餘很是有價值的外部支援，好比來自業界其餘大公司的補丁，也都是以 GitHub pull request 的形式出現，方便審查和存檔。例如 2015 年 5 月，英特爾的工程師向 .NET Core 捐贈了一批有關 CRC 算法的補丁，使得 GZipStream 等經常使用類型性能倍增。2016 年 6 月加入 .NET 基金會的三星公司更是竭盡全力，不只令 .NET Core 成爲自家 Tizen 計算平臺的應用開發標準配置，也使 .NET Core 程序可以支持其餘採用 ARM 處理器的相似平臺（如樹莓派）。

在 Connect 2016 大會上，微軟終於詳細公佈了 .NET Core 平臺開源兩年以來的一系列數據，例如新近提交給 .NET Core 相關項目的貢獻超過 60% 都來自於社區。這代表，雖然 .NET Core 暫時還比較依賴微軟，但它背後已經有一個活躍的社區，並且微軟和這個社區保持着良好的互動。

蜀道艱難

固然，一旦選擇代碼開源，而且將設計和發佈的流程逐步從公司內部轉移到 GitHub 這樣的公開平臺，微軟一樣須要去直面這些轉變帶來的種種挑戰以及負面影響。

第一個挑戰，是如何把控預覽版本、發佈候選版本和正式版本的節奏。從 2015 年年初起，微軟就連續發佈了多個 .NET Core 平臺的預覽版本，不過到 11 月項目開源滿一週年的時候，開發計劃中的任務尚未所有完成。11 月 18 日在微軟的官方網站上卻出現了首個發佈候選版本。過後來看，這個版本存在很多尚不完善的地方，用戶體驗不佳，其實繼續標記爲預覽版更好。微軟以後也當即針對性的調整了開發計劃。等到 2016 年 5 月 16 日發佈 .NET Core 第二個發佈候選版本時，產品質量顯著提高。

第二個挑戰，是選擇一個合適的版本號。在 2014 年末這個平臺剛公佈的時候，名字仍是 .NET Core 5 和 ASP.NET 5。微軟最初選擇 5 做爲版本號，多是但願它成爲 .NET Framework 4.x 的延續。但這個版本號很容易讓部分用戶認爲這個新平臺是 .NET Framework 的簡單升級。然而 .NET Core 從本質上說，是一個徹底獨立的全新平臺，和過去的 .NET Framework 有着天壤之別。所以微軟收集各方意見以後，在第二個發佈候選版本時開始啓用新命名，.NET Core 1.0 和 ASP.NET Core 1.0。

第三個挑戰，是如何爲 .NET Core 這個新平臺搭配合適的工具鏈。這也是一個很是重大的抉擇。前面提到，.NET Core 誕生之初沒有一個完整的工具鏈，連最初的構建過程都須要 Mono 來配合。本來微軟的計劃是複用當時爲 UWP 全新開發的 project.json 工程格式，並圍繞這個格式設計出以 DNX 爲核心工具的一套工具鏈。在第一個發佈候選版本中，微軟也確實搭載了 DNX 等命令行工具。可是棘手的問題出現了，從 2005 年 .NET Framework 2.0 時代開始，整個 .NET 生態環境是圍繞着 MSBuild 創建起來的。DNX 和 MSBuild 並不兼容，所以微軟必須決定是否徹底拋棄 MSBuild 而圍繞 DNX 重建一個生態系統。幾經權衡微軟放棄了 DNX，回到了 MSBuild 之上，開源了相關代碼並圍繞它從新設計 .NET Core SDK。這也是爲何到了第二個發佈候選版本面世的時候 DNX 徹底消失，而 MSBuild 以及新的 dotnet 命令行工具出現了。

從上述內容能夠看出，其實到第二個發佈候選版本止，圍繞着 .NET Core 這個平臺的各類摸索纔算是塵埃落定。在 Stack Overflow 等問答站點上，短短几個月內詢問 DNX 和 dotnet 兩套工具鏈如何遷移、有何異同的問題一會兒多了起來，甚至 DNX 被廢棄很長時間以後仍然零星出現。這反映了微軟當時在設計上面的反覆確實給開發者們帶來了不小困擾。

固然，解決這些問題最好的方式，就是發佈一個穩定可靠的正式版本。微軟選擇了 6 月 21 日 Red Hat 公司主辦的 DevNation 技術大會，在一個稍顯奇怪的場合發佈了 .NET Core 1.0 和 ASP.NET Core 1.0。

說場合奇怪，一方面固然是由於會議自己不是微軟本身主辦。另外一方面是由於發佈會當時臺上的幾個技術演示內容都有點不一樣尋常。它們分別是：

• Red Hat 公司演示他們爲微軟剛剛開源的編輯器 Visual Studio Code 設計的 Java 語言插件。
• 微軟公司演示能夠運行在 Red Hat Linux 上面的 .NET Core 1.0。
• Eclipse Che 的負責人演示 Che 這個新 IDE 對於 .NET Core 和 C# 的支持。

怎麼樣，是否是以爲臺上這羣人都拿錯了劇本？如此有趣的方式，反而契合了當前 IT 技術發展的潮流。如今已經沒有哪家公司可以僅靠種好本身一畝三分地就旱澇保收。用戶系統的多樣性使得每一個品牌都必須更好的瞭解別家技術，增強互操做性，有時候甚至要「越俎代庖」，經過合做構建一個更加開放的總體大環境。

.NET Core 1.0 運行環境是正式發佈了，但與它搭配的工具鏈 .NET Core SDK 僅僅是一個預覽版本。出現這種情況，很大程度是因爲 MSBuild 開源較晚，不少從 DNX 工具鏈遷移到 MSBuild 的具體開發工做還沒能結束。此後 .NET Core SDK 的研發雖然緊鑼密鼓，但又錯過了 2016 年 11 月 16 號的 .NET Core 1.1 發佈會。直到 2017 年 3 月 7 日 Visual Studio 2017 正式發行，.NET Core SDK 1.0 才姍姍來遲。

爲什麼以上要討論這麼多微軟幹得並不漂亮的地方呢？項目如此反覆，難道不是在打微軟的臉嗎？只需咱們靜下心來看看時間表，就會發現——.NET Core 從 2014 年 11 月項目正式公佈，到 2016 年 6 月運行環境 1.0 正式發佈，其實才不過一年半時間，而到 2017 年 3 月 SDK 1.0 正式發佈，整個.NET Core 1.x 平臺的計劃執行時間，滿打滿算也就兩年多一點點。對於這個事實上很是複雜的系統來講，這一路走下來並不容易，道路上出現點曲折仍是能夠接受的。放眼開源社區，別家項目遇到相似問題也是屢見不鮮。微軟採起了徹底開源的方式來打造這個平臺，將本身研發過程的每一步都暴露在你們眼皮底下，這種勇氣自己就很是使人欽佩了。

至於部分微軟老用戶抱怨開源以後版本太多，很難跟上研發進度獲取最新信息，微軟的「首席佈道師」 Scott Hanselman 打了一個很是形象的比方。絕大多數人吃牛排，都會選擇七分或者全熟之類的作法，比如開發工具的用戶使用發佈候選版本或者正式版本。只是若是遇到一個快速迭代的項目，尤爲是頻繁發佈的開源項目，它的一切版本包括測試版本都是公開的，那麼用戶一不當心試玩測試版本，就比如吃上五分熟的牛排或者乾脆牛肉刺身，有人吃着不舒服或者出現消化不良，那也是很正常的事情。開源的好處，即是你們各取所需，按照各自的習慣去選擇適合的版本。不得不說，讓用戶慢慢接受和認同 .NET Core 的開發模式，還須要一段比較長的時間。

面向將來

.NET Core 1.0 和 1.1 雖然是微軟提供官方技術支持的正式版本，爲後續版本奠基基礎的功勞毋庸置疑，可是嚴格意義上說，它們僅僅適合一些行業用戶，而不是以前使用 .NET Framework 許多年的龐大用戶羣。所以微軟還必須竭盡所能在 .NET Core 2.0 發佈以前作出更多改進。

首先，微軟一直給予厚望的 .NET Standard 標準，在它的 1.x 版本中僅僅規定了一萬多個 API。這使得依賴項衆多的龐大軟件系統難於遷移到這個新平臺。經過拜訪本身的客戶，尤爲是企業客戶，微軟對於 .NET Standard 2.0 須要包含哪些 API 進行了摸底調查，最終歸入到 2.0 標準中 的 API 數量超過了三萬個。

其次，微軟完成了對 Xamarin 的收購併接手 Mono 平臺，對外增強和 Unity 的合做關係，對內協調以前旗下的 .NET Framework 和 UWP 兩個平臺，保證 .NET Standard 2.0 可以在這些主流平臺上獲得完善的支持。這種跨平臺兼容性對於全部 .NET 開發者都特別重要，尤爲是 Unity 開發者的福音。雖然 Unity 在遊戲引擎領域很是熱門，可是技術上一系列緣由使得它一直沒法支持最新的 .NET 技術（如編譯器和 IDE）。2016 年 4 月 1 日 Unity 加入 .NET 基金會，這一尷尬局面大爲改觀。

此外，微軟本身旗下的產品也結束了過去幾十年間那種每隔幾年才發佈新版本的慢節奏，走上了小步快跑頻繁更新的快速路，這樣就能更好地配合 .NET Core 開源項目的發佈週期。這裏特別表揚一下往日升級慢吞吞的 Visual Studio。Visual Studio 2017 從 2017 年 3 月正式發佈起，每隔數週就有新版本發佈，版本號從 15.0 一路遞增到年末的 15.5，很好地配合了 .NET Core 2.0 測試版本和正式版的發佈，還遇上了 Windows 10/UWP 快速升級的節奏。

固然另外一個改變，是微軟在產品發佈時的低調。2017 年不管是 .NET Core 2.0 的幾個測試版本仍是正式版本，都沒有搞隆重的發佈會。低調，並不意味着微軟忽視本身的產品和使用它的開發者，相反持續改善開發者體驗變成了平常重點。想看看哪些新的 API 可使用，開發者能夠查閱 API Browser 網站和 GitHub 相關倉庫。想參考新的工具和入門指南，開發者能夠訪問微軟全新的文檔網站。想了解哪些新的特性將在後續版本中出現，開發者能夠經過微軟在 GitHub 主倉庫上的公告和 .NET 官方博客提早獲知。而絕大部分的資料，都託管在對應的 GitHub 倉庫裏，不只官方時時修訂和更新，還接受大量來自社區的新內容。

開發者社區對於這個新平臺的響應也愈來愈積極。更多的函數庫開始遷移到 .NET Standard 2.0。AppVeyor 等平臺也都正式支持了 Visual Studio 2017 和 .NET Core 2.0 SDK。2017 年 5 月 10 日微軟發佈了新產品 Visual Studio for Mac，填補自身在 Mac 平臺開發工具領域的空白，但一時還沒法提供適合 Linux 平臺的相似工具。同爲 .NET 基金會成員的 JetBrains 公司則在 2017 年夏天推出了 Rider 跨平臺 IDE 的首個正式版本，補上了這個短板。

從 2002 年 2 月 13 日 .NET Framework 1.0 和 Visual Studio .NET 2002 發佈算起，到今年 2 月 13 日，.NET 已經走過十六個年頭，邁入了成年階段。按照官方計劃，.NET Core 2.1 將在今年晚些時候發佈，在性能和開發者體驗等方面都會有大的提高，達成又一個里程碑。雄關漫道真如鐵，而今邁步從頭越。在微軟公司和開源社區等多股力量的不懈努力之下，.NET 必將銳不可當，再創輝煌！

做者介紹

Lex Li，資深軟件工程師兼播客主播，微軟最有價值技術專家，著有《.NET 傳奇》等書。現就任於摩根士丹利蒙特利爾研發中心，從事企業私有云相關的技術推廣工做。業餘時間裏他的身影也會出如今一些微軟技術的開源項目或是 Stack Overlow 等在線社區。他的微博賬號是 @Lex_Li，我的博客位於 https://blog.lextudio.com， 播客 .NET FM 位於 http://podcast.sxl.cn。