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

Question

我有机会将一个用C++/Powerbuilder编写的旧应用程序移植到C#。我们本次迭代中有一个启动独立对话框的功能，我刚刚完成了创建CCW dll的练习，用于调用来自C++的托管实现的此功能。我决定在我的托管DLL中使用WPF视图。到目前为止，一切都很好，因为我能够与我的托管DLL进行交互，包括从示例MFC应用程序启动WPF窗口。

这种策略有几个原因：

1. 我有一堆可重用的托管DLL，这些DLL是从最近重新设计的10年历史遗留应用程序中产生的。

2. 相比于C ++，我在C＃方面经验丰富，在C ++中，我发现自己不断地与语言语法和智能感斗争。值得一提的是，我们公司可以在一些工具上投资更多，尽管这并不会真正改变我对C ++语法、头文件和方法不一致的厌恶。

3. 对于桌面应用程序，至少对于我们开发的应用程序类型，我认为C＃是正确的选择。

4. 有未来的计划要重写该应用程序，我不想重复自己，因此在这个阶段开始设计正确的事情是很诱人的。

5. 我没有太多的C ++帮助。

然而，我有一些担忧和问题：

1. 这种逐步实现的方法是否可行？

2. 从性能角度来看，我应该与Winforms而不是WPF进行交互吗？应用程序将托管GIS，因此性能非常重要，尽管我们刚刚开发了另一个托管ThinkGeo's MapSuite的WPF应用程序，它的表现相当不错。主要区别在于旧应用程序比其WPF同类更注重GIS。

3. 鉴于最近有关WPF / Silverlight命运的传言，我是否应该考虑WPF？如果WPF / Silverlight会消失，桌面应用程序的替代品是什么？

4. 等待我的陷阱是什么？

如果您有任何想法和/或建议，那将是极好的。我将与我的经理商量，但首先想听听您的想法和经验。

- Klaus Nji

---

如果你的应用程序有任何严重规模，你可能不会完成手动迁移。它已经发展了25年，肯定是相当大的。你肯定不会手动重新编码所有内容，并期望保留其所有属性吧？你可能会觉得这个讨论很有用：https://dev59.com/anA75IYBdhLWcg3wJFYL - Ira Baxter

WPF和Silverlight是与PB不错的选择。预计开发所需时间为PB的4倍，这也假设你对GUI很灵活。仍然很难复制DataWindow，我使用Telerik网格但远不能像DataWindow那样灵活。 - Rich Bianco

Answer 1

我认为分步骤的方式是最好的方法，如果真的遇到难题，你可以使用C++/CLI (即托管C++)来弥合任何困难的差距。

我非常喜欢WPF/Silverlight，所以我肯定会建议它优于Winforms，虽然后者也不错，但它看起来比较老旧。自定义控件和数据绑定使得在WPF领域进行长期开发变得更加容易。

关于WPF死亡的谣言纯粹是无稽之谈。是的，微软缩小了WPF团队的规模——主要是因为WPF已经成熟和稳定了。他们出于战略原因希望将更多资源投入到浏览器领域；我不知道为什么有人会把这种行动等同于他们在杀死WPF。

我在使用WPF封装或与用C++编写的遗留代码进行接口时取得了巨大的成功。我遇到的主要“陷阱”是在具有托管和非托管代码层的情况下，调试可能会变得有点棘手和困难。如果你有一个遗留应用程序正在加载运行托管代码的C++ DLL，那么你可能需要考虑编写一个自定义的程序集加载器回调，这样你就可以看到更多关于加载失败的原因以及为什么会失败的信息。

- Ed Bayiates

---

谢谢你的建议。昨天我遇到了我的第一个调试“陷阱”，在尝试为我的托管类创建一个简单的包装器时。在StackOverflow的一些建议下，我能够将调试器附加到我的托管DLL中。但是确实很有挑战性。采取逐步方法是有道理的。我的方法是在WPF中实现新的应用程序扩展。 - Klaus Nji