我想采取一种增量方式,我们慢慢地移动部分代码,并将新功能写入C#,并将其编译到可以从旧应用程序引用的库或DLL中.
这是可能的,最好的方法是什么？
编辑：在这一点上,我们仅限于Express版本,我相信不允许使用在我们当前的应用程序中大量使用的MFC库.这也是一个非常大的应用程序与大量的硬件依赖关系,所以我不认为批发迁移是在卡.
编辑2：我们研究了在C#中编写COM包装的组件,但没有COM体验这是可怕而复杂的.是否可以使用直接C接口生成一个C#dll,其中隐藏所有管理好的内容？还是COM是必要的邪恶？
解决方法
>通过转向2010年发展来确定我们希望获得什么 – 可能是
>提高质量保证：单元测试,嘲笑是现代开发工具的一部分
> slicker UI：WPF提供了现代的外观和感觉.
>生产力：在某些领域,.NET开发比C开发更有成效
>支持：新工具支持改进和错误修复.
>识别系统的哪些部分不会被移动到C#中：
>硬件访问,低级算法代码
>非常规定非UI工作代码 – 如果已经有效,则无需抛出任何错误
>确定系统的哪些部分需要迁移到c#.对于这些部分,确保C中的当前实现是解耦和模块化的,以便这些部分可以被换出.如果应用程序是一个整体,那么需要大量的工作来重构应用程序,以便它可以被分解,并在c#中选择要重新实现的部分. (有可能没有重构,而只是专注于在c#中实现新的应用程序功能.)
>现在您已经确定哪些部分将保留在C中,哪些部分将在c#中实现(或者只是规定新功能在c#中),那么关注如何将c#和c集成到一个解决方案中
>使用COM包装器 – 如果您现有的C项目很好地利用OO,这通常并不像看起来那么困难.使用MSVC 6,您可以使用ATL类将您的类公开为COM组件.
>直接整合native和c#代码.集成“遗留”编译代码需要一个中间的DLL – 有关详细信息,请参阅here.
混合MFC UI和c#UI可能无法实现,并且不建议,因为它会产生两种截然不同的风格(20世纪90年代灰色和2010年的氛围)的UI组合.将重点放在实现增量迁移上更为简单,例如在c#中实现新的应用程序代码,并从本地C代码调用该代码.这使得迁移的c#代码的数量保持不变.随着您进一步了解2010年的开发,您可以获取不可迁移的较大块,例如UI.
