通用Windows平台应用程序和C ++ / CLI（VS 2015 RC1） [英] Universal Windows Plattform Apps and C++/CLI (VS 2015 RC1)
问题描述
我有一些来自.NET系统命名空间类的C ++ / CLI代码。
有没有办法为通用Windows平台应用程序重用这个代码？ / p>
我无法在C ++中获得对系统命名空间的引用，尽管在C＃中是可能的。它似乎只支持C ++ / Cx代码，而不是托管C ++ / CLI。
语法和关键字C ++ / CX扩展类似于 C ++ / CLI。但是，这是相似性的结束，他们没有什么共同点。 C ++ / CX直接编译为本地代码，就像本地C ++。但是C ++ / CLI被编译为MSIL，.NET的中间语言。它们的语法看起来非常相似，因为它们都解决了相同的问题，将C ++连接到外部类型系统。 .NET在C ++ / CLI的情况下，WinRT在C ++ / CX的情况下。
这是为什么你不能使用系统命名空间的基本原因，它是一个.NET命名空间。您改为使用 std 命名空间以及 Platform 和 Windows WinRT特定类型的命名空间。编译器不能导入带有/ ZW编译选项有效的.NET引用程序集，只能导入具有.winmd文件扩展名的WinRT元数据文件。这是COM .tlb类型库文件格式的扩展，您以前必须使用#import指令导入。
这本身是另一个主要来源混淆，内部.winmd文件格式基于.NET元数据的格式。大多数.NET反汇编程序可以向您显示.winmd文件的内容。但同样只是一个表面的相似性，它是完全不相关的.NET程序集。它只能包含声明，而不是代码。最好将它与在本地C ++项目中使用的.h文件进行比较。
了解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框架的子集。这些天更好的称为CoreCLR，这些部分是开源的。其中不支持模块初始化器，对C ++ / CLI至关重要。
足够的介绍和得到答案：不，你没有使用你的C ++ / CLI代码，必须重写它。你将有一个体面的镜头，移植本地C ++代码，你的C ++ / CLI包装接口，只要它观察到api的限制。你应该总是从那里开始，因为它很容易做，并立即告诉你，你的本地C ++代码是否正在使用 verboten api函数，这种类型的电池太耗电或违反沙盒限制。
然而， ref类包装器必须大幅调整。很少有理由认为这将是一个主要障碍，它仍然可能在结构上类似。最大的限制是缺乏对实现继承，COM限制的支持，并且不得不使用等价的C ++代码替换使用.NET Framework类型的代码。典型的挂起是，往往有很多，原作者通常会喜欢的标准C ++库类型非常方便的.NET类型。 YMMV。
I have some C++/CLI code which derives from the .NET System Namespace classes.
Is there a way to reuse this code for Universal Windows Platform Apps?
I can't get a reference to the System Namespace in C++, though in C# it is possible. It looks like there is only support for C++/Cx code and not for managed C++/CLI.
The syntax and keywords of the C++/CX extension resembles C++/CLI a great deal. But that's where similarity ends, they have nothing whatsoever in common. C++/CX gets compiled directly to native code, just like native C++. But C++/CLI is compiled to MSIL, the intermediate language of .NET. Their syntax looks so similar because they both solve the same problem, interfacing C++ to a foreign type system. .NET's in the case of C++/CLI, WinRT in the case of C++/CX.
Which is the basic reason why you cannot use the System namespace, it is a .NET namespace. You instead use the std namespace, along with the Platform and Windows namespaces for WinRT specific types. The compiler cannot import .NET reference assemblies with the /ZW compile option in effect, only WinRT metadata files, the ones with the .winmd filename extension. Which are an extension to the COM .tlb type library file format, the ones you previously had to import with the #import directive.
Which in itself is another major source for confusion, the internal .winmd file format was based on the format of .NET metadata. Most .NET decompilers can show you the content of a .winmd file because of this. But again just a superficial similarity, it is completely unrelated to a .NET assembly. It can just contain declarations, not code. Best to compare it to a .h file you'd use in a native C++ project. Or a .tlb file if you previously had exposure to COM.
Knowing how COM works can be very helpful to grok what this is all about. It is in fact COM that lies at the core of WinRT, the basic reason why your C++/CX project can be easily used by a program written in a completely different language like Javascript or VB.NET. A WinRT app is actually an out-of-process COM server. A class library or WinRT component is actually an in-process COM server. COM object factories work differently, the scope is limited to the files named in the package manifest. C++/CX is part of the language projection that hides COM, along with the C++ libraries you link that implement the Platform namespaces. WinRT would be still-born if programmers had to write traditional COM client code. You still can in native C++, the WRL library does little to hide the plumbing.
WinRT readily supports code written in a managed language like C# or VB.NET, the language projection is built into the framework and highly invisible. But not C++/CLI, a structural limitation. A Store/Phone/Universal app targets a subset of the .NET Framework named .NETCore. Better known these days as CoreCLR, the parts that were open-sourced. Which does not support module initializers, critical to C++/CLI.
Enough introduction and getting to the answer: no, you have no use for your C++/CLI code and you'll have to rewrite it. You'll have a decent shot at porting the native C++ code that your C++/CLI wrapper interfaced with, as long as it observes the api limitations. You should always start there first, given that it is easy to do and instantly tells you if your native C++ code is using verboten api functions, the kind that drains a battery too quickly or violates the sandbox restrictions.
The ref class wrappers however have to be significantly tweaked. Little reason to assume that will be a major obstacle, it could still structurally be similar. Biggest limitations are the lack of support for implementation inheritance, a COM restriction, and having to replace the code that used .NET Framework types with equivalent C++ code. The typical hangup is that there tends to be a lot of it, the original author would normally have favored the very convenient .NET types over the standard C++ library types. YMMV.
这篇关于通用Windows平台应用程序和C ++ / CLI（VS 2015 RC1）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
