C# 将 PowerBuilder 应用程序移植到 .NET

Porting a PowerBuilder Application to .NET

提问by Justin Ethier

Does anyone have any advice for migrating a PowerBuilder 10 business application to .NET?

有人对将 PowerBuilder 10 业务应用程序迁移到 .NET 有什么建议吗？

My company is considering migrating a legacy PB application to .NET (C#) and I am just wondering if anyone has any experience - good or bad - that you would like to share.

我的公司正在考虑将旧的 PB 应用程序迁移到 .NET (C#)，我只是想知道是否有人有任何经验 - 无论好坏 - 想要分享。

The application is rather large with 10 PBL libraries, some PFC as well as custom frameworks. There are a large number of DLL calls being made as well. Finally, it uses a Microsoft SQL Server database.

该应用程序相当大，有 10 个 PBL 库、一些 PFC 以及自定义框架。还有大量的 DLL 调用。最后，它使用 Microsoft SQL Server 数据库。

We have discussed porting the "core" application code to .NET and then porting more advanced functionality across as-needed.

我们已经讨论了将“核心”应用程序代码移植到 .NET，然后根据需要移植更高级的功能。

采纳答案by Terry

When I saw the title, I was just going to lurk, being a renowned PB bigot. Oh well. Thanks for the vote of confidence, Bernard.

当我看到标题时，我只是要潜伏，成为一个著名的 PB 偏执狂。那好吧。感谢您的信任投票，伯纳德。

My first suggestion would be to ditch the language of self-deception. If I eat half of a "lite" cheesecake, I'm still going to lose sight of my belt. A migration can take as little as 10 minutes. What you'll be doing is a rewrite. The timeneeds to be measured as a rewrite. The riskneeds to be measured as a rewrite. And the design effortshould be measured as a rewrite.

我的第一个建议是抛弃自欺欺人的语言。如果我吃了一半的“精简版”芝士蛋糕，我仍然会看不到我的腰带。迁移可能只需 10 分钟。你要做的是重写。的时间需要作为重写要被测量。该风险需要作为重写来衡量。与设计工作应作为一个重写进行测量。

Yes, I said design effort. "Migrate" conjures up images of pumping code through some black box with a translation mirroring the original coming out the other side. Do you want to replicate the same design mistakes that were made back in 1994 that you've been living withfor years? Even with excellent quality code, I'd guess that excellent design choices in PowerBuilder may be awful design choices in C#. Does a straight conversion neglect the power and strengths of the platform? Will you be living withthe consequences of neglecting a good C# design for the next 15 years?

是的，我说的是设计努力。“迁移”让人联想到通过一些黑匣子泵送代码的图像，翻译反映了从另一侧出来的原始代码。您是否想重现 1994 年犯下并已忍受多年的相同设计错误？即使代码质量非常好，我猜想 PowerBuilder 中出色的设计选择在 C# 中可能是糟糕的设计选择。直接转换是否忽略了平台的力量和优势？你将与住忽略良好的C＃设计，为未来15年的后果是什么？

---

---

That rant aside, since you don't mention your motivation for moving "to .NET," it's hard to suggest what options you might have to mitigate the risk of a rewrite. If your management has simply decided that PowerBuilder developers smell bad and need to be expunged from the office, then good luck on the rewrite.

暂且不提，因为您没有提到您迁移到“.NET”的动机，所以很难建议您可能需要哪些选项来降低重写的风险。如果您的管理层只是认为 PowerBuilder 开发人员闻起来很糟糕，需要将其从办公室开除，那么祝您在重写时好运。

If you simply want to deploy Windows Forms, Web Forms, Assemblies or .NET web services, or to leverage the .NET libraries, then as Paul mentioned, moving to 11.0 or 11.5 could get you there, with an effort closer to a migration. (I'd suggest again reviewing and making sure you've got a good design for the new platform, particularly with Web Forms, but that effort should be significantly smaller than a rewrite.) If you want to deploy a WPF application, I know a year is quite a while to wait, but looking into PowerBuilder 12 might be worth the effort. Pulled off correctly, the WPF capability may put PowerBuilder into a unique and powerful position.

如果您只是想部署 Windows 窗体、Web 窗体、程序集或 .NET Web 服务，或者想要利用 .NET 库，那么正如 Paul 所提到的，迁移到 11.0 或 11.5 可以帮助您实现目标，并且更接近迁移。（我建议再次检查并确保您为新平台设计了良好的设计，尤其是 Web Forms，但这种工作应该比重写要小得多。）如果您想部署 WPF 应用程序，我知道一年需要等待相当长的时间，但研究 PowerBuilder 12 可能值得付出努力。如果正确使用，WPF 功能可能会将 PowerBuilder 置于独特而强大的位置。

If a rewrite is guaranteed to be in your future (showers seem cheaper), you might want to phase the conversion. DataWindow.NET makes it possible to to take your DataWindows with you. (My pet theory of the week is that PowerBuilder developers take the DataWindow for granted until they have to reproduce all the functionality that comes built in.) Being able to drop in pre-existing, pre-tested, multi-row, scrollable, minimal resource consuming, printable, data-bound dynamic UI, generating minimal SQL with built-in logical record locking and database error conversion to events, into a new application is a big leg up.

如果保证将来会进行重写（淋浴似乎更便宜），则您可能需要分阶段进行转换。DataWindow.NET 使您可以随身携带您的 DataWindows。（我本周最喜欢的理论是，PowerBuilder 开发人员认为 DataWindow 是理所当然的，直到他们必须重现所有内置功能。）资源消耗、可打印、数据绑定的动态 UI，生成最少的 SQL，内置逻辑记录锁定和数据库错误转换为事件，进入新应用程序是一个很大的优势。

You can also phase the transition by converting your PowerBuilder code to something that is consumable by a .NET application. As mentioned, you can produce COM objects with the PB 10 you've got, but will have to move to 11.0 or 11.5 to produce assemblies. The value of this may depend on how well partitioned your application is. If your business logic snakes through GUI events and functions instead of being partitioned out to non-visual objects (aka custom classes), the value of this may be questionable. Still, this is a design faux pasthat should probably be fixed before a full conversion to C#; this is something that can be done while still maintaining the PowerBuilder application as a preliminary step to a phased and then a full conversion.

您还可以通过将 PowerBuilder 代码转换为 .NET 应用程序可以使用的代码来分阶段过渡。如前所述，您可以使用已有的 PB 10 生成 COM 对象，但必须移动到 11.0 或 11.5 才能生成程序集。此值可能取决于您的应用程序的分区程度。如果您的业务逻辑绕过 GUI 事件和函数，而不是被划分到非可视对象（又名自定义类），则其价值可能值得怀疑。不过，这是一个设计失礼应可能是一个完全转化为C＃前固定; 这是可以完成的，同时仍然保持 PowerBuilder 应用程序作为分阶段然后完全转换的初步步骤。

No doubt I'd rather see you stay with PowerBuilder. Failing that, I'd like to see you succeed. Just remember, once you take that first bite, you'll have to finish it.

毫无疑问，我宁愿看到你留在 PowerBuilder。如果失败了，我希望看到你成功。请记住，一旦你吃了第一口，你就必须吃完。

Good luck finding that belt,

祝你找到那个腰带，

Terry.

特里。

---

---

I see you've mentioned moving "core components" to .NET to start. As you might guess by now, I think a staged approach is a wise decision. Now the definition of "core" may be debatable, but how about a contrary point of view. Food for thought? (Obviously, this was the wrong week to start a diet.) Based on where PB is right now, it would be hard to divide your application between PB and C# along application functionality (e.g. Accounts Receivable in PB, Accounts Payable in C#). A division that may work is GUI vs business logic. As mentioned before, pumping business logic out of PB into executables C# can consume is already possible. How about building the GUI in C#, with the DataWindows copied from PB and the business logic pumped out as COM objects or assemblies? Going the other way, to consume .NET assemblies in PB, you'll either have to move up to 11.x and migrate to Windows Forms, or put them in a COM callable wrapper.

我看到您提到将“核心组件”移至 .NET 以开始。正如您现在可能已经猜到的那样，我认为分阶段进行是一个明智的决定。现在“核心”的定义可能有争议，但相反的观点如何。深思熟虑？（显然，这是开始节食的错误一周。）基于 PB 现在的位置，很难根据应用程序功能（例如 PB 中的应收账款，C# 中的应付账款）在 PB 和 C# 之间划分应用程序。一个可行的划分是 GUI 与业务逻辑。如前所述，将业务逻辑从 PB 抽取到 C# 可以使用的可执行文件中已经是可能的。用 C# 构建 GUI，从 PB 复制 DataWindows 并将业务逻辑作为 COM 对象或程序集输出如何？反过来，在 PB 中使用 .NET 程序集，COM 可调用包装器。

Or, just train your C# developers in PowerBuilder. This just may be a rumour, but I hear the new PowerBuilder marketing tag line will be "So simple, even a C# developer can use it." ;-)

或者，只需在 PowerBuilder 中培训您的 C# 开发人员。这可能只是一个谣言，但我听说新的 PowerBuilder 营销标语将是“如此简单，即使是 C# 开发人员也可以使用它”。;-)

回答by gbjbaanb

If its rather large, you might have better results writing a front-end for it in .net (or a web-based GUI) and using that to interact with your PB code, assuming you can expose the functionality it as an API.

如果它相当大，您可能会在 .net（或基于 Web 的 GUI）中为它编写前端并使用它与您的 PB 代码交互，假设您可以将其功能公开为 API，则可能会获得更好的结果。

If you're using PB 9 or greater, you can generate COM or .NET dlls, that you can then consume by a C# GUI. I'd recommend this over a rewrite in any new language.

如果您使用 PB 9 或更高版本，您可以生成 COM 或 .NET dll，然后您可以通过 C# GUI 使用它们。我会推荐这个而不是用任何新语言重写。

Remember, rewrites are never a silver bullet, they always end up more time-consuming, difficult, and buggy than you first expect.

请记住，重写从来都不是灵丹妙药，它们最终总是比您最初预期的更耗时、更困难、更容易出错。

回答by Bernard Dy

I think gbjbaanb gave you a good answer above.

我认为 gbjbaanb 在上面给了你一个很好的答案。

Some other questions worth considering:

其他一些值得考虑的问题：

• Is this PB10 app a new, well-written PB10 app, or was it one made in 1998 in PB4, then gradually converted to PB10 over the years? A well-written app should have some decent segregation between the business logic and the GUI, and you should be able to systematically port your code to .Net. At least, it should be a lot easier than if this is a legacy PB app, in which case it would be likely that you'd have tons of logic buried in buttons, datawindows, menus, and who knows what else. Not impossible, but more difficult to rework.
• How well is the app running? If it's OK and stable, and doesn't need a lot of new features, then maybe it doesn't need rewriting. Or, as gbjbaanb said, you can put .Net wrappers around some pieces and then expose the functionality you need without a full rewrite. If, on the other hand, your app is cantankerous, nasty, not really satisfying business needs, and is making your users inefficient, then you might have a case for rewriting, or perhaps some serious refactoring and then some enhancements. There are PB guys serving sentences, er, I mean, making a living with the second scenario.

• 这个 PB10 应用程序是新的、编写良好的 PB10 应用程序，还是 1998 年在 PB4 中制作的应用程序，然后这些年来逐渐转换为 PB10 应用程序？一个编写良好的应用程序应该在业务逻辑和 GUI 之间有一些适当的隔离，并且您应该能够系统地将代码移植到 .Net。至少，它应该比如果这是一个传统的 PB 应用程序要容易得多，在这种情况下，你可能会在按钮、数据窗口、菜单中埋藏大量逻辑，谁知道还有什么。并非不可能，但更难返工。
• 应用程序运行情况如何？如果还可以，稳定，不需要很多新功能，那么也许就不需要重写了。或者，正如 gbjbaanb 所说，您可以在某些部分周围放置 .Net 包装器，然后在不完全重写的情况下公开您需要的功能。另一方面，如果您的应用程序很烦人、令人讨厌，不能真正满足业务需求，并且使您的用户效率低下，那么您可能需要重写，或者进行一些严重的重构，然后进行一些增强。有PB人在服刑，呃，我的意思是，以第二种情况为生。

I'm not against rewrites if the software is exceedingly poor and is negatively affecting the company's business, but even then gradual adjustments and improvements are a less risky way to achieve system evolution.

如果软件非常糟糕并且对公司的业务产生负面影响，我不反对重写，但即使如此，逐步调整和改进也是实现系统进化风险较小的方式。

Also, don't bail on this thread until after Terry Voth posts. He's on StackOverflow and is one of the top PB guys.

另外，在 Terry Voth 发帖之前不要放弃此线程。他在 StackOverflow 上并且是顶级 PB 人之一。

回答by Paul Lefebvre

You might want to spend some time investigating PowerBuilder 11.5(recently released) which adds some significant .NET integration.

您可能想花一些时间研究PowerBuilder 11.5（最近发布），它增加了一些重要的 .NET 集成。

Migrating to PowerBuilder 11.5 in order to make use of new .NET code will certainly be a lot easier than completely rewriting the entire app in C#.

迁移到 PowerBuilder 11.5 以使用新的 .NET 代码肯定比用 C# 完全重写整个应用程序要容易得多。

回答by RealHowTo

I don't know if it's good or not but check this (commercial) product : PB.Net

我不知道它是否好，但检查这个（商业）产品： PB.Net

回答by DaveE

My pet theory of the week is that PowerBuilder developers take the DataWindow for granted until they have to reproduce all the functionality that comes built in.

我本周最喜欢的理论是 PowerBuilder 开发人员认为 DataWindow 是理所当然的，直到他们必须重现所有内置功能。

I'd back that theory. I went though an attempted conversion from PB8 to Java on a project several years ago that failed miserably, even using the first-gen HTML DataWindow. My current employer is hell-bent on moving to C#, not using Datawindow.NET despite > 2K DWOs in our current product. I'm not looking forward to the day when the realization sets in. (the entire product consist of several user applications, more than a dozen services, and use about 70 PBDs)

我会支持那个理论。几年前，我在一个项目中尝试从 PB8 转换为 Java，但失败了，即使使用第一代 HTML DataWindow。尽管我们当前的产品中有超过 2K 的 DWO，但我现在的雇主一心想转向 C#，不使用 Datawindow.NET。我并不期待实现的那一天。（整个产品由几个用户应用程序、十多个服务组成，并使用大约 70 个 PBD）

OP - unless your application is unusually well-structured (originally written for EA Server maybe?), this will not be a port. Things work too differently in the PB & .NET environments for a plain port to work satisfactorily. I cannot stress this enough - if you're really using the PB event model, a "port" will likely be a failure.

OP - 除非您的应用程序结构异常良好（最初可能是为 EA Server 编写的？），否则这不会是一个端口。在 PB 和 .NET 环境中的工作方式非常不同，普通端口无法令人满意地工作。我对此再怎么强调也不为过——如果您真的在使用 PB 事件模型，那么“端口”可能会失败。

You need to look at logic flow (intertwined UI & process), control flow (who owns the process or data right now), data access (UI, data layer, ??) and the parts of the DW event model you're using from code. If you're thinking about ASP.NET (as we are), your whole user interaction experience will have to change, and that will feed back into the other considerations.

你需要看一下逻辑流（交织UI和过程），控制流（谁拥有的过程或数据，现在您正在使用），数据访问（UI，数据层，??）和DW事件模型的零件从代码。如果您正在考虑 ASP.NET（就像我们一样），您的整个用户交互体验将不得不改变，这将反馈到其他考虑因素中。

Not directly related to code, build automation will change (we use PowerGen for consistent PB builds; MSBuild is very different) as will your installation & setup.

与代码没有直接关系，构建自动化会发生变化（我们使用 PowerGen 进行一致的 PB 构建；MSBuild 非常不同）以及您的安装和设置。

回答by Dan Cooperstock

I think anyone considering this for a large app would be pretty crazy not to very seriously consider using the DataWindow.NET, so as not to lose their investment in the DWs.

我认为任何考虑将其用于大型应用程序的人都会非常疯狂，如果不认真考虑使用 DataWindow.NET，以免失去对 DW 的投资。

回答by psant

PHB's at major corporations think that Powerbuilder is a toy language and migrating to a new language like C# is trivial and can be done at a low cost. In fact, migrating a PB application to any other language will cost at least as much as developing an entirely new application on the new language. The resulting app will generally lose functionality compared to the original and will result in user dissatisfaction. I have seen a number of attempts - all have failed because of the difficulty and the user issues.

大公司的 PHB 认为 Powerbuilder 是一种玩具语言，迁移到像 C# 这样的新语言是微不足道的，并且可以以较低的成本完成。事实上，将 PB 应用程序迁移到任何其他语言的成本至少与在新语言上开发全新应用程序的成本一样高。与原始应用程序相比，生成的应用程序通常会失去功能，并会导致用户不满意。我已经看到了许多尝试 - 由于困难和用户问题，所有尝试都失败了。

If it ain't broke, don't fix it.

如果它没有坏，请不要修理它。

回答by LostCoder

Yes, it`s doable now without rewriting service components period.

是的，现在可以不用重写服务组件期间。

PB 12.5>

PB 12.5>

And target GUI and service component migrations and integrations to c#.

并将 GUI 和服务组件迁移和集成到 C# 的目标。

Migration/Integration strategy may vary depending your project scope, scalability, resources and timeline.

迁移/集成策略可能因您的项目范围、可扩展性、资源和时间表而异。

You can use these target and project types in PowerBuilder .NET. Refer this link Sybase_PB .Net

您可以在 PowerBuilder .NET 中使用这些目标和项目类型。请参阅此链接Sybase_PB .Net

• WPF Window Application WPF Window Application, WCF Client Proxy, or REST Client Proxy
• PB Assembly WCF Client Proxy, REST Client Proxy, or PB Assembly
• .NET Assembly WCF Client Proxy, REST Client Proxy, or .NET Assembly
• WCF Service WCF Client Proxy, REST Client Proxy, or WCF Service

• WPF 窗口应用程序 WPF 窗口应用程序、WCF 客户端代理或 REST 客户端代理
• PB 组件 WCF 客户端代理、REST 客户端代理或 PB 组件
• .NET 程序集 WCF 客户端代理、REST 客户端代理或 .NET 程序集
• WCF 服务 WCF 客户端代理、REST 客户端代理或 WCF 服务