我有一些从.NET系统命名空间类派生的C ++ / CLI代码。
有没有办法重用通用Windows平台应用程序的这个代码？
我不能在C ++中获得系统命名空间的引用，尽pipe在C＃中是可能的。 看起来好像只支持C ++ / Cx代码，而不支持托pipe的C ++ / CLI。
C ++ / CX扩展的语法和关键字非常类似于 C ++ / CLI。 但这就是相似之处的结局，它们没有什么共同之处。 C ++ / CX直接编译为本地代码，就像本机C ++一样。 但是C ++ / CLI被编译为.NET的中间语言MSIL。 它们的语法看起来非常相似，因为它们解决了同样的问题，将C ++连接到外部类型系统。 在C ++ / CLI的情况下是.NET，在C ++ / CX的情况下是WinRT。
这是你不能使用System命名空间的基本原因，它是一个.NET命名空间。 而是使用std命名空间，以及WinRT特定类型的Platform和Windows命名空间。 编译器不能导入带有/ ZW编译选项的.NET引用程序集，只有WinRT元数据文件，扩展名为.winmd的文件。 这是COM .tlb类型库文件格式的扩展，这是您以前必须使用#import指令导入的格式。
这本身就是造成混乱的另一个主要原因，内部.winmd文件格式是基于.NET元数据的格式。 大多数.NET反编译器都可以显示.winmd文件的内容。 但是，再次只是表面的相似性，它是完全无关的.NET程序集。 它可以包含声明，而不是代码。 最好将它与在本机C ++项目中使用的.h文件进行比较。 或者如果您之前已经暴露于COM，则为.tlb文件。
了解COM的工作方式可以帮助您理解这一切。 事实上，COM就是WinRT的核心，这就是为什么你的C ++ / CX项目可以被一个完全不同的语言如Javascript或VB.NET编写的程序轻松使用的基本原因。 WinRT应用程序实际上是一个进程外COM服务器。 类库或WinRT组件实际上是一个进程内COM服务器。 COM对象工厂的工作方式不同，范围仅限于包清单中指定的文件。 C ++ / CX是隐藏COM的语言投影的一部分，以及实现Platform命名空间的C ++库链接。 如果程序员不得不编写传统的COM客户端代码，WinRT仍然是天生的。 你仍然可以在本地的C ++，WRL图书馆几乎没有隐藏管道。
WinRT很容易支持用C＃或VB.NET之类的托管语言编写的代码，语言投影被嵌入到框架中，并且非常隐蔽。 但不是C ++ / CLI，一个结构性的限制。 商店/电话/通用应用程序的目标是名为.NETCore的.NET Framework的一个子集。 这些日子更好地被称为CoreCLR，即开源的部分。 哪些不支持模块初始化器，对C ++ / CLI至关重要。
有足够的介绍并得到答案：不，你没有使用你的C ++ / CLI代码，你将不得不重写它。 在移植C ++ / CLI包装程序接口的本机C ++代码时，只要遵守api限制，就会有一个体面的效果。 你应该总是先从那里开始，因为它很容易做，并立即告诉你，如果你的本地C + +代码使用verboten API功能，这种电池耗尽太快或违反沙箱的限制。
然而ref class包装必须被大幅调整。 没有什么理由认为这将是一个主要障碍，它仍然可能在结构上是相似的。 最大的限制是缺乏对实现继承，COM限制的支持，并且不得不将.NET Framework类型的代码替换为等价的C ++代码。 典型的挂断是，它往往是很多的，原来的作者通常会赞成非常方便的.NET类型超过标准的C ++库类型。 因人而异。