我的应用程序未被管理。从哪里开始引入托管代码?

配置应用程序,决定什么样的集成点,你可以跳过逻辑的C行,然后进入C++,反之亦然。把这些设计成一个有立面设计模式的系统,通过C++逐步取代C++。当决定在每个候选外观/接口上切换语言时,关键关注的是CPU和内存成本。

您将希望能够合并编辑,这样您就可以最好地使用一个源代码集和源代码存储库,用于原始C++代码和另一个用于外观的集合和存储库,以及C语言。

然后,当增强/维护工作进入收件箱时,您将它应用于这两个代码库,并尝试确保外观从代码开始在系统中移动,以使增强或维护中的代码变化最少,从而将更改工作的加倍减至最小。

同样,理想地构造你的作品,这样你就可以回击门面,如果你遇到障碍,就可以回到100%个C++。

为了测试两个特别难以理解的C++模块是否可以被分离成一个C++片段和一个C语言片段,在两个不同的Win32 C++进程中运行它们,它们使用管道或套接字进行通信。这样,您就可以更好地了解内存管理或性能是否存在问题,这些问题需要在拆分调用链之前进行修复。

我们完全按照您在数千个用户使用的关键任务应用程序中所描述的进行操作。基本上,我们保持现有的应用程序,所以可执行文件仍然是一个100%非托管可执行文件(不是C++/CLI)。然后,我们将所有新的C代码放入由业务对象、用户控件和GUI代码等组成的.NET DLL中。

基本上,所有新代码都是用C编写的。我们有1个DLL,即C++/CLI,只是胶水。这使得我们可以轻松地在托管代码和非托管代码之间进行互操作,而不必使用现有的C++代码CLR。这限制了我们必须编写的C++/CLI代码的数量。本地代码与混合模式代码对话,混合模式代码可以与托管代码对话。混合模式的DLL可以在C类中钩住事件,因此C代码可以触发事件以与C++/CLI通信(可以与本机代码对话)。

我们还可以在现有的C++应用程序中承载.NET用户控件(WiFrm只是WiLAPI周围的一个包装器,所以它工作得很好)。

这很好地工作,并且允许您保留现有的代码,而不必用C_重写整个GUI。

现在,考虑这个问题已经结束。

我意识到,答案不是混合C++和C++,而是首先让架构正确。

如果体系结构是正确的,并且在需要分离的地方进行分离,那么通过其他模块(外部模块、其他语言等)更改应用程序的部分应该更容易。

对于编组过程中的性能问题,我们必须等待.NET进一步成熟。