Microsoft .NET Native 常见问题
是否支持 F# 或 VB 或我最喜欢的语言？
此预览版仅支持 C# 代码，因为它是大多数应用商店应用使用的 .NET 语言。但在我们拓宽工作重点之后，毫无疑问，我们会支持所有 .NET 语言。
此产品是仅与性能有关，还是也允许生成针对 Win32/64 本机编译并且不需要在目标计算机上安装 .NET Framework 的 C# 代码（举例来说）？
没错：.NET Native 不仅仅与性能有关，而且与工作效率和一致的设备体验有关。利用 .NET Native，您能够使用托管语言编写代码并且能够像往常一样上载 MSIL 包。但是，应用将作为完全自包含的本机编译代码部署在最终用户设备上（当 .NET Native 进入生产时），并且不依赖目标设备/计算机上的 .NET Framework。如您所知，.NET 应用程序的范围很广。因此，我们对完整的 .NET Framework 也进行了重大投入（例如，我们刚刚发布了 RyuJIT 的 CTP）。
设计此产品时考虑了哪些方案？
我们考虑过的方案是用于设备的应用商店应用 - 使开发人员能够保持 .NET 和 MSIL 的工作效率优势并且能够将 MSIL 包上载到应用商店，为最终用户提供性能类似的本机代码 (C++)（与 Windows Phone 8 类似，在云中进行编译）。
.NET Native 是否将取代 .NET Micro Framework 以及 C#/.NET 是否将完全可供小型设备使用？
.NET Native 当前的重点是 Windows 应用商店应用。Micro Framework 由 Windows Embedded 团队交付，.NET 团队与他们一起携手为客户提供最佳服务。
开发人员预览版是否适用于创建 Windows Phone 应用和库？
可以创建与 .NET Native 一起使用的通用类库。在此预览版中，仅 Windows 应用商店应用可使用 .NET Native 进行创建。正在实现使用 .NET Native 开发 Windows Phone 应用。
此产品能否提高 C# 开发人员开发高度图形化的应用和/或游戏的体验？
可以。.NET Native 编译器与 Microsoft C++ 优化器共享部分基本代码。
服务器/桌面应用是否将受益于 .NET Native 和/或云中的编译器？
桌面应用是我们策略中的非常重要的部分。最初，我们的重心是 Windows 应用商店应用与 .NET Native。从长远来看，我们将继续改进所有 .NET 应用程序的本机编译。
如何进行链接？框架代码是否将编译到应用程序中？这将如何影响包/二进制文件大小？
是的，框架代码将编译到应用程序中。对于包大小，由于大多数应用商店应用都有大量多媒体，因此差异不明显。 因此，代码大小确实会发生变化；但是，仅会将应用使用的框架部分链接到应用中。最终结果是，使用 .NET Native 编译的二进制文件将与执行 NGEN 的二进制文件处在相同的大小范围中。 我们仍将研究可进一步减少大小差异的策略。
使用 .NET Native 编译比使用 MSIL 编译慢。为什么？
常规应用开发使用 Visual Studio 中的标准 MSIL/JIT 开发体验。只有在将应用部署到设备才会调用 .NET Native 编译器，在大多数开发过程完成之后，重心将转移到应用的优化上。此时，编译时间与使用链接时间代码生成优化的 C++ 的差不多。
P/Invoke 有什么变化？是否会将它们优化为标准 DLL 调用？
即使对二进制文件进行本机编译，但我们保留了托管代码类型安全性（以及垃圾回收）和完整 C# 异常模型的好处。利用 .NET Native，我们还极大地优化了互操作路径 - 因此，尽管 P/Invoke 不会优化为标准 DLL 调用，但开销极低，以便执行 GC 同步和任何必需的封送。
有什么限制？此产品是否支持开放的泛型和反射？
.NET Native 将在进入生产时支持目标平台支持的所有功能。由于这是预览版，很多功能正在开发中，因此目前有一些限制。话虽如此，此预览版中支持开放的泛型和反射（是的，甚至支持静态编译！）。在此预览版中，编译器具有试图弄清运行时需要的泛型实例化和元数据的内置启发机制。因此，大量的应用有望直接运行，而不必简化源代码来获得编译器的好处。
如何修补这些应用或为这些应用提供服务？
应用的服务模式继续保持不变。对于框架，.NET 的最新模式是自动提供库更新。我们将继续探索选项；我们期待听到您的建议和意见。
如果删除了从未用过的方法，是否有某种方式表明某个方法（或整个类）已使用，即使从未直接调用过？
有；在此预览版中，支持开发人员声明某个方法（或类型）已使用，即使未直接调用（请查看运行时指令文档）。