首先，我知道一个包含“建议”的问题标题会引发反对票和“非建设性”标志的尖叫，但是如果您先阅读并考虑到我的问题，我将很高兴就可访问的学习材料/文档而言，这是一个具体的问题。
ATM我正在尝试将现有应用程序从Linux扩展到Windows。结构基本上由一个包含几个静态本机C ++库的后端核心组成，我从一个前端项目（带有其他语言的C / C ++ GTK）中调用这些库。恕我直言，通过使用核心C ++库并将此类项目插入不同平台特定的前端中，将此类项目扩展到其他平台应该是一个非常普遍的计划。现在，在这种情况下，这将是一个UWP项目。
让我感到困惑的是Microsoft与C＃的互操作策略看似不一致，现在就过渡的景象，特别是C ++ / CX和C ++ / WinRT。 我正在努力解决的主要问题是：什么是在您中实现本机C ++库的最佳方法（也可以将它们作为项目嵌入Visual Studio中以在Windows上提供本机生成体验和依赖项管理） UWP应用程序？ C ++ / WinRT似乎非常关注WinRT的消耗（这是有道理的，因为这是应该的！）。 C ++ / CX似乎已正式被弃用和不推荐使用，当您在VS中选择Visual C ++库项目时，它会自动引用VC ++库，这些库不是本机的，我担心会有某种中间层介入。
在这种情况下必须有某种工业上的最佳实践，不是吗？
答案 0 :(得分：3)
C ++ / WinRT和较早的C ++ / CX语言扩展只是使Windows运行时界面更易于从C ++使用的方式。 Windows Runtime的主要设计价值之一是使编写可以投影到C ++，C＃和JavaScript的组件更加容易。
如果所有这些语言都将使用您的组件的目的（这在很大程度上影响界面设计），那么为您的代码创建Windows运行时界面就很有价值。组件/库的客户端可以自由使用他们想使用Windows运行时类型的任何方法：C ++ / WinRT，C ++ / CX，C＃或JavaScript互操作。
对于内部实现，这取决于您。 C ++ / WinRT支持编写Windows Runtime组件，如果您正在寻找编写Windows Runtime API的“现代C ++”方式，那么从头开始是一个不错的选择。您也可以使用C ++ / CX或Windows运行时库（WRL），尽管WRL需要付出一些努力才能使MDL生成保持同步。
Walkthrough: Creating a Windows Runtime component in C++/CX, and calling it from JavaScript or C#
The Windows Runtime Library (WRL) (Channel 9)
如果另一方面，如果您正在编写希望由C ++ UWP应用程序使用的C ++库，则只需创建一个标准C ++库即可供C ++ UWP或经典Win32桌面应用程序使用（例如，在DirectX Tool Kit）。这对您的库提出的唯一要求是坚持适用于UWP应用程序可用的Win32 API表面积。有关各种注意事项，请参见this blog series。通常，您可以将其简化为现有代码的配置形式。
如果您想同时支持C＃/ JavaScript使用的本机C ++接口和Windows运行时API，则可以为本机Windows运行时API提供一个可选组件（例如Win2D对于Direct2D / DirectWrite / WIC的作用）
有一些历史遗忘之处： WRL是使用C ++中的Windows Runtime API的第一个解决方案，但是感觉很难使用它来编写WinRT接口。 Microsoft内部开发人员仍然使用WRL进行组件开发，但是建议一般开发人员使用C ++ / CX路径。参见Inside the C++/CX Design。 C ++ / CX大量借用了Managed C ++的现有“保留字”，这不太可能与现有代码发生冲突，但确实使熟悉Managed C ++的人们感到困惑。
C ++ / WinRT是一种更现代的解决方案，可以使Windows运行时类型的本机C ++语言投影更加直观。该技术严重依赖已经开发了一段时间的C ++ 14 / ++ 17语言功能，因此，实际上只有最近才能完全实现C ++ / WinRT解决方案。以直观的本机C ++方式使用Windows运行时异步API时，需要使用C ++ 20草案中的协例程。因此，总的来说，C ++ / WinRT是一种优雅的解决方案，但需要尖端的编译器技术。参见C++/WinRT