* * * WINDOWS 10 2015 年特別版 # Microsoft .NET - .NET 和通用 Windows 平臺開發 作者?[Daniel Jacobson](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Daniel+Jacobson)?| Windows 2015 借助 Visual Studio 2015，您現在可以使用最新 .NET 技術構建運行于所有 Windows 10 設備（其中包括您口袋里的手機、背包中的筆記本電腦或平板電腦、辦公室里的 Surface Hub、家里的 Xbox 控制臺、HoloLens 以及您可以想象的任何其他物聯網 (IoT) 設備）上的通用 Windows 平臺 (UWP) 應用程序。成為 Windows 開發人員真的是太讓人激動了。 ## UWP 的新增功能 作為一名 .NET 開發人員，您將會對 UWP 提供的所有功能欣喜若狂。UWP 應用將在大量已經且將繼續升級至 Windows 10 的桌面上以“窗口化”模式運行。UWP 應用將能夠通過一個應用程序包和一個代碼庫連接所有 Windows 10 設備。此外，UWP 應用還充分利用全新 Microsoft .NET Core Framework（本文后面部分有詳細介紹）。您的 .NET 業務邏輯可以運行于支持 .NET Core 的其他平臺，例如 ASP.NET 5。UWP 應用為應用部署一小塊 .NET Core，這樣應用將始終針對您測試應用所依據的 .NET 版本運行。所有 .NET UWP 應用都充分利用 .NET Native，其可生成高度優化的本機代碼，從而提升性能（本文也有所介紹）。 ## .NET Core Framework .NET Core Framework 是適用于現代設備和云工作負載的新版 .NET。它是 Microsoft .NET Framework 的通用及模塊化實現，可以針對各種工作負載在許多不同的環境中移植和使用。此外，.NET Core Framework 是開源代碼并在 GitHub ([github.com/dotnet/corefx](http://github.com/dotnet/corefx)) 上提供，Microsoft 在 Windows、Linux 和 Mac OS X 上均提供支持。如果您是使用最新 .NET 技術的 UWP 開發人員，這對您來說將是非常大的優勢。在 Visual Studio 2015 中，您可以利用 .NET Core 可移植類庫 (PCL) 來鎖定任意 UWP 應用、.NET 4.6 應用或 ASP.NET 5 應用（甚至那些跨平臺應用）。 此外，.NET Core Framework 還是先前在 Windows 應用商店應用開發中可用的 .NET API 的超集。這就表示，UWP 開發人員現在在其 API 庫中擁有其他多個命名空間。其中一個此類命名空間是 System.Net.Sockets，用于 UDP 通信。這之前在 Windows Runtime (WinRT) 應用中不可用，解決方法是使用 WinRT 特定 UDP API。由于套接字在 .NET Core 中可用，因此，您可以在 UWP 應用及其他 .NET 應用中使用相同的套接字代碼。 另一大優勢是，System.Net.Http.HttpClient API 構建于 WinRT HTTP 堆棧之上。這樣，如果服務器支持 HTTP/2，默認情況下就可以使用它，從而降低延遲并減少來回通信。 Windows Communication Foundation (WCF) 客戶端（以及關聯的“添加服務引用”對話框）先前在 Windows Phone .appx 項目中不可用，但是因為它屬于 .NET Core，所以可以由所有 .NET UWP 應用使用。 最后，.NET Core 是 .NET Native 依賴的基礎框架。設計 .NET Native 時，很顯然 .NET Framework 將不適合作為框架類庫的基礎。這是因為 .NET Native 靜態地將框架與應用相連，然后刪除應用不需要的額外內容。（這是粗略簡單的介紹，但是您已經明白了。有關更多詳細信息，請查看“Inside .NET Native”（.NET Native 內部），網址為?[bit.ly/1UR7ChW](http://bit.ly/1UR7ChW)。） 由于未構造傳統的 .NET Framework 實現，因此，對于鏈接器而言，減少編譯到應用中的框架量是個挑戰。畢竟，.NET Core 實際上是 .NET Framework 的分支，而 .NET Framework 的實現已圍繞構造問題進行了優化。該實現的另一個優勢是能夠將 .NET Core Framework 作為一套 NuGet 程序包進行交付，這樣就可以從 .NET Framework 帶外更新各個類。不過，在進一步操作之前，讓我們來看看 NuGet 中的一些變化。 ## NuGet 的新增功能 對于 UWP，已內置 NuGet 3.1 支持。此版本中包括可改進程序包依賴項管理以及本地緩存程序包以便在多個項目中重用的功能。 對于 NuGet 3.1，程序包依賴項聲明模型已更新。從 ASP.NET 5 開始，NuGet 引入了對 project.json 文件的支持，這是 UWP 支持的同一模型。Project.json 使您可以介紹一個項目的依賴項，清晰地定義您直接依賴的程序包。由于對于 ASP.NET 5 和 UWP 而言格式相同，因此您可以使用相同的文件定義兩個平臺以及 PCL 的程序包引用。 從 packages.config 更改為 project.json 使您可以在項目中“重新啟動”應用，而且現在有了新的 NuGet 傳遞依賴項功能。如果您引用一個引用了另一 NuGet 程序包的程序包，則使用它管理包版本會比較困難。例如，NHibernate 是依賴于 lesi.Collections 的程序包。在 packages.config 中，您將會有兩個引用，每個程序包一個引用。想要更新 NHibernate 時，是否也會更新 lesi.collections？ 如果有適用于 lesi.collections 的更新，是否還需要更新 NHibernate 來支持新功能？ 這會變成混亂的循環，程序包版本管理比較困難。NuGet 的可傳遞依賴項功能簡化了這一決定，通過程序包定義文件 (nuspecs) 中改進的語義版本更新程序包引用。 此外，NuGet 現在可下載您使用的程序包副本并將這些程序包的副本存儲在位于 %userprofile%\.nuget\packages 文件夾中的全局程序包文件夾中。這不僅可以提升程序包引用的性能（因為您將只需下載每個程序包一次），而且還會減少您工作站上所用的磁盤空間（因為您可以在項目間共享相同的程序包二進制文件）。 ## NuGet 和 .NET Core 使用注重構造的 .NET Core 并將其與 NuGet 3.1 的程序包依賴項管理結合時會如何？ 您將可以從 .NET Framework 的其余部分帶外更新各個 .NET Framework 程序包。對于 UWP，.NET Core 作為一套 NuGet 程序包包含在您的應用中。創建新項目時，您將只看到常規 Microsoft.NETCore.UniversalWindowsPlatform 程序包依賴項，但是如果在 NuGet 上看到此程序包，您將會看到包含的所有 .NET Framework 庫，如圖 1?所示。 ? 圖 1 查看 NuGet 中的 .NET Framework 庫 例如，假設存在引入您喜歡在應用程序中使用的新 API 的 System.Net.Sockets 類的更新。對于傳統的 .NET，您的應用需要依賴于整個 .NET Framework 的新版本。對于 UWP 和具有 NuGet 的 .NET Core，您可以將 NuGet 依賴項更新為包含該程序包的最新版本即可。然后，編譯和打包您的應用程序時，該版本的框架庫將包含在您的應用程序中。這樣一來，您便可以靈活地使用最新且最強大的 .NET 技術，而不用迫使用戶始終在其設備上安裝最新的框架。 除了能夠根據您自己的節奏更新 .NET 類之外，.NET Core 的組件化特征還能使 .NET Native 在交付到用戶設備時為所有 Windows 10 C# 和 Visual Basic 應用程序帶來性能優勢。 ## 什么是 .NET Native？ 現在，您已經了解 .NET Core Framework 實現了 .NET Native，接下來我將為您詳細介紹什么是 .NET Native 及其可為 UWP 開發人員提供哪些功能。 .NET Native 是一種預先 (AOT) 編譯過程，其在編譯時將您的托管 .NET 代碼轉變為本機代碼。相反，傳統的 .NET 則采用實時 (JIT) 編譯，這會延遲方法的本機編譯，直到其在運行時首次執行。.NET Native 更類似于 C++ 編譯器。事實上，它采用 Visual Studio C++ 編譯器作為其工具鏈的一部分。每個托管的（C# 或 Visual Basic）通用 Windows 應用都將利用這一新技術。應用程序會在到達用戶設備之前自動編譯為本機代碼。如果您想深入了解其工作原理，我強烈建議您閱讀 MSDN 庫文章“Compiling Apps with .NET Native”（使用 .NET Native 編譯應用），網址為?[bit.ly/1QcTGxm](http://bit.ly/1QcTGxm)。 ## .NET Native 為您及您的應用帶來哪些影響？ 獲得的好處可能不盡相同，但是大多數情況下，應用啟動速度會變快、性能會更出色且占用的系統資源會更少。預計首次啟動應用程序時其性能會提升 60%，后續啟動（“熱”啟動）則會實現高達 40% 的性能提升。進行本機編譯時，應用程序會占用更少的內存。.NET 運行時的所有依賴項都會被刪除，所以最終用戶將永不需要跳出安裝體驗過程即可獲得您應用所引用的特定 .NET Framework 版本。事實上，所有 .NET 依賴項均打包在您的應用程序內，所以您應用的行為不會因計算機上安裝的 .NET Framework 有變化而發生變化。 即使您的應用程序正編譯為本機二進制文件，您仍可利用您熟悉的 .NET 語言（C# 或 Visual Basic）以及關聯的出色工具。最后，您可以繼續使用 .NET Framework 提供的全面且一致的編程模型，它具有面向業務邏輯、內置內存管理以及異常處理的廣泛 API。 有了 .NET Native，您在以下兩個方面均實現最優化：托管的開發和 C++ 性能。這多酷啊！ ## 調試與發布編譯配置 .NET Native 編譯是一個復雜的過程，這就使得其比經典 .NET 編譯要慢一點。前面提到的優勢都是以犧牲編譯時間為代價的。每次要運行應用時您都可以選擇本機編譯，但是您將會花費額外的時間來等待生成完成。Visual Studio 工具旨在解決這一問題，以及打造盡可能順暢的開發體驗。 在“調試”配置中構建并運行時，您將針對應用程序內打包的 CoreCLR 運行中間語言代碼。.NET 系統組件與您的應用程序代碼一起打包，您的應用程序將依賴于 Microsoft.NET.CoreRuntime (CoreCLR) 程序包。如果您正在測試的設備缺少 CoreCLR 框架，則在部署您的應用程序之前，Visual Studio 將自動檢測并進行安裝。 這意味著您可以獲得盡可能出色的開發體驗：快速編譯和部署、豐富的調試與診斷以及您習慣用于 .NET 開發的所有工具。 切換至“發布”模式時，默認情況下，您的應用會利用 .NET Native 工具鏈。因為程序包編譯到本機二進制文件，所以程序包不需要包含 .NET Framework 庫。而且，程序包依賴于最新安裝的 .NET Native 運行時（與 CoreCLR 程序包相反）。設備上的 .NET Native 運行時將始終與您的應用程序包兼容。 通過“發布”配置進行的本地本機編譯將支持在與您客戶將體驗的環境類似的一種環境中測試您的應用程序。要繼續進行開發，定期進行該測試非常重要！ 通過使用您的客戶將體驗的代碼生成和運行時技術測試您的應用程序，您將可以確保解決所有可能的 bug（例如由于不同性能特點導致的潛在爭用條件）。 一個很好的經驗法則就是，在開發過程中定期對您的應用進行這一測試，以確保發現并糾正 .NET Native 編譯器可能會導致的任何問題。大多數情況下，不會有問題；但是，仍會有一些與 .NET Native 不太兼容的條目。4+ 維數組就是個例子。最終，您的客戶將會獲得您的應用程序的 .NET Native 編譯版本，所以在開發過程中以及發運之前對該版本進行測試始終是個好的做法。 除了測試 .NET Native 編譯，您可能還會注意到 AnyCPU 生成配置消失了。有了 .NET Native，AnyCPU 不再是有效的生成配置，因為本機編譯依賴體系結構。另一個結果就是，在您打包應用程序時，應選擇全部三個體系結構配置（x86、x64 和 ARM）以確保您的應用程序盡可能適用于更多的設備。這畢竟是通用 Windows 平臺。 這么說來，您仍可以構建要在您的 UWP 應用中引用的 AnyCPU 庫和 DLL。這些組件將基于使用它的項目 (.appx) 的配置編譯到特定于體系結構的二進制文件中。 ## 云中的 .NET Native .NET Native 一個強大的功能就是編譯器可以托管在云中。這意味著，當對編譯器進行可能會對您的應用程序產生有益影響的改進后，應用商店的云托管 .NET Native 編譯器可以重新編譯您的應用程序包來獲取這些優勢。每次完成此編譯后，對于您這個開發人員都將是透明的，但是，最終都是應用程序用戶更幸福。 不過，這會對您的工作流程產生一些影響。例如，確保您始終安裝最新的工具是很好的想法，這樣您就可以針對最新本地版本的編譯器測試您的 .NET Native 編譯。此外，在 Visual Studio 中構建您的應用商店程序包時，會創建兩個程序包：一個是 .appxupload，一個是 “test”.appx，用于旁加載。.appxupload 包含 MSIL 二進制文件，以及對您應用使用的 .NET Native 工具鏈版本的顯式引用（在 AppxManifest.xml 中引用為“ilc.exe”）。之后，該程序包進入應用商店并使用相同的 .NET Native 工具鏈版本對其進行編譯。因為編譯器是云托管編譯器，所以它可以循環修復 bug，而不用您本地重新編譯應用。 使用 .NET Native 時，您必須謹慎對待上傳至應用商店的程序包。因為應用商店為您執行本機編譯，所以您不能上傳本地 .NET Native 編譯器生成的本機二進制文件。Visual Studio 工作流將指導您完成該過程，以便您選擇正確的程序包。有關創建應用商店程序包的全面指導，請查看 MSDN 庫文章“Packaging Universal Windows Apps for Windows 10”（打包 Windows 10 的通用 Windows 應用），網址為?[bit.ly/1OQTTG0](http://bit.ly/1OQTTG0)。該文章將指導您完成程序包創建過程，以確保您生成并選擇要上傳至商店的正確程序包。 ## 使用 .NET Native 調試 如果您發現應用程序中某些問題可能是由 .NET Native 所導致，您可以使用一項技術來幫助調試該問題。默認情況下，發布配置全面優化代碼（例如，在很多地方應用的代碼內聯），這會丟失一些調試項目。因此，嘗試調試發布配置應用會很困難；您可能會遇到預料不到的步進和斷點行為，并且由于內存優化而無法檢查變量。因為發布配置的默認行為是使用代碼優化的 .NET Native 編譯器，所以很難調試可能是由 .NET Native 編譯過程導致的任何問題。 一個很好的解決辦法是，為采用 .NET Native 編譯器但未全面優化代碼的項目創建自定義生成配置。要創建自定義生成配置，請從版本配置下拉菜單中打開“配置服務器”，如圖 2?所示。 ? 圖 2 打開配置服務器 在“活動”解決方案配置下拉菜單中，選擇“”創建新配置，如圖 3?所示。 ? 圖 3 新建配置 為新配置提供日后對您有用的名稱。我想使用“Debug .NET Native”。 從“發布”生成配置中復制設置，然后單擊“確定”。 關閉配置管理器，通過右鍵單擊解決方案資源管理器中的項目并單擊“屬性”來打開項目的屬性頁。導航到“生成”選項卡并確保選中“使用 .NET Native 工具鏈編譯”，而且取消選中“優化代碼”，如圖 4?所示。 ? 圖 4 為調試 .NET Native 創建生成配置 現在，您擁有可用于調試 .NET Native 特定問題的生成配置。 有關使用 .NET Native 進行調試的詳細信息，請參閱 MSDN 庫文章“Debugging .NET Native Windows Universal Apps”（調試 .NET Native Windows 通用應用），網址為?[bit.ly/1Ixd07v](http://bit.ly/1Ixd07v)。 ## .NET Native Analyzer 當然，了解如何調試問題挺好的，但是能從一開始就避免問題豈不是更好？ Microsoft.NETNative.Analyzer ([bit.ly/1LugGnO](http://bit.ly/1LugGnO)) 可以通過 NuGet 在您的應用程序中安裝。通過程序包管理器控制臺，您可以使用下列命令安裝程序包： Install-Package Microsoft.NETNative.Analyzer。開發時，如果您的代碼與 .NET Native 編譯器不兼容，該分析器將會為您發出警告。有一小部分 .NET 接口不兼容，但是對于大多數應用而言，這根本不是問題。 ## 結束語 綜上所述，成為 .NET Windows 開發人員是多么令人激動的事情啊！憑借 UWP、.NET Native 以及對 NuGet 的更改，跨這么多客戶喜愛的不同設備創建應用從未如此簡單。您將有史以來第一次可以充分利用任何 .NET 類的最新進步，并且依然期望您的應用程序能夠在所有 Windows 10 設備上運行。 * * * Daniel Jacobson?*是 Visual Studio 的程序管理員，致力于研究面向 Windows 平臺開發人員的工具。您可以通過?[dajaco@microsoft.com](mailto:dajaco@microsoft.com)?與他聯系。*