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

【问题标题】：Gradually porting PowerBuilder/C++ application to C#/WPF or Winforms逐步将 PowerBuilder/C++ 应用程序移植到 C#/WPF 或 Winforms
【发布时间】：2011-07-01 05:39:51
【问题描述】：

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

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

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

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

这种零敲碎打的方法是否可行？
从性能的角度来看，我应该与 Winforms 而不是 WPF 进行互操作吗？应用程序将托管一个 GIS，因此性能是关键，尽管我们刚刚开发了另一个托管 ThinkGeo 的 MapSuite 的 WPF 应用程序，它的性能非常好。主要区别在于旧版应用程序比其 WPF 表亲更需要 GIS。
随着关于 WPF/Silverlight 命运的最新传闻，我是否应该考虑 WPF？如果 WPF/Silverlight 要死了，桌面应用程序的替代方案是什么？

3.还有什么问题在等着我？

对此的任何想法和/或建议都会很棒。我将就此与我的经理进行协商，但想先了解您的一些想法和经验。钛酸。

克劳斯

编辑：

抱歉，申请是 10 岁，而不是最初所说的 25 岁。那里有点混。

【问题讨论】：

如果您的应用程序有任何严重的规模，您可能不会以手动迁移的方式完成此操作。它有25年的发展，肯定是相当大的。您肯定不会手动重新编码所有这些，并期望保留其所有属性吗？您可能会发现此讨论很有用：stackoverflow.com/q/3455456/120163
WPF 和 Silverlight 是 PB 的不错替代品。预计开发所需的时间大约是 PB 的 4 倍，并且还假设您对 GUI 很灵活。复制数据窗口仍然很困难，我使用 Telerik 网格，但远不及数据窗口的灵活性。

标签： c# wpf interop powerbuilder code-migration

【解决方案1】：

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

我是 WPF/Silverlight 的忠实拥护者，所以我肯定会在 Winforms 之上推荐它，它虽然不错，但看起来更古老。自定义控件和数据绑定使 WPF 世界中的长期开发变得更加容易。

WPF 即将消亡的谣言纯属无稽之谈。是的，微软缩减了 WPF 团队的规模——主要是因为 WPF 已经变得成熟和稳定。出于战略原因，他们希望将更多资源投入浏览器区域；不知道为什么有人会将其等同于他们杀死 WPF。

我在使用 WPF 包装或与用 C++ 编写的遗留代码交互方面取得了巨大成功。我遇到的主要“问题”是当您拥有托管和非托管代码层时，它可能会变得有些棘手且难以调试。您可能需要考虑编写自定义程序集加载器回调，这样您就可以了解更多关于加载失败和原因的信息，尤其是如果您有一个加载 C++ DLL 并最终运行托管代码的旧版应用程序。

【讨论】：

感谢您的建议。我昨天刚遇到我的第一个调试“陷阱”，试图为我的托管类创建一个简单的包装器。有了一些建议，感谢 StackOverflow，我能够将调试器附加到我的托管 DLL。但是，是的，这是一个挑战。采取零碎的方法是有道理的。我的方法是在 WPF 中实现新的应用程序扩展。