通用 Windows 平台应用程序和 C++/CLI (VS 2015 RC1)
Universal Windows Platform Apps and C++/CLI (VS 2015 RC1)
我有一些源自 .NET 系统命名空间的 C++/CLI 代码 类。
有没有办法为通用 Windows 平台应用重用此代码？
我无法在 C++ 中获得对系统命名空间的引用，但在 C# 中是可能的。看起来只支持 C++/Cx 代码，不支持托管 C++/CLI。
C++/CX 扩展的语法和关键字与 C++/CLI 非常相似。但这就是相似之处的终结，它们没有任何共同点。 C++/CX 直接编译为本机代码，就像本机 C++ 一样。但是C++/CLI被编译成.NET的中间语言MSIL。它们的语法看起来非常相似，因为它们都解决了相同的问题，将 C++ 连接到外部类型系统。 .NET 在 C++/CLI 的情况下，WinRT 在 C++/CX 的情况下。
这是不能使用 System 命名空间的根本原因，它是一个 .NET 命名空间。您改为使用 std 命名空间，以及用于 WinRT 特定类型的 Platform 和 Windows 命名空间。编译器无法导入具有有效 /ZW 编译选项的 .NET 参考程序集，只能导入 WinRT 元数据文件，即具有 .winmd 文件扩展名的文件。它们是 COM .tlb 类型库文件格式的扩展，您之前必须使用 #import 指令导入。
内部 .winmd 文件格式是基于 .NET 元数据格式的，这本身就是另一个主要的混淆来源。因此，大多数 .NET 反编译器可以向您显示 .winmd 文件的内容。但同样只是表面上的相似，它与 .NET 程序集完全无关。它可以只包含声明，而不是代码。最好将它与您在本机 C++ 项目中使用的 .h 文件进行比较。或者 .tlb 文件，如果您以前接触过 COM。
了解 COM 的工作原理对于理解这一切的意义非常有帮助。事实上，COM 位于 WinRT 的核心，这就是为什么您的 C++/CX 项目可以被用 Javascript 或 VB.NET 等完全不同的语言编写的程序轻松使用的基本原因。 WinRT 应用程序实际上 是一个进程外的 COM 服务器。 class 库或 WinRT 组件实际上是进程内 COM 服务器。 COM 对象工厂的工作方式不同，范围仅限于包清单中命名的文件。 C++/CX 是隐藏 COM 的 语言投影 的一部分，以及您 link 实现平台命名空间的 C++ 库。如果程序员必须编写传统的 COM 客户端代码，WinRT 将胎死腹中。您仍然可以在本机 C++ 中，WRL 库几乎不会隐藏管道。
WinRT 随时支持用 C# 或 VB.NET 等托管语言编写的代码，语言投影内置于框架中并且高度不可见。但不是 C++/CLI，这是一种结构限制。 Store/Phone/Universal 应用程序以名为 .NETCore 的 .NET Framework 子集为目标。这些天更广为人知的是 CoreCLR，这些部分是开源的。它不支持对 C++/CLI 至关重要的模块初始值设定项。
足够的介绍和答案：不，您的 C++/CLI 代码没有用处，您将不得不重写它。只要遵守 api 限制，您就可以很好地移植与 C++/CLI 包装器接口的本机 C++ 代码。你应该首先从那里开始，因为它很容易做到，并且会立即告诉你你的本机 C++ 代码是否正在使用 verboten api 函数，这种函数也会耗尽电池快速或违反沙盒限制。
ref class 包装器必须进行显着调整。没有理由认为这将是一个主要障碍，它在结构上 可能仍然相似。最大的限制是缺乏对实现继承的支持、COM 限制以及必须用等效的 C++ 代码替换使用 .NET Framework 类型的代码。典型的挂断是它往往有很多，原作者通常会更喜欢非常方便的 .NET 类型而不是标准的 C++ 库类型。 YMMV.
我有一些源自 .NET 系统命名空间的 C++/CLI 代码 类。
有没有办法为通用 Windows 平台应用重用此代码？
我无法在 C++ 中获得对系统命名空间的引用，但在 C# 中是可能的。看起来只支持 C++/Cx 代码，不支持托管 C++/CLI。
C++/CX 扩展的语法和关键字与 C++/CLI 非常相似。但这就是相似之处的终结，它们没有任何共同点。 C++/CX 直接编译为本机代码，就像本机 C++ 一样。但是C++/CLI被编译成.NET的中间语言MSIL。它们的语法看起来非常相似，因为它们都解决了相同的问题，将 C++ 连接到外部类型系统。 .NET 在 C++/CLI 的情况下，WinRT 在 C++/CX 的情况下。
这是不能使用 System 命名空间的根本原因，它是一个 .NET 命名空间。您改为使用 std 命名空间，以及用于 WinRT 特定类型的 Platform 和 Windows 命名空间。编译器无法导入具有有效 /ZW 编译选项的 .NET 参考程序集，只能导入 WinRT 元数据文件，即具有 .winmd 文件扩展名的文件。它们是 COM .tlb 类型库文件格式的扩展，您之前必须使用 #import 指令导入。
内部 .winmd 文件格式是基于 .NET 元数据格式的，这本身就是另一个主要的混淆来源。因此，大多数 .NET 反编译器可以向您显示 .winmd 文件的内容。但同样只是表面上的相似，它与 .NET 程序集完全无关。它可以只包含声明，而不是代码。最好将它与您在本机 C++ 项目中使用的 .h 文件进行比较。或者 .tlb 文件，如果您以前接触过 COM。
了解 COM 的工作原理对于理解这一切的意义非常有帮助。事实上，COM 位于 WinRT 的核心，这就是为什么您的 C++/CX 项目可以被用 Javascript 或 VB.NET 等完全不同的语言编写的程序轻松使用的基本原因。 WinRT 应用程序实际上 是一个进程外的 COM 服务器。 class 库或 WinRT 组件实际上是进程内 COM 服务器。 COM 对象工厂的工作方式不同，范围仅限于包清单中命名的文件。 C++/CX 是隐藏 COM 的 语言投影 的一部分，以及您 link 实现平台命名空间的 C++ 库。如果程序员必须编写传统的 COM 客户端代码，WinRT 将胎死腹中。您仍然可以在本机 C++ 中，WRL 库几乎不会隐藏管道。
WinRT 随时支持用 C# 或 VB.NET 等托管语言编写的代码，语言投影内置于框架中并且高度不可见。但不是 C++/CLI，这是一种结构限制。 Store/Phone/Universal 应用程序以名为 .NETCore 的 .NET Framework 子集为目标。这些天更广为人知的是 CoreCLR，这些部分是开源的。它不支持对 C++/CLI 至关重要的模块初始值设定项。
足够的介绍和答案：不，您的 C++/CLI 代码没有用处，您将不得不重写它。只要遵守 api 限制，您就可以很好地移植与 C++/CLI 包装器接口的本机 C++ 代码。你应该首先从那里开始，因为它很容易做到，并且会立即告诉你你的本机 C++ 代码是否正在使用 verboten api 函数，这种函数也会耗尽电池快速或违反沙盒限制。
ref class 包装器必须进行显着调整。没有理由认为这将是一个主要障碍，它在结构上 可能仍然相似。最大的限制是缺乏对实现继承的支持、COM 限制以及必须用等效的 C++ 代码替换使用 .NET Framework 类型的代码。典型的挂断是它往往有很多，原作者通常会更喜欢非常方便的 .NET 类型而不是标准的 C++ 库类型。 YMMV.