通用Windows平台应用程序和C ++ / CLI(VS 2015 RC1)

我有一些从.NET系统命名空间类派生的C ++ / CLI代码。

有没有办法重用通用Windows平台应用程序的这个代码?

我不能在C ++中获得系统命名空间的引用,尽pipe在C#中是可能的。 看起来好像只支持C ++ / Cx代码,而不支持托pipe的C ++ / CLI。

Solutions Collecting From Web of "通用Windows平台应用程序和C ++ / CLI(VS 2015 RC1)"

C ++ / CX扩展的语法和关键字非常类似于 C ++ / CLI。 但这就是相似之处的结局,它们没有什么共同之处。 C ++ / CX直接编译为本地代码,就像本机C ++一样。 但是C ++ / CLI被编译为.NET的中间语言MSIL。 它们的语法看起来非常相似,因为它们解决了同样的问题,将C ++连接到外部类型系统。 在C ++ / CLI的情况下是.NET,在C ++ / CX的情况下是WinRT。

这是你不能使用System命名空间的基本原因,它是一个.NET命名空间。 而是使用std命名空间,以及WinRT特定类型的PlatformWindows命名空间。 编译器不能导入带有/ 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 ++库类型。 因人而异。