通用Windows平台应用程序和C ++ / CLI（VS 2015 RC1） [英] Universal Windows Platform Apps and C++/CLI (VS 2015 RC1)

问题描述

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

I have some C++/CLI code which derives from the .NET System Namespace classes.

有没有一种方法可以将该代码重用于Universal Windows Platform Apps？

Is there a way to reuse this code for Universal Windows Platform Apps?

我无法获得C ++中对系统命名空间的引用，尽管在C＃中是可能的。似乎仅支持C ++ / Cx代码，而不支持托管C ++ / CLI。

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.

推荐答案

C ++ / CX扩展名类似于 C ++ / CLI。但这就是相似性结束的地方，它们之间没有任何共同点。 C ++ / CX像本机C ++一样直接编译为本机代码。但是C ++ / CLI被编译为MSIL（.NET的中间语言）。它们的语法看起来非常相似，因为它们都解决了相同的问题，将C ++与外部类型系统接口。 .NET是C ++ / CLI，WinRT是C ++ / CX。

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.

这是您不能使用System命名空间的基本原因，这是.NET名称空间。您可以使用 std 命名空间，以及 Platform 和 Windows WinRT特定类型的名称空间。编译器不能导入有效的/ ZW编译选项的.NET参考程序集，而只能导入WinRT元数据文件（扩展名为.winmd的文件）。这是COM .tlb类型库文件格式的扩展，以前是您必须使用#import指令导入的文件格式。

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.

本身就是另一个主要来源混乱时，内部.winmd文件格式基于.NET元数据的格式。因此，大多数.NET反编译器可以向您显示.winmd文件的内容。但是同样，这只是表面上的相似之处，它与.NET程序集完全无关。它只能包含声明，不能包含代码。最好将其与您在本机C ++项目中使用的.h文件进行比较。

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.

了解COM的工作原理对于了解这是怎么回事非常有用。

实际上，COM是WinRT的核心，这是用完全不同的语言（例如Javascript或VB.NET）编写的程序可以轻松使用C ++ / CX项目的基本原因。实际上，WinRT应用是进程外COM服务器。一个类库或WinRT组件实际上是一个进程内COM服务器。 COM对象工厂的工作方式不同，范围仅限于程序包清单中命名的文件。 C ++ / CX是语言投射的一部分，该语言隐藏了COM，以及您链接的用于实现Platform名称空间的C ++库。如果程序员必须编写传统的COM客户端代码，那么WinRT将会诞生。您仍然可以在本机C ++中使用WRL库来隐藏管道。

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支持用C＃或VB.NET之类的托管语言编写的代码，该语言投影内置在框架中并且高度不可见。但不是C ++ / CLI，这是结构限制。商店/电话/通用应用程序以.NET Framework名为.NETCore的子集为目标。如今，众所周知的是开源的部件CoreCLR。不支持模块初始化程序，对C ++ / CLI至关重要。

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.

足够的介绍并得到答案：不，您不需要使用C ++ / CLI代码，您将必须重写它。只要移植您的C ++ / CLI包装器与其连接的本机C ++代码，只要遵守api的限制，您就可以很好地进行移植。考虑到它很容易做到，您应该始终从那里开始，并立即告诉您您的本机C ++代码是否使用 verboten api函数，这种函数会很快耗尽电池电量或违反沙箱限制。

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.

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

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屋！