使用 .NET 開發通用 Windows 應用程式

這篇文章是由 Managed Language 團隊的 Program Manager, Lucian Wischik 所撰寫。

我們前幾天釋出了在 Visual Studio 2015 中用來撰寫 Windows 10 應用程式的通用 Windows 應用程式開發工具，這個工具的發行令人感到興奮，因為您可以用最新的 .NET 技術來建立在所有 Windows 裝置上的 Universal Windows Platform ("UWP") 應用程式，這些 Windows 裝置可能是您口袋中的手機、背包裡的平板或筆記型電腦、桌上的 PC、客廳中的 Xbox 主機、以及正在加入 Windows 家族的新裝置如 HoloLens、Surface Hub 、以及 IoT 裝置如 Raspberry Pi 2 等。

安裝 UWP 工具

您可以安裝免費的 Visual Studio 2015 Community 版本，它預設就會安裝 UWP 工具，如果您安裝的是 Professional 或 Enterprise 版本，在安裝的過程中，選擇「自訂」安裝，然後勾選通用 Windows 應用程式開發工具的選項來安裝 UWP 工具。

如果您已經安裝了 Visual Studio 2015，有兩個方法可以取得這個新工具：

• 下載並執行 Windows 工具安裝程式。
• 開啟控制台中的程式與功能，選擇 Visual Studio 2015，然後按下變更，這時在安裝程式上選擇修改，然後勾選通用 Windows 應用程式工具。

UWP 有什麼新功能

對一個 .NET 開發人員來說，您會很高興看到 UWP 提供了...

• UWP 應用程式可以「視窗型式」在大量已升級至 Windows 10 的電腦桌面上執行。
• UWP 應用程式可以在手機、XBox、HoloLens、甚至是物聯網裝置包含 Respberry Pi 2 上執行。
• UWP 應用程式使用新的 .NET Core 技術，所以您可以使用這項最新的技術，輕鬆打造應用程式。
• 在您應用程式最核心的部份、商業邏輯的部份，都可以在支援 .NET Core 的平台或框架（如：ASP.NET 5）上重複使用。
• UWP 應用程式會與用到的 .NET 函式庫一起打包，所以您不必擔心應用程式在哪個 .NET 版本上執行的相容性問題。
• UWP 應用程式使用 .NET Native 技術來編譯程式，所以能讓應用程式啟動速度加快、降低耗電量、以及更好的執行效能。
• UWP 應用程式可藉由 Windows 市集發行，讓您的客戶便於購買及下載安裝。
• UWP 應用程式完美結合 Application Insights ，可用來進行遙測與分析，這對於瞭解您的客戶並改善應用程式來說是非常重要的工具。

而在這次發行的開發工具上，您可以：

• 使用 .NET 撰寫 Windows 10 UWP 應用程式。
• 建立目標平台為 .NET Core 的可攜式類別函式庫（PCL, Portable Class Library）。
• 比起之前的 Windows 市集或 Windows Phone 應用程式而言可以用到更多 .NET 函式庫，如：System.Net.Sockets、WCF Client、System.Numerics.Vectors 以及新的診斷 API。
• 您可選擇使用 NuGet 3.1 （相容 "project.json" 檔案）來存取 NuGet 上的套件。

立即開始進行 UWP 開發

這裡提供一些有用的關於 UWP 開發的概論介紹以及教學手冊：

• 建置 Windows 10 通用 app [MSDN] -- 透過自適應式 UI 及程式碼讓您的 UWP 應用程式在所有的 Windows 10 裝置上都能正常執行，同時介面正常。
• Guide to UWP apps [MSDN] -- 介紹「通用」應用程式如何支援所有的裝置。
• 將應用程式移轉至通用 Windows 平台 (UWP) [MSDN] -- 介紹如何從 Phone Silverlight、Windows 8.1 以及 VS2015 RC 移植應用程式。
• Developing Universal Windows Apps with C# and XAML [Microsoft Virtual Academy] -- 由專家 Jerry Nixon 所教學的總計 22 小時的實用課程。
• Developing UWP apps in VS2015 [BUILD talk]。
• Deep dive into XAML and .NET UWP development [BUILD talk]。

在這篇文章中，因為其它教學文件沒有特別提及，所以我們希望讓您知道，身為一個 .NET 開發人員，到底 UWP 的開發有什麼改良呢？首先，我們以 10 張圖片來介紹微軟提供給 .NET 開發人員什麼樣的新功能。

檔案 > 新增 > C#/VB > Windows > 通用 在這個項目下，開始建立空白的 UWP 應用程式專案，這個動作目前比起 VS2015 RC 來說快多了，這是因為我們在正式版中改良了 NuGet 的關係。而現在您也可以建立在 UWP、ASP.NET 5 以及 .NET 4.6 上共享的可攜式類別函式庫。

方案總管 > 參考 在專案中的參考節點中會以獨特的圖示顯示 NuGet 套件，而其中 Microsoft.NETCore.UniversalWindowsPlatform 這個套件很重要，它包含了 .NET Core 執行階段以及框架。而新的 project.json 檔案也取代了 packages.config 檔案，使用比起 NuGet 2.0 更快更有彈性的 NuGet 3.0。

自適應式 XAML 開發人員可以開發自適應式操作介面（adaptive UI）來適用於各種類型的裝置上，因為 XAML 技術的演進，現在有了 ViewState 觸發器、更多的裝置預覽畫面以及即時視覺化的 XAML 樹狀結構以便偵錯，當然，也加入了像 x:Bind 這樣的技術來提升資料繫結的效能。

自適應式程式碼. 通用型應用程式有個很棒的特色就是可以在不同裝置間共享許多程式碼，同時也能在每一個裝置上都有最好的使用體驗。現在您可以使用 .NET 、呼叫指定平台的 WinRT APIs 來撰寫自適應式程式碼，這比起在執行時使用 reflection 技術要好得多了。

快速圖形處理: Win2d 以及 System.Numerics.Vectors. 如果需要快速的圖形處理能力，就要使用 Win2d 函式庫，一個很棒的基於 DirectX 並且轉換成 .NET 容易使用的函式庫，當然您還是可以使用 SharpDX 或是 MonoGame。而 System.Numerics.Vectors 運用了 CPU 的 SIMD 指令來提供更快速的向量及矩陣運算，透過這些技術讓我可以在我的中階 Nokia Lumia 635 手機上只花 70ms 的時間就能畫出 Mandelbrot fractal 圖形。

WCF, HTTP/2 以及 Sockets. 在 .NET Core 函式庫中，已經加入了 WCF 以及 Add Service Reference 這些在之前的 Windows Phone 上無法使用的物件及方法，而 HttpClient 也重新改寫：除了有更好的效能以及支援 HTTP/2，另外我們也加入了 System.Net.Sockets 的支援，這是 .NET 開發人員一直希望能在 Windows 市集應用程式中使用的功能。

改良的除錯以及 EnC. 現在您可以在模擬器除錯時使用 "編輯及繼續" (EnC) 的功能，我們把整套偵錯引擎都翻修了，新的偵錯引擎支援在立即視窗及監看視窗中使用 lambda 以及 LINQ 表述式，以及比起之前在更多地方支援 EnC。有些開發人員會在 EnC 中撰寫他們全部的程式碼，不妨試試看！

.NET Native 當您以 Release 模式建置應用程式套件時，開發工具會使用 ".NET Native" 編譯器來編譯程式，所以它會將程式碼轉換成高度最佳化後的原生機器碼，這樣一來，應用程式將會啟動得更快、消耗較少的電池電量、以及提升整體的運作效能。

上架到市集 您應該很高興現在我們整合了開發人員中心，同時，當您要上傳應用程式時，上架程式精靈傳的是您應用程式的 MSIL，而市集會再使用 .NET Native 技術重新編譯您的應用程式成原生的機器代碼（這樣一來您的應用程式就會像 C++ 程式碼那樣一樣難反組譯），然後才提供給其它使用者下載。

Application Insights 以及診斷工具 在新的專案中預設都會加入 Application Insights 的相關套件，這可以幫助您瞭解應用程式詳細的分析資訊（例如當機或使用情形），頂尖的應用程式開發商都知道如何運用這些工具讓他的應用程式保持領先。另外也可以在 ETW（Event Tracing in Windows）中使用更豐富的追蹤功能。

.NET Native

.NET Native 採取預先編譯（AOT, ahead-of-time）的作法：當您在編譯程式時就轉成原生的機器碼，這與傳統 .NET 應用程式使用 just-in-time (JIT) 編譯是在程式第一次執行後才進行編譯是不同的概念，.NET Native 的運作更接近 C++ 編譯器的作法，而事實上，在 .NET Native 的工具鏈中也有一部份使用了 Visual C++ 編譯器，像是當您將應用程式上架到 Windows 市集時它就會運作，產生出更快、更輕巧的機器碼。

.NET Native 為終端用戶帶來許多好處：應用程式啟動速度平均提升了 60%，而且使用較少的記憶體。在我開發的一些 UWP 應用程式中，它們運作在 Nokia Lumia 635 上時，啟動速度從 1 秒提升至 110 毫秒，這一切都要感謝 .NET Native 以及 VS2015 中新的效能及診斷工具的幫忙。

您可以找到許多文章提到 .NET Native 預覽版本的內容，而 UWP 的開發是第一個正式採用 .NET Native 技術的領域，雖然在大部份的開發時間中，開發人員不會特別感受到 .NET Native 的存在，只有在以 Release 模式建置時才會發揮功能，而這也使得以 Release 模式編譯應用程式時會花點時間，當然也就不易偵錯以及搭配 Visual Studio 中的效能診斷工具，不過除此之外，它並不影響應用程式的正常運作。當然您還是可以使用 Debug 模式建置應用程式，由於它的執行環境是 CoreCLR，所以還是可以享受到絕佳的偵錯體驗，調整您的應用程式。

雖然 .NET Native 已經公開預覽超過一年的時間了，UWP 的開發讓許多開發人員第一次使用它，面對開發人員的好奇心，以及我們對這項技術的信心，我希望在本文後續的篇幅再詳細介紹它是怎麼運作的。

.NET Core 開發框架

關於 .NET Core 開發框架（"CoreFX"）已經在之前的文章有詳細的介紹：

.NET Core 是針對現代裝置及雲端平台所設計的新版本 .NET，它的一般化用途以及模組化設計讓它能輕易地被移植到許多不同的執行環境中，並且執行不同的應用程式。

UWP 應用程式使用 CoreFX，它是 Windows 市集開發 API 的超集合（superset）。

接下來讓我們特別提出幾個讓 UWP 開發人員覺得有趣的 .NET Core FX 功能：

• System.Net.Sockets (用來做 UDP 通訊) 在之前的 WinRT 應用程式中還不能使用，所以當時的開發人員必須使用 WinRT 版本的 UDP APIs，現在 System.Net.Sockets 已經是 .NET Core 的一部份了，所以所有的 UWP 應用程式都可以使用它，這同時也表示您可以與其它 .NET 應用程式共享 Sockets 部份的程式碼。注意：我們也正在讓 System.Net.Sockets 開放源碼。
• HttpClient (與 .NET Core FX 中許多低階 API 一樣) 在不同的平台上會有不同的實作，而對 UWP 應用程式來說，它是基於 WinRT HTTP 的部份所開發的，同時也預設使用 HTTP/2 的通訊協定（如果 http 伺服器使用 HTTP/2 協定的話），可以大幅減少資料傳輸的時間及次數。
• WCF Client (並且與加入服務參考對話盒關聯) 一樣在之前的 Windows Phone 應用程式中無法使用，但由於它已經被加入 .NET Core，所以 UWP 應用程式當然也能使用它。
• System.Numerics.Vectors 提供向量及矩陣的資料結構及運算，並且運用 CPU 的 SIMD (Single Instruction Multiple Data) 指令來做最佳化，這比起單純使用 "SISD" 指令碼做計算要來得快多了！
• System.Diagnostics.Tracing.EventSource 讓您可以在您的事件中送出更完整的訊息到 ETW (Event Tracing for Windows) 中。

使用 Core FX 有兩件令人興奮的事，一個是它完全開放源碼，另一方面則是不綁定特定版本的 Windows 或 Visual Studio，任何人都可以像 .NET 團隊一樣每天更新貢獻程式碼，這個團隊與社群合作不斷擴充 CoreFX 的功能並且加入更多 APIs，而 UWP 應用程式中都可以立刻使用到這些新加入的 APIs，感謝 project.json 以及 NuGet 的整合，任何 UWP 開發人員都可以透過「管理 NuGet 套件」對話盒來取得最新版本的 .NET Core FX 套件。

注意當您新增專案時，開發工具會代入完整官方並測試過的 Microsoft .NET Core 組建，如果您想要使用其它的版本函式庫，不是在「參考 > 加入參考...」中加入，而是使用「參考 > 管理 NuGet 參考」來加入這些函式庫。

如果您正在開發 .NET Core 函式庫，您可以撰寫 PCL（Portable Class Libraries，可攜式類別函式庫）並且目標平台選擇 .NET 4.6、UWP 以及 ASP.NET 5。

通用專案

UWP 帶來的新概念讓您能夠撰寫通用型 (universal) 專案，這表示只需要在 Visual Studio 中開啟一個專案、同樣的程式碼、上傳單一套件至 Windows 開發人員中心，就能夠讓應用程式執行在多重「裝置家族」（包括桌上電腦、行動平台、XBox ......）上，您不必再另外開啟一個共享專案，然後使用 #ifdef 這類語法來表示平台的不同，這樣一來，應用程式的專案也就更容易維護了。

在 MSDN 上有一篇文章「Guide to UWP apps」說明了要如何讓您的應用程式在不同的裝置間依然可以看起來很棒，令人開心的是，通常只需要根據不同的視窗大小調整介面就能在所有的裝置上正常運作。

從 .NET 的角度來看，技術上可以使用自適應程式碼（adaptive code）的方式來做就可以，以下是個例子：

我的應用程式在 Windows 10 桌面環境上可以正常運作，而在 Windows 10 行動裝置上便會顯示狀態列，為了一致性所以我呼叫了 StatusBar.HideAsync 方法來隱藏狀態列，然而在桌面環境並不存在 StatusBar 這個物件，所以這段程式碼用了很簡單的方式來處理——透過 WinRT API Windows.Foundation.Metadata.ApiInformation.IsTypePresent 來確認某個 WinRT API 在當下的執行環境中是否存在，所以下面的程式碼只會在特定的平台上才執行。

有時候很難判斷您想使用的 API 是否需要使用 IsTypePresent 方法來確認，所以您可以使用一個 NuGet 套件 PlatformSpecific.Analyzer，把它加入到專案後，它就會分析您是否忘記確認，然後在 IDE 中顯示警告訊息。

上面這段很有趣，因為在 .NET 開發中，自適應程式碼（adaptive code）的概念目前只能在 UWP 平台中使用，而且只能針對 UWP 類別物件所使用，低階 .NET 專家會很想瞭解這是怎麼做到的。在 Debug 模式建置的應用程式中，CoreCLR 需要能 JIT 您的 SetupAsync 方法，而為了做到這點就必須知道所有類別的 metadata，以及每一個方法（即使程式中沒有呼叫）的內容，UWP 透過打包進一個應用程式本地端檔案「windows.winmd」來處理這些方法及類別，在 windows.winmd 檔案中包含了 UWP 在每一個裝置版本上所有的 WinRT 類別及方法；而在 Release 模式下建置的應用程式，.NET Native 會將必要的 metadata ，以 COM IIDs 以及 vtables 的形式放進最終編譯的機器碼中。

最後我還是想強調關於在自適應式應用程式中使用 PCLs 的注意事項，因為這對您將既有的程式碼放進 UWP 中是個很重要的概念，如果您曾經開發了「8.1 Universal PCL」目標平台同時是 Windows 8.1 以及 Windows Phone 8.1，那您的 UWP 應用程式還是可以參考使用它，這是因為這類型的 PCL 只會呼叫 WinRT 的子集合，當然也是 UWP 的子集合。

NuGet 3.0 以及 "project.json"

NuGet 已經成為 .NET 應用程式開發的套件管理標準，我們也希望將 .NET Core 放上 NuGet 成為套件的形式來發佈，但是現有的 NuGet 2.0 用戶端以及搭配的 packages.config 檔案，雖然過去是個很棒的設計，但是現在已經不太適用於像是 .NET Core 這樣有超過 100 個子套件的使用情境，因為不但效能低落而且也沒有彈性。NuGet 3.0 修正了這些問題，一開始是在 ASP.NET 5 中使用，現在 UWP 也採用了新的 NuGet。

您可以很容易地判斷一個專案是否使用 NuGet 3.0，因為它使用 project.json 檔案取代了 packages.config，您可以在任何既有的 .NET 專案中使用 NuGet 3.0 以及 project.json，並不會影響開發工作（不過要先卸載再重新載入專案），而 project.json 檔案能順利運作的關鍵在於：

1. 當您安裝 NuGet 套件，參考的資訊就會加入到 project.json 檔案中，而且可以在方案總管中的參考中看到這個套件。
2. 在建置之前，Visual Studio 會確保所有的 NuGet 套件（包含相依的套件）已經下載到使用者本機上的快取目錄中，而且會根據專案的目標平台來選擇正確的版本。注意：可以獨立執行的「nuget.exe」命令列工具很快就會獨立於 Visual Studio 來發行了。
3. 在建置期間，如果專案中有 project.json 檔案，MSBuild 便會根據檔案內容選擇合適的 DLLs 以及 .targets 檔案來加入建置內容。

而接下來讓我們看一下使用 project.json 究竟帶來哪些好處：

• 在您的 .vbproj/.csproj 中不必再包含 NuGet 的參考：這個部份完全獨立開來，也可以讓您在做版本管挖或是合併衝突的操作上更加輕鬆。
• 您可以任意切換您應用程式的目標平台、切換 Debug/Release 以及 x86/x64/ARM/AnyCPU 等設定，NuGet 會很完美相容這些設定。
• 您現在可以在不同的目錄的不同專案間使用相同的 NuGet 套件，這對於同時開發不同專案的開發人員來說相當方便。
• 在方案總管中的參考節點看起來更清爽，因為這裡只會顯示您安裝的套件而沒有其它相依的套件，移除 NuGet 套件也很簡單，因為您可以直接移除當初選擇安裝的套件，而不必一個個移除相依的套件。
• 套件會快取在同一個地方（同一個使用者下），所以不必換到不同的專案就要重新下載它們。
• 新增專案以及管理 NuGet 套件時的速度都變快了。
• 您可以更有效掌握 NuGet 套件的升級，以及它所使用的版本。

我們建議您透過閱讀 NuGet 團隊部落格以及拜訪 NuGet Home repo 來瞭解 NuGet，您可以在這些地方與 NuGet 團隊進行討論。

下列 NuGet 套件並不是用相同的方式裝進 UWP 應用程式中，如果您還發現了其它有問題的套件，歡迎讓我們知道：

• SharpDX.Toolkit 2.6.3. 升級至 SharpDX 3 （目前還是 alpha 版本），這個版本可以相容於 UWP 應用程式。而 SharpDX Toolkit 已經過時而且不會移植到 SharpDX 3，也不能安裝到 UWP 應用程式中，其它類似的替代方案可以考慮使用 Paraox 或是 MonoGame。
• MvvmLight. 這個 NuGet 套件本身是支援 UWP 應用程式的，只是要多一個步驟來安裝它，原本這個套件安裝完會在 App.xaml 檔案中加入一些內容，同時在專案中加入一些檔案，但在 UWP 的專案中就不會做這些事情，所以您必須手動完成，或是使用 MvvmLight VSIX 來安裝。
• Sqlite-net. 雖然這個 NuGet 套件不再支援 UWP 應用程式，但可以使用相同的 Sqlite.Net-PCL (同一個作者開發的) 套件。
• LiveSDK. 這個 NuGet 套件雖然在安裝時宣稱安裝成功，但是在參考 DLLs 時就會發生錯誤，一個簡單的作法就是手動加上 Microsoft.Live.dll 的參考（要在哪裡找到這個 DLL？最簡單的方法是在 UWP 專案中加入 LiveSDK 的參考，然後到 NuGet 的下載目錄 %USERPROFILE%\.nuget\packages\LiveSDK 中找），或是如果您只是要使用帳號登入的功能，可以選擇使用 Windows.Security.Authentican.OnlineID （可見說明），或是使用 OneDrive 的話可以透過 HttpClient 來存取它的 REST APIs。

順帶一提，project.json 檔案預設用在「現代化」的 PCL 上，也就是那些目標平台是 .NET 4.6、UWP 以及 ASP.NET 5 Core 的 PCL。

UWP 應用程式在偵錯時使用 CoreCLR、發行時使用 .NET Native

下面這張圖表顥示了當您建置、偵錯以及上架應用程式時到底發生了什麼事，VB 及 C# 編譯器跟之前一樣繼續會以 MSIL 格式來散佈 DLLs 檔案，而不同的的地方在於...

Debug 建置: CoreCLR. 當您在 Debug 模式建置您的 UWP 應用程式時，它會使用 ".NET Core CLR" 作為執行階段，這點與 ASP.NET 5 相同。它提供了很好的 編輯+執行+除錯 的操作體驗：快速部署、完整除錯功能、編輯及繼續執行。

Release 建置: .NET Native. 當您在 Release 模式下建置時，它會多花超過 30 秒的時間將您的 MSIL 以及引用的參考優化成原生的機器碼，我們持續在改進這個部份，它使用了 "tree-shaking" 的技術移除了完全沒有被使用到的程式碼，也使用了 "Marshalling Code Generation" 技術預先編譯及序列化程式碼，所以不必在執行階段才做 reflection。.NET Native 技術會對整個應用程式做最佳化，如此一來不僅是將程式編譯成原生的機器碼，並且產出單一原生 DLL 檔案，您可以在 bin\x86\Release\ilc 目錄下找到它。

**.NET Core: CoreCLR 與 .NET Native 都是「.NET 執行環境」，它們都使用相同的 .NET Core 函式庫（CoreFX），所以程式在 Debug 及 Release 模式下都會有相同的表現，在 Windows 8/8.1 中，使用的是為 Windows 市集應用程式打造的 .NET 環境，現在我們已經將 UWP 完全地使用 .NET Core 並且存取新的 CoreFX 函式庫，藉此能在 debug/release 模式下有相同的行為。

上架到市集. 當您建立好 Appx 套件準備要上傳到 Windows 市集時，appx 的內容含有 MSIL 碼，而 Windows 市集便會使用 .NET Native 來編譯您的套件，這能降低開發人員對於部署使用 .NET Core FX 應用程式的疑慮，他們擔心萬一 .NET 發生安全性問題時要如何解決，以往的做法都是透過 Windows Update 更新系統的 .NET 執行環境，現在可以只要修正 appx 套件內的 .NET Core 即可。

使用 .NET Native 開發的技巧

在 Release 模式下測試應用程式. 請確保您會定期地使用 Release 模式建置並測試您的 UWP 應用程式，Release 模式使用 .NET Native，如果您定期（在開發時我會每 4 個小時測試一次）進行測試，您便能即時發現問題，像是 Expression.Compile 不同的效能表現。如果您在測試時發現問題，並且想要進行偵錯，請注意 Release 模式已經經過最佳化，所以您可能會想關閉最佳化來取得更好的偵錯體驗。

.NET Native 分析器. 有些 .NET 功能在 .NET Native 中還不支援，像是超過四維的多維度陣列，當您在使用 .NET Native 進行編譯時就會通知您，不過若是您希望在進行長達 30 秒以上的編譯前就發現不支援的部份，可以安裝 Microsoft.NETNative.Analyzer 這個套件，它會在您撰寫程式碼時，發現 .NET Native 不支援的部份便會提出警告。

AnyCPU 已經不用了. 由於 .NET Native 會將程式碼轉換成原生的機器碼，對於開發人員來說，使用 AnyCPU 已經沒什麼意義了，您只需要記住要部署到本地機器或是模擬器上時要選擇 x86，而要部署到 Windows 10 行動裝置上選擇 ARM，在您建置要上架到市集的應用程式套件時，套件製作精靈會協助您產生 x86/x64/ARM 三個平台的套件，並且打包在一起。

如果您正在開發類別函式庫或是 PCL，這時就應該選擇「AnyCPU」，這樣會讓事情簡單一點，您只需要散佈一個 DLL 便能讓所有類型的專案來使用。

一個最簡單的作法就是在建置 > 組態管理員對話盒中，即使工具列上顯示 AnyCPU，您還是可以設定 UWP 應用程式在建置及部署時都使用 x86 平台。

在 .NET Native 下偵錯. 有時候您會希望設定中斷點或是偵錯 .NET Native 編譯後的程式碼，當然最好不要這麼做，因為這會讓偵錯變得很困難，而且 .NET Native 使用了大量的最佳化技巧後，會讓偵錯更加困難。如果非這麼做不可，那建議使用 Debug 模式，但是在專案設定下開啟 .NET Native 的設定。以 C# 專案來說，它在專案 > 內容 > 使用 .NET Native 工具鏈來進行編譯；而 VB 專案則在我的專案 > 建置 > 進階下。

自訂 .NET Native 最佳化. 有時候程式開發會使用 reflections，.NET Native 可能會因為最佳化的操作將這些程式碼移除，而這是您可以控制的，可以參考下列這些部落格的說明：

1. Dynamic features in static code.
2. Help! I hit a MissingMetadataException!.
3. Help! I didn't hit a MissingMetadataException!.
4. .NET Native deep dive: making your library great.
5. .NET Native deep dive: optimizing with Runtime Directives.

*Expression,Compile* . 我想將這個部份獨立開來討論，因為這個在 Newtonsoft 的 Json.NET 中用到很多，所以會影響到很多開發人員，在傳統的 CLR 中，表述式樹（expression-tree）會在執行期間被編譯成 MSIL，同時 JIT 會將它們轉換成原生碼，這在 .NET Native 中是不可能的，取而代之的是解析這些表述式樹，這項改變也許您會在 Json.NET 中觀察到它的效果，它會更快速啟動（因為不必再啟動 CLR 處理表述式樹的部份），但是在序列化大量資料時會變慢，所以請您務必測量這些變化會如何影響您的應用程式，在我的經驗中，我的應用程式因為這項改變加快了約 200ms 的啟動時間。

F# . F# DLLs 不能在 UWP 程式中使用：因為它們還不支援 .NET Native，我們會改善它，如果這對您很重要，也請不吝告訴我們。

取得支援。如果您在 .NET Native 上遇到問題，歡迎您寄信至 dotnetnative@microsoft.com 尋求協助。

結論

這次通用 Windows 平台的發行為 .NET 開發人員創造了一個重要的機會，您可以透過 UWP 應用程式觸及更多的用戶，而且您可以使用最新的 .NET 技術來開發這些應用程式。

請您們試試看，然後不吝告訴我們您的想法，如果您在開發上有任何問題，歡迎到 Windows 開發中心上的 "Developing Universal Apps" 論壇上尋求協助。最後，感謝 .NET Native 技術，您會發現您的應用程式可以在 200ms 以內啟動完成！

 

這篇文章翻譯自 Universal Windows apps in .NET