3

我有机会开始将用 C++/Powerbuilder 编写的遗留应用程序移植到 c#。我们在这个 sprint 中有一个特性，它启动一个独立的对话框，我刚刚完成了为我的这个特性的托管实现创建一个 CCW dll 的练习，从 C++ 中调用。我决定将 WPF 用于托管 DLL 中的视图。到目前为止一切顺利，因为我能够与我的托管 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.等待我的是什么陷阱？

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

克劳斯

编辑：

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

4

1 回答 1

1

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

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

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

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

于 2011-07-05T18:39:25.200 回答