我想沿着将 WPF/Silverlight 组件移植到 Windows 8 的路线。对于一些上下文，该组件是一个实时 WPF Chart，它使用 WPF/XAML 和位图渲染的混合来实现高表现。
我希望该组件与 Metro 兼容，例如用于 Metro 模式和桌面模式。我阅读了很多关于在 Windows 8 中创建C++/WinRT应用程序以及C#/XAML应用程序的内容，但是这两个框架之间有什么区别？
如果您选择 C#/XAML 而不是 C++/XAML，是否有限制？还要考虑从 .NET4.0 中的 C#/Xaml 移植到 Windows8 会容易得多，如果我可以坚持使用 C#/XAML，但是我能否使用这种方法创建功能齐全的 Metro 组件？
您的意见/建议表示赞赏。
编辑：
如果您投票关闭此线程，请发表评论原因。这是一个有效的问题，有 +6 票，四个答案和一个最爱。把它留给我似乎是合理的！
我将差异视为设计选择，而不是个人对语言的偏好。偏好与 VB 与 C# 更相关。通常，在您选择 C++ 或 .NET 的任何应用程序中，您会得到相同的差异。
C++ 将为您提供更快的启动时间。IIRC，.NET 4.5 具有自动 NGENing 功能（不确定它与 Metro 应用程序的关系），因此这可能有助于缓解 .NET 应用程序典型的缓慢启动时间。
C++ 将降低一般内存使用量，因为它不使用垃圾收集器。这在平板电脑等资源受限的设备上变得越来越重要。IIRC，.NET 4.5 对 GC 暂停有更多的缓解（这可能导致 UI 崩溃），它们仍然是托管代码的现实。
由于 .NET 和 C++ 使用相同的 WinRT 框架，因此与 XAML/WinRT 平台交互可能不会有太大差异（通过 C++ 与 WinRT 对象交互在技术上更快，但影响非常小），但当然你的用户使用 C++ 编写的代码通常比使用 .NET 更快。
C++ 通常更难逆向工程，即使与模糊的 .NET 代码相比也是如此。尽管狡猾的小偷无论如何都可以窃取您的IP。
由于 .NET 最初是为了方便开发人员和开发人员的生产力而创建的，因此您在构建应用程序时将拥有更多方便的选择（例如，基于反射的工具，如 DI/IoC）。
通过 .NET 迭代应用程序代码可能更容易，因为 .NET 的编译速度比 C++ 快，但正确创建的 C++ 项目可以大大缓解这种情况。
纯 .NET 项目可以支持“任何 CPU”，这意味着您的应用程序可以在所有受支持的 WinRT 平台上运行。您只需重新编译 C++ 项目即可支持 ARM、x86/64。如果您的 .NET 应用程序依赖于自定义 C++ 组件，则必须针对每个体系结构进行编译。
因为 WinRT 是从头开始创建以支持多种语言的，所以我对不熟悉 C++ 的开发人员的建议是坚持使用 .NET，但探索受益于 C++ 的领域。Microsoft 在 /CX 预测方面做得很好，大多数 C# 开发人员应该能够找到自己的方法。我对 C++ 开发人员的建议是坚持使用 C++ 并获得 C++ 的所有好处。
从XAML的角度来看，它成为一种语言选择。无论您在此处选择哪种代码语言，XAML UI 堆栈都是相同的。根据您的应用程序目标，如果您需要 C++ 为您提供的优势，使用 C++ 可能更有意义。
我们现在还可以在 Win8 中混合 DirectX 和 XAML，这通常意味着 C++——但是对于像 SharpDX 这样的项目仍然不完全有效（是的，我意识到你将在 DirectX 中为包装托管代码付出性能损失...我只是指出可以做到）。
您的问题似乎是关于创建可在桌面和 Metro 中使用的可重用组件。这可能有点挑战性，具体取决于您如何构建它，因为需要对如何从文件位置加载资源（即，generic.xaml）而不是从嵌入式资源进行一些更改。
我能想到的使用 C++/XAML 的唯一优势是速度是否对您的项目很重要。C#/XAML 的优点是更容易编码，特别是如果您的项目已经在 C# 中。
到目前为止，还没有办法在 Windows 8 中制作同时针对 Metro 和桌面的应用程序。
希望这可以帮助。
好吧，其他人可能知道更多，但基于微软对我在 WinRT 发布时间提出的问题的回答：
WinRT 是一种协议和一组原生 API，允许每种语言保持其现有执行环境的真实性 - 用于 JavaScript 的 Chakra、用于 C# 的 CLR 和用于 C++ 的 CRT/原始本机代码。
这表明我们目前使用 CLR 与本机代码访问本质上是本机代码 API (WinRT) 的体验类似的性能权衡。但我期待看到对此进行一些实证调查，以了解 WinRT 的不同之处。