这是您无法使用System命名空间的基本原因,它是.NET命名空间.您可以使用std命名空间以及WinRT特定类型的Platform和Windows命名空间.编译器无法使用有效的/ ZW编译选项导入.NET引用程序集,只能导入具有.winmd文件扩展名的WinRT元数据文件.这是COM .tlb类型库文件格式的扩展,您以前必须使用#import指令导入它们.

这本身就是混淆的另一个主要来源,内部.winmd文件格式基于.NET元数据的格式.因此,大多数.NET反编译器都会向您显示.winmd文件的内容.但同样只是表面上的相似之处,它与.NET程序集完全无关.它只能包含声明,而不是代码.最好将它与您在本机C项目中使用的.h文件进行比较.或者.tlb文件,如果您以前曾接触过COM.

了解COM的工作原理对于了解这是什么一件非常有帮助.实际上COM是WinRT的核心,这是为什么你的C/C++X项目可以被一个用完全不同的语言(如Javascript或VB.NET)编写的程序轻松使用的基本原因. WinRT应用程序实际上是一个进程外COM服务器.类库或WinRT组件实际上是进程内COM服务器. COM对象工厂的工作方式不同,范围仅限于包清单中指定的文件. C/C++X是隐藏COM的语言投影的一部分,以及您实现Platform命名空间的链接的C库.如果程序员必须编写传统的COM客户端代码,WinRT仍然会诞生.你仍然可以在本地C,WRL库几乎没有隐藏管道.

WinRT很容易支持用C#或VB.NET等托管语言编写的代码,语言投影内置于框架中并且非常不可见.但不是C/C++LI,这是一个结构性限制. Store / Phone / Universal应用程序面向名为.NETCore的.NET Framework子集.最近知道CoreCLR是开源的部件.哪个不支持模块初始化程序,对C/C++LI至关重要.

足够的介绍和答案：不,你没有使用你的C/C++LI代码,你将不得不重写它.只要它遵守api限制,您就可以轻松移植C/C++LI包装器所连接的本机C代码.你应该首先从那里开始,因为它很容易做,并立即告诉你你的本机C代码是否使用verboten api函数,那种电池耗尽太快或违反沙箱限制.

然而,ref类包装器必须进行重大调整.没有理由认为这将是一个主要障碍,它在结构上仍然可能是相似的.最大的限制是缺乏对实现继承的支持,COM限制以及必须用等效C代码替换使用.NET Framework类型的代码.典型的挂起是它往往会有很多,原始作者通常会喜欢非常方便的.NET类型而不是标准的C库类型.因人而异.