将PowerBuilder应用程序移植到.NET
有没有人有任何建议将PowerBuilder 10业务应用程序迁移到.NET？
我的公司正在考虑将传统的PB应用程序迁移到.NET（C＃），我只是想知道是否有人有任何经验 – 好的或坏的 – 你想分享。
该应用程序相当大，包含10个PBL库，一些PFC以及自定义框架。 还有大量的DLL调用。 最后，它使用Microsoft SQL Server数据库。
我们已经讨论过将“核心”应用程序代码移植到.NET，然后根据需要移植更高级的function。
当我看到这个头衔时，我只是潜伏着，成为着名的PB bigot。 那好吧。 感谢Bernard的信任投票。
我的第一个建议是放弃自欺欺人的语言。 如果我吃一半“精简”芝士蛋糕，我仍然会看不到我的皮带。 迁移只需10分钟。 你要做的就是改写 。 需要将时间作为重写来衡量。 风险需要作为重写来衡量。 设计工作应该作为重写来衡量。
是的，我说过设计工作。 “迁移”通过一些黑盒子让人想起泵代码的图像，翻译镜像原来的另一面。 你想复制1994年你曾经生活多年的同样的设计错误吗？ 即使有优质的代码，我猜想PowerBuilder中出色的设计选择可能是C＃中糟糕的设计选择。 直接转换会忽视平台的强大function吗？ 您是否会承受在未来15年内忽略良好C＃设计的后果？
除此之外，由于你没有提到你转向“.NET”的动机，因此很难说明你可能有哪些选择来降低重写的风险。 如果您的管理层只是认为PowerBuilder开发人员闻起来很糟糕并且需要从办公室中删除，那么重写就好运了。
如果您只是想部署Windows窗体，Web窗体，程序集或.NET Web服务，或者利用.NET库，那么正如Paul所提到的那样，迁移到11.0或11.5可以帮助您实现迁移。 （我建议再次检查并确保你已经为新平台设计了一个好的设计，特别是使用Web Forms，但是这个工作应该比重写要小得多。）如果你想部署一个WPF应用程序，我知道一年是等待很长一段时间，但调查PowerBuilder 12可能是值得的。 正确拉出，WPFfunction可能使PowerBuilder成为一个独特而强大的位置。
如果保证在将来重写（淋浴看起来更便宜），您可能希望逐步进行转换。 DataWindow.NET使您可以随身携带DataWindows。 （我本周的宠物理论是，PowerBuilder开发人员将DataWindow视为理所当然，直到他们必须重现内置的所有function。）能够放入预先存在的，预先测试的，多行的，可滚动的，最小的资源消耗，可打印，数据绑定的动态UI，生成最小的SQL，内置逻辑记录锁定和数据库错误转换为事件，进入新的应用程序是一个很大的问题。
您还可以通过将PowerBuilder代码转换为.NET应用程序可以使用的代码来分阶段转换。 如上所述，您可以使用您已获得的PB 10生成COM对象，但必须移至11.0或11.5才能生成程序集。 这个值可能取决于您的应用程序的分区程度。 如果您的业务逻辑通过GUI事件和函数进行窃取而不是被分区到非可视对象（也称为自定义类），那么这个值可能会有问题。 不过，这是一个设计失误，应该在完全转换为C＃之前修复; 这可以在保持PowerBuilder应用程序作为分阶段然后完全转换的初步步骤的同时完成。
毫无疑问，我宁愿看到你留在PowerBuilder。 如果做不到这一点，我希望看到你成功。 请记住，一旦你吃了第一口， 你就必须完成它 。
祝好运找到腰带，
特里。
我看到你提到将“核心组件”移动到.NET开始。 正如你现在可能猜到的那样，我认为分阶段的方法是一个明智的决定。 现在，“核心”的定义可能存在争议，但如何相反的观点。 深思熟虑？ （显然，这是错误的一周开始节食。）根据PB现在的位置，很难在PB和C＃之间沿着应用程序function划分应用程序（例如PB中的应收帐款，C＃中的应付帐款）。 可能有效的部门是GUI与业务逻辑。 如前所述，将业务逻辑从PB中抽取到C＃可以消耗的可执行文件中已经是可能的了。 如何在C＃中构建GUI，从PB复制DataWindows并将业务逻辑作为COM对象或程序集抽出？ 换句话说，要在PB中使用.NET程序集，您要么必须升级到11.x并迁移到Windows窗体，要么将它们放在COM可调用包装器中 。
或者，只需在PowerBuilder中培训您的C＃开发人员。 这可能只是一个谣言，但我听说新的PowerBuilder营销标签将是“如此简单，即使是C＃开发人员也可以使用它”。 😉
我想gbjbaanb给了你一个很好的答案。
其他一些值得考虑的问题：
- 这款PB10应用程序是一款全新的，写得很好的PB10应用程序，还是1998年在PB4上制造的应用程序，多年来逐渐转换为PB10？ 一个编写良好的应用程序应该在业务逻辑和GUI之间进行一些适当的隔离，并且您应该能够系统地将代码移植到.Net。 至少，它应该比这是一个传统的PB应用程序容易得多，在这种情况下，你可能有大量的逻辑埋在按钮，数据窗口，菜单，谁知道还有什么。 并非不可能，但更难以返工。
- 该应用程序的运行情况如何？ 如果它可以稳定，并且不需要很多新function，那么它可能不需要重写。 或者，正如gbjbaanb所说，你可以将.Net包装器放在一些部件上，然后在没有完全重写的情况下公开你需要的function。 另一方面，如果你的应用程序是令人厌恶的，令人讨厌的，不是真正令人满意的业务需求，并且使你的用户效率低下，那么你可能会有重写的情况，或者可能是一些严重的重构，然后是一些增强。 有PB人服刑，呃，我的意思是，用第二种情景谋生。
如果软件非常差并且对公司的业务产生负面影响，我不反对重写，但即使这样，逐步调整和改进也是实现系统发展的风险较小的方法。
此外，在Terry Voth发布之前不要保释这个post。 他在StackOverflow上，是最顶尖的PB之一。
如果它相当大，你可能会有更好的结果在.net（或基于Web的GUI）中为它编写前端并使用它来与你的PB代码进行交互，假设你可以将它作为API公开。
如果您使用的是PB 9或更高版本，则可以生成COM或.NET dll ，然后可以通过C＃GUI使用它们。 我建议用任何新语言重写。
请记住，重写永远不是一颗银弹，它们总是比你最初期望的更耗时，更困难，更多。
您可能需要花一些时间来研究PowerBuilder 11.5 （最近发布），它增加了一些重要的.NET集成。
迁移到PowerBuilder 11.5以便使用新的.NET代码肯定比在C＃中完全重写整个应用程序容易得多。
我不知道它是否好，但检查这个（商业）产品： PB.Net
本周我的宠物理论是PowerBuilder开发人员将DataWindow视为理所当然，直到他们必须重现内置的所有function。
我支持这个理论。 几年前，我在一个项目中试图从PB8转换到Java，即使使用第一代HTML DataWindow，它仍然失败了。 我现在的雇主非常想转向C＃，尽管我们目前的产品中使用了> 2K DWO，但并没有使用Datawindow.NET。 我不期待实现的那一天。（整个产品包括几个用户应用程序，十几个服务，并使用大约70个PBD）
OP – 除非您的应用程序结构exception结构（最初是为EA Server编写的？），否则这不是端口。 在PB和.NET环境中，事情的工作方式完全不同，以便普通端口能够令人满意地工作。 我不能强调这一点 – 如果你真的使用PB事件模型，“端口”可能会失败。
您需要查看逻辑流程（交织的UI和流程），控制流程（谁现在拥有流程或数据），数据访问（UI，数据层，??）以及您正在使用的DW事件模型的各个部分来自代码。 如果您正在考虑使用ASP.NET（就像我们一样），您的整个用户交互体验将不得不改变，这将反馈到其他考虑因素。
与代码没有直接关系，构建自动化将发生变化（我们使用PowerGen进行一致的PB构建; MSBuild非常不同），您的安装和设置也将如此。
我认为任何考虑将其用于大型应用程序的人都会非常疯狂，不要非常认真地考虑使用DataWindow.NET，以免失去对DW的投资。
大公司的PHB认为Powerbuilder是一种玩具语言，并且迁移到像C＃这样的新语言是微不足道的，并且可以以低成本完成。 实际上，将PB应用程序迁移到任何其他语言所花费的成本至少与在新语言上开发全新应用程序一样多。 生成的应用程序通常会丢失与原始应用程序相比的function，并将导致用户不满意。 我已经看到了许多尝试 – 由于困难和用户问题，所有尝试都失败了。
如果没有损坏，请不要修理它。
是的，如果没有重写服务组件期间，它现在可行。
PB 12.5>
并将目标GUI和服务组件迁移和集成到c＃。
迁移/集成策略可能因项目范围，可伸缩性，资源和时间线而异。
您可以在PowerBuilder .NET中使用这些目标和项目类型。 请参阅此链接Sybase_PB .Net
- WPF窗口应用程序WPF窗口应用程序，WCF客户端代理或REST客户端代理
- PB程序集WCF客户端代理，REST客户端代理或PB程序集
- .NET程序集WCF客户端代理，REST客户端代理或.NET程序集
- WCF服务WCF客户端代理，REST客户端代理或WCF服务