Windows runtime 为什么WinRT的托管版本不包括对.NET API的访问？

最近，我开始使用C#在WinRT中为Windows应用商店应用程序（以及即将推出的Windows 10通用应用程序）工作。之前在.NET中工作了一段时间后，我很兴奋能在移动设备上使用.NET，但却发现WinRT一点都不像家

我经常发现自己不得不寻找我在.NET中熟悉的某些类的替代品，因为它们通常不相同，甚至在WinRT中实现。我认为缺乏实现是因为WinRT的核心是非托管的，即使CLR从托管代码绑定到WinRT

我的问题是：是什么阻止了Microsoft允许开发人员从托管代码中导入和使用所有熟悉的.NET类，即使WinRT从后面运行？我知道这不是设备的限制，因为我的Surface Pro可以很好地运行桌面.NET应用程序，Mono项目已经成功地将几乎整个.NET API移植到各种设备上

---

谢谢你的意见

这是一个很大的话题，但有三个基本原因导致您无法从Windows应用商店应用程序获得完整的.NET API

这些API不适合手机等小型设备。由于通用Windows平台的目的是让应用程序可以在任何地方运行，因此它不能包含资源密集型（磁盘、内存、CPU等）无法在小型设备上运行的API。（请注意，即使托管API看起来很小，它也可能依赖于大的基础Win32 API）

这些API与应用商店模型不兼容。许多需要未授予应用商店权限的API都属于这一类，使应用程序能够对您的机器执行“不需要的”操作的API也属于这一类（不必要的程度是主观的）

这些API已被弃用，或者有更新的替代方案。Windows 8中的许多API就是这种情况，在Windows 8中，文件系统访问和网络套接字等内容被阻止从应用商店应用程序中访问，因为有更新的WinRT等价物

---

请注意，Microsoft始终愿意重新评估是否应包含特定API。例如，Windows 10带回了许多在Windows 8.1中被禁止的API（例如

System.IO

和

System.Net.Sockets

），并扩展了授予应用程序的功能。您可以通过Windows feedback应用程序提交反馈，或者如果您希望带回其他API（添加详细的理由永远不会有什么坏处）。

现在，似乎有一半的Microsoft公司在努力销售Surface Pros，让人们留在以Microsoft为中心的世界中，而另一半公司正在将.NET推向开源/Unix世界。我不确定你能不能想出一个合理的理由来解释这些天雷德蒙德出现的许多事情：）.NET程序员唱着王子的歌，“像1999年一样去聚会”。现在已经不是1999年了，计算与那些简单的日子有着根本的不同。回到过去，你总是可以指望机器变得越来越快。今天，它是一个拥有移动设备的高度网络化的世界。WinRT是一个完全不同的操作系统api，旨在处理延迟和极低的功耗要求。比如说，苹果的OSX和iOS是不同的。“在它上面运行的东西，如.NET，必须符合要求。@Hans Passant正如我在问题中所说的，大多数Windows 8.1 Pro平板电脑运行桌面程序都没有问题。事实上，从早期的.NET时代起，移动硬件实际上已经超过了桌面硬件，而且自创建afaik以来，其核心功能并没有显著变化。即使我可以在我的平板电脑上同时运行15个不同的.NET桌面程序（这可能不太关心WinRT），一个前台Metro应用程序也不能使用.NET？这对我来说还不算什么。这是他们在设计和技术上做出的决定。WinRT是新代码（至少不使用太多已有15年历史的.NET旧代码）。我很高兴听到微软对开发人员的反馈持开放态度。希望随着项目的进展，API会感觉更加统一。