我正在做一个名为"C++游戏开发"的学生项目。这是一个有客户端和服务器的纸牌游戏。客户端应用程序包含一些我已经在Visual Studio 2013中使用windows窗体制作的窗口。对于客户端/服务器通信，我决定使用互联网通信引擎（ICE）。在内置客户端的项目中，我在ICE自动生成的代码中出现了错误。我发现ICE不支持C++/CLI，只支持本机C++或C#（我不能使用）。
因此，现在我正处于一个十字路口，无论是用本机C++制作整个客户端应用程序（例如，使用我不熟悉的MFC），还是同时使用本机C++和C++/CLI（将我在Windows窗体上所做的工作放在CLR类库中，并从带有入口点的本机C++项目链接到它），这都不是一件小事。
我正试着选择一个耗时较少的选项。我请求帮助我估计这些方法的复杂性。我更喜欢第二个，但我不确定它是最简单的。
这取决于GUI中已经有多复杂。如果你有一百个对话框/控件，那么用原生C++重写它可能是错误的答案。在这种情况下，将GUI制作成库更有意义。
然而，最好将GUI作为一个进程，并在本机C++中构建一个代理库，将ICE调用传递到服务器上。（因此，C++/CLI.exe调用新C++库中的一个函数，该函数对服务器进行ICE调用，反之亦然）。
如果你的GUI很小，那么在一个现代的（并且更好地支持C++/CLI）系统中重写它是最好的选择。Qt可能是目前原生GUI中的终极版本（但也有MFC或wxWidgets等替代品）。即使在这种情况下，将网络子系统编码为本地库也可能更好。然后，您可以更改GUI，并根据自己的喜好尝试加载GUI堆栈，只需更改一个表示层即可将游戏移植到Android或iOS。
第三种选择是选择不同的通信系统。虽然像RPC这样的ICE很好，但现在的"位置"是通过REST服务进行基于web的通信（尝试像Mongoose或NxWeb这样的嵌入式c++web服务器），如果你需要将数据推送回客户端，这些支持WebSocket，因此将提供你所需的所有功能。然后，您可以将GUI重写为基于HTML的！
所以：把你的命令放在一个原生的C++库中。
C++/CLI可以很好地使用本机C++代码。
将生成的代码粘贴到不使用/clr构建的"静态库项目"中。然后将该静态库列为C++/CLI DLL的依赖项。
链接器将计算出其余部分。结果被称为"混合模式程序集"。
请注意，您的命令库可能不接受托管类型。没关系，C++/CLI可以很好地混合非托管数据模型和托管视图（UI）类。