我有一大堆MFC/ATL程序的代码,希望在Windows窗体应用程序中使用。最简单的方法是什么,以便将此代码“转换”为启用/clr并找到基本类(例如CObject、CString、CFile和模板)的编译方式?
我有一大堆MFC/ATL程序的代码,希望在Windows窗体应用程序中使用。最简单的方法是什么,以便将此代码“转换”为启用/clr并找到基本类(例如CObject、CString、CFile和模板)的编译方式?
没有太多需要进行“转换”的工作,您只需启用/clr并编译即可。会有一些构建错误,但不是很多。
这是一个应该谨慎考虑的决定。一旦您跨越了/clr门槛,就会牺牲一些东西:
构建性能变得更差,特别是链接方面。您不能增量链接C++/clr项目。
在您的.exe或.dll中添加了一个额外的加载层。您必须注意初始化的顺序,特别是静态初始化。自VS2005以来,这方面已经有了很大的改进,但仍存在问题。我有一个/clr DLL项目,无法正确卸载,我一直没能找到原因。这种问题的一个症状是,在调试结束时,您不会获得内存泄漏检测信息。
当您向项目添加功能时,可以选择托管或本机实现。如果您选择为某些在项目中其他地方使用本机实现的功能选择托管,则必须选择修改旧实现。
跨越托管-本机阈值会影响性能和调试。
异常处理变得更加复杂。
与其在整个项目上切换/clr开关,我建议采用更有针对性的方法。将您的大型库保持为本机方式。创建混合模式/clr引导程序/包装器。这个“薄代理”提供了访问本机库的好处,同时保持了本机库的稳定性和性能。
如果您的本机库中有对话框(或更糟的是SDI/MDI视图,请参见此处),则连接显示可能会有些棘手。但这将是值得的。
如果我没记错的话,VC++.net有一个新版本的MFC。将项目转换为VC.net项目,然后慢慢将类转换为托管代码。这样可以让您逐步重新设计所有内容,而不是一次性重写所有内容。顺便说一下,如果您还没有使用MVC设计模式将接口与内部工作分离。