逐步将PowerBuilder / C ++应用程序移植到C＃/ WPF或Winforms

Question

我有机会开始将用C ++ / Powerbuilder编写的遗留应用程序移植到c＃。我们有一个功能，这个sprint启动一个独立的对话框，我刚刚完成了为我的托管实现创建一个CCW dll的练习，可以从C ++调用。我决定在我的托管DLL中使用WPF作为视图。到目前为止一切顺利，因为我可以与我的托管DLl进行互操作，包括从示例MFC应用程序启动WPF窗口。

推动这一策略有几个原因：

1. 我有一堆可重复使用的管理DLL，这些DLL来自最近重新设计的10年旧版应用程序。
2. 与C ++相比，我在C＃方面经验丰富，我发现自己经常与语言语法和智能感知作斗争。 FWIW，我们公司可以在投资某些工具方面做得更好，尽管它不会真正改变我对C ++语法，头文件和方法不一致......的厌恶。
3. 对于我们开发的应用程序类型的桌面应用程序，我认为C＃是要走的路。 4.未来计划重新编写应用程序，我不想重复自己，因此在现阶段我可以尽可能地开始设计正确的东西。
4. 我没有很多C ++帮助。

但是，我有一些疑虑和问题：

1. 这种零碎的方法是否可行？

2. 从性能角度来看，我应该与Winforms而不是WPF进行互操作吗？应用程序将托管GIS，因此性能是关键，尽管我们刚刚开发了另一个承载ThinkGeo的MapSuite的WPF应用程序，并且它的性能非常好。主要区别在于遗留应用程序与其WPF堂兄有很多GIS密集型。

3. 关于WPF / Silverlight命运的最新传言，我是否应该考虑WPF？如果WPF / Silverlight要死的桌面应用程序有什么替代方案？

3.等待我的问题是什么？

对此的任何想法和/或建议都会很棒。我将就此与我的经理进行咨询，但希望先了解一些您的想法和经验。 TIA。

克劳斯

修改

很抱歉，申请表是10岁，而不是原先陈述的25岁。那里很少混淆。

Answer 1

我认为没有比零碎的方法更好的方法。并且您始终可以使用C ++ / CLI（也称为托管C ++）来弥补任何困难。

我是WPF / Silverlight的忠实粉丝所以我肯定会在Winforms之上推荐它，这是一个很好但是看起来更老的技术。自定义控件和数据绑定使WPF世界中的长期开发变得更加容易。

WPF濒临死亡的谣言只是简单的胡说八道。是的，微软减少了WPF团队的规模 - 主要是因为WPF已经变得成熟和稳定。他们希望出于战略原因将更多资源投入浏览器区域;不知道为什么有人会把它等同于杀死WPF。

我在使用WPF封装或接口用C ++编写的遗留代码方面取得了巨大成功。我遇到的主要“问题”是当你有托管和非托管代码的层时，它可能会有点棘手，难以调试。您可能需要考虑编写自定义程序集加载器回调，以便可以查看有关无法加载的内容以及原因的更多信息，特别是如果您有遗留应用程序加载最终运行托管代码的C ++ DLL。