Windows Phone8.1之后，開發者有三種選擇。

1. 繼續用silverlight 8.0，反正向下兼容，如果APP也不需要新功能就這樣吧。
2. 升級到silverlight 8.1，如果需要8.1提供的新功能，silverlight8.0項目可以直接升級到8.1，然后開發新功能即可。
3. 遷移到windows phone Store APP(也就是Windows Runtime)，這個推薦，這個可以最大化和Windows共享代碼，Win/RT/WP 8.1的通用程序也需要遷移到Windows Runtime。

后面就不討論silverlight了，只討論Windows Runtime，之前泄露的SDK還分別稱Windows Phone Runtime和Windows Runtime，也就是WPRT和WinRT。

而這次的RC版，微軟已經統稱Windows Runtime，已經淡化Windows Phone Runtime了。

一張圖說明問題，windows.winmd，也就是Windows Runtime提供的API：

圖中分別列出了Win8.1,WP8.1,和WP8的windows.winmd的API，下原圖對著看一幕了然：

（點擊看大圖）

看了這張圖，就明白微軟為何不刻意區分WPRT和WinRT了，因為已經高度統一了。

WP8.1和Win8.1的WinRT已經高度統一了，不像WP8的WPRT不但大量API缺失，還有不少是Windows.Phone.xxx手機專用命名空間。

MSDN上也統一為Windows Runtime APP開發文檔了，不過手機PC畢竟還有一些區別，所以有PC和手機圖標表明該功能的適用場景(如圖

下面我首先看了下自己比較關注的方面，文件訪問。

WP8.1已經有和Win8/RT同樣的文件選擇器，Windows.Storage.Pickers.FileOpenPicker。

看看效果，兩個使用方式基本沒有差別，不過實際效果嘛：

• Win8.1：可以選擇SkyDrive，本機磁盤，網上鄰居的共享文件，甚至第三方應用提供的接口的文件選擇。
• WP8.1：不錯，沒Win8.1這么強，但已經可以自由瀏覽可訪問的目錄，包括SD卡，而且SD卡已經有寫入權限，不用走后門了。

以后第三方軟件，就可以自由打開保存文件了，例如下載視頻歌曲等文件，就可以下載到SD卡，其他軟件也可以訪問。

雖然說表面看來，WP8.1和Win8.1的WinRT已經非常接近了，但實際還是有所不同的。例如Windows.UI.Xaml.Controls.Pivot是WP上的樞紐視圖控件，在Win8.1上就木有。例如Windows.UI.Xaml.Controls.Hub在WP8.1和Win8.1上都有，但展現形式不同。WP8.1上就是以前的全景視圖的樣子，Win8.1嘛，你知道的。

就跟Windows.Storage.Pickers.FileOpenPicker，都是文件選擇器，用法也基本一樣，但功能和展現形式不見得一樣。

PS：winmd是什么，可以認為是新一代的dll，winmd程序集可以被C++，C#，JS調用。winmd包含元數據，意思就是調用winmd程序集就像調用Net的類庫一樣簡單。

反正我覺得8.1開始，是很有必要遷移到Windows Runtime了，特別是要跨平臺(Win8/RT/WP)開發的。Windows Phone和Windows 8.1的Windows Runtime既然已經如此靠近了。未來就算改也是更接近而已，繼續加強Windows Runtime而已。基本不可能退到Windows Runtime。

還有就是Windows Runtime本身就是Native Code，而Silverlight是Managed Code。目前，微軟的C#也開始支持直接編譯Native Code了，這個已經開始beta了。感覺上技術還是那些技術，silverlight是XAML+C#，Windows Runtime也是XAML+C#，但本質已經有所不同了。未來C#可能不再運行在.Net框架上，而是直接編譯native code了。

可以理解為C++的運行效率，C#的開發效率么？

唉，C#可以編譯Native Code的工作早點想起來做，讓C#可以脫離Net框架運行，或許Winform早占領桌面程序了。至少我最關心的一點，第三方程序，可以打開有權訪問的任意目錄了，第三方程序不用走后門，也可以讀寫寫SD卡了。

反正我覺得8.1開始，是很有必要遷移到Windows Runtime了，特別是要跨平臺(Win8/RT/WP)開發的。但我覺得silverlight可能到頭了，雖然WP8.1新加的功能，silverlight8.1仍然提供支持，8.0項目可以直接升級silverlight 8.1享受新功能。但我很擔心未來WP8.2如果帶來新特性，有可能木有silverlight 8.2了。就像當年的XNA，只是兼容XNA開發的已有程序而已，XNA本身已經不會更新了。

未來不需要兩種不同的C#+XAML。

當年Windows Phone和Windows不是一個部門，而且WP部門的理念完全不同于Windows。不然WP8.0就該兼容WP7的silverlight時，保留盡量完整的Windows Runtime了。畢竟WP8.0和Win8同期開發的，Win8一開始是完整的Windows Runtime，而WP8.0卻是個渣。同期開發的東西故意把WP的Windows Runtime搞的面目全非，現在才來補全，根本說不過去。

你看RT和Win8都是Windows 部門的，多好，除了ARM不兼容舊桌面程序外。它們從內到外都做成一個樣子，月經補丁一起打，8.1,8.1 Update都同時升級。我覺得5年前也就是Win8和WP8開始開發的時候，WP和Windows屬于一個部門。那么WP8.0一出生，Windows Runtime就不可能相對Win8如此殘缺需要現在慢慢補回來。

如果WP一開始就是Windows 團隊開發，Windows團隊一定是想著怎么盡量共享代碼。去掉桌面，精簡體積，為手機優化界面功能，兼容WP7的silverlight應用。記得當年，live.com上面維護的聯系人分組和頭像，和Windows Phone 7同步到人脈的分組和頭像，完全不相干。你就知道，大公司病多嚴重，各部門溝通多差。

Windows Runtime是Native code，是Win32 com的新的封裝形式。但加入一個很重要的特性，就是元數據，使得調用WinRT如同Net 類庫一樣簡單方便。以前C#就算預編譯，仍然無法脫離Net框架，是因為框架本身的程序集都是運行在Net虛擬機上。所以以前只是所謂的預編譯，不能整整的Native code，所以C#直接編譯和所謂預編譯沒有本質區別了。只是先后的問題，比預編譯再早一點而已，類似的還有云編譯，都是先后問題，沒解決本質問題。

所以以前談C#直接編譯Native code是根本沒有意義的，都要運行在.net框架下。而現在，一套類似Net的原生庫已經有現成了就是WIndows Runtime，雖然其目前無法代替Net框架。所以C#直接編譯Native code，也就變成順理成章的事情。

Windows Runtime絕對不是.Net升級版，基本上除了借鑒Net的元數據，讓開發友好跨語言調用，其他方面沒有任何相同點。winrt和.net不存在合并，否者就不會發展獨立發展Windows Runtime了。一個是在.Net虛擬機上提供了一套API。一個是Win32 com基礎上實現了一套API。借鑒了Net的元數據，使開發更加容易。意思就是把本質根本不同的東西。做的表面上一樣，使用Windows Runtime和使用Net框架一樣友好。

開發者以前用C#開發Net程序，現在用C#開發Windows runtime程序，除了API的了解，可以說沒有學習成本。而讓Net程序員從winform開發桌面程序改為用C++開發桌面程序，可以說是非常高的學習成本。但這兩個本質不同的東西，功能存在大量重疊，開發者使用起來也差不多。就像VB和C#都可以做Net開發的感覺，共存。但共存總有一個熱門一個變得冷門。

可能隨著Windows Runtime的成熟，桌面也就是Windows Runtime的天下了。Net退居于服務端了。因為基于Net的第三方資源不可能都重建。例如MVC，例如Entity Fremework，基于Net框架的很多項目都是獨立在發展而且已經有很大市場。所以Windows Runtime并非要取代.Net框架，也沒有打算去實現Net框架的那一面。

Windows Runtime應該沒有打算去參合Net用于網站那一部分。由于Windows Runtime并未去重復Net框架的很多功能。所以做開發，可能一邊用Net框架， 一邊用Windows Runtime。例如你想要用到的一個第三方組件Json.Net是基于Net框架的等等。Windows Runtime是原生代碼，Windows Runtime可以被C++，C#，JS調用。意思就是未來基于Windows Store開發，C#可能擁有和C++類似的地位。

以前都是C#快速開發， 核心算法部分可能還是C++。未來更多的東西可以C#通吃。

Windows Runtime有些功能仍然是通過Win32 API實現不能脫離Win32 API，但就Windows Runtime本身來說是如同Net框架一樣友好的

總結就是：Windows Runtime是新時代的Win32 api，借鑒了net的易用性。

但目前沒發現，要用它取代Net的的想法。

Windows Runtime主要是Windows本身的開發，就像以前Win32做桌面應用，現在WIndows Runtime做跨平臺觸屏應用。現在乃至未來可以預見的時間，都不會取代Net。微軟自己維護的一些基于Net的開源項目，例如MVC3,4,5框架,Entity Framework等，都不會基于Windows Runtime重建。Windows Runtime絕對不是.Net升級版，基本上除了借鑒Net的元數據，讓開發友好跨語言調用，其他方面沒有任何相同點。和Net完全沒有繼承性，所有API都是與Net無關的重建的一套原生的實現。

首先第一點，根本的一點，Windows Runtime本身都是原生代碼，并非運行在虛擬機上，原生的實現或是對Win32 api之類的直接調用。簡單粗暴的理解，就是com加上元數據，沒有什么中間語言，所以除了C++加Windows Runtime，自始至終是原生代碼。之前用C#+Windows Runtime就會出現一個很尷尬的局面，就是同時在用Net框架和Windows Runtime。本質有點類似于以前Net程序Interop調用Win32 API的感覺，只是說現在使用的是更友好的Windows Runtime。

所以C#能像C++一樣編譯原生代碼，脫離Net框架，在WIndows Runtime出現后，也就變得順理成章。

以前Net的本身是中間語言，本是運行時的即時編譯，所謂的優化手段例如安裝后或后臺預編譯，甚至后來的云編譯。

無非是編譯的時機不同，把運行時影響速度的即時編譯改在了運行前準備好，沒有改變運行在Net框架上的本質。

而這次，Net Native時C#基于Windows Runtime，是真的徹底的原生代碼，至始至終都可以獨立于Net框架了。