随着 .net Core 以及最近的 .net 5 的引入，跨平台的 .net/C# 相对容易。 考虑到这一点，我正在开发一个使用 .net 5/C# 的应用程序，但是我想将一些代码保留在 C++/native 域中。仅使用 C#，甚至可以从开发平台发布到其他平台。我愿意放弃。
现在，如何保持项目跨平台？
我一直在寻找任何地方似乎都没有一个很好的选择......
也许是this solution from Xamarin？我不确定它会转化为桌面，或者它可以在 CI/CD 上自动化......
但除此之外，每个人似乎都以自己的笨拙方式逃脱。
有人对跨平台的 C(++)/C# 集成有意见吗？
编辑 1：
我的问题不是使互操作本身。我已成功使用 SWIG，并且我了解 P/Invoke、C 兼容的 ABI 等。
我的问题是构建系统/部署。到目前为止，我必须复制文件。但是如何才能拥有一个集成的构建系统呢？例如，我希望在构建我的 dotnet 应用程序以编译 C++ 库时使用它。
【问题讨论】：
您可以毫无问题地使用 C++/C#。但是 C++ 端和 C# 端之间的“桥梁”方法必须接受/返回纯 C 类型/结构。 你不能绕过std::xxxx句号。您可以传递char *str、struct { int Foo, int Bar }、int[] 等等（但仍然有一点复杂性，具体取决于它是如何完成的）。
我维护了一个 github 示例，其中包含有关在 .NET Framework/.NET Core 上将字符串和结构从/到 C/C++ 到 C# 的封送处理的示例。该项目是为 Visual Studio 构建的，因此内部有一些“微软特性”，但可以轻松地将基本思想复制粘贴到其他 C 平台上。
当你想做一个完全多平台的项目时，还有一些额外的复杂性（我写这些例子时没有考虑跨平台）：
字符串的编码：在示例中，我展示了您可以轻松使用 utf-8 字符串，但这仍然很痛苦，因为在 Windows 上，Windows API 不支持 utf-8 并且是为 wchar_t 量身定制的（你不能 CreateFile 使用 utf-8 文件名）。在 Linux 的另一侧，每个人都使用char*，几乎没有人使用wchar_t*（举同样的例子，filesystems on Linux are agnostic about character sets，所以open 原语和fopen 方法可以接受char* utf-8 编码），因此决定如何以跨平台方式处理 char/wchar_t 是一件痛苦的事情。如果必须这样做，我可能会将TCHAR 宏定义为Linux 上的char，Windows 上的wchar_t，在任何地方都使用它，并对字符串使用LPTStr 编组选项，以及Auto Marshal 类的方法（例如Marshal.PtrToStringAuto）。 .NET Core 认为LPTStr/xxxAuto 在 Linux 上是 char*，在 Windows 上是 wchar_t*。
虽然在 Windows 上存在大量内存分配器（.NET Core 在互操作中使用的主要分配器是用于内存的 CoTaskMemAlloc 和用于字符串的 SysAllocString，但也有一些小众（有用）的东西，例如 @ 987654349@)，在 Linux .NET Core 上直接使用malloc。这对于释放“从另一边”分配的内存很重要，如果您希望能够让编组器自动释放内存，它会增加复杂性。但最终，从 C/C++ 端公开内存释放器总是一个好主意，因为在此之前或之后，您必须释放在 C/C++ 端分配的内存。虽然可能，但我认为让编组器自动释放 C/C++ 端分配的内存是一个坏主意（因为您无法控制操作，并且无法轻松调试它）。所以没有char* Foo() 用string Foo() 翻译成C#：这是可能的，但.NET 编组器将使用CoTaskMemFree 来释放它。还有其他方法可以做到这一点，或者您可以手动进行（IntPtr Foo() 然后您转换并明确释放IntPtr）。
在Linux下使用BSTR和SAFEARRAY有一些限制（主要问题是C端没有互惠方法），所以如果你想跨平台编程使用它们是个坏主意（但没有一个人使用它们）
【讨论】：
extern "C" 并让事情成为函数而不是为简单的 FFI 分类。还有诸如 SWIG 和 CppSharp 之类的东西。您展示的仍然是 vcxproj，因此无法为 Linux 或 MacOS 构建。我对跨平台感兴趣，这就是问题的重点。
分为三个方面：
显然，您需要为所有受支持的平台维护本机组件的版本和构建。这本身就是一个挑战，但与从 .NET 中使用它无关。关于 1)，您需要为您的本地库提供与标准化 PInvoke 规范兼容的 API。这可能具有挑战性，具体取决于您的组件所做的事情，如果做得不好，可能会导致麻烦。如果可以，请只选择纯托管代码，如果您已准备好迎接挑战，请继续！
【讨论】：