Windows Phone8.1之后，开发者有三种选择。
- 继续用silverlight 8.0，反正向下兼容，如果APP也不需要新功能就这样吧。
- 升级到silverlight 8.1，如果需要8.1提供的新功能，silverlight8.0项目可以直接升级到8.1，然后开发新功能即可。
- 迁移到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框架了。
