Back in 2002, Sybase announced their four-phase approach toward adding .NET support to PowerBuilder. Phase 1 was the implementation of web services in PB9 and Phase 2 was the release of DataWindow.NET, which was packaged with PB 10. Phases 3 and 4 were the more significant phases. In Phase 3, Sybase added a number of .NET target types to PowerBuilder 11 and added support for calling non-visual .NET assemblies from PowerScript. The 4th phase will be completed in PowerBuilder 12 and involves “...support for Windows Presentation Foundation (WPF) ... as well as full support for visual controls and drag-and-drop programming with .NET within the IDE”.1 We’re at the mid-point between the release of PowerBuilder 11 (phase III) and the release of PowerBuilder 12 (phase IV, which should complete .NET support). I thought it might be beneficial to review the progress so far and reassess what the future looks like.

Web Services
While PB9 did provide some original support for web services, it wasn’t until the 10.5 release when the .NET engine was added that such support became highly useable. The previous engine, built on the EasySOAP open source library, became largely feature frozen in 2002 when the EasySOAP project essentially became abandonware (http://en.wikipedia.org/wiki/Abandonware). The .NET engine introduced with PB 10.5 did bring the client proxy creation capability to current standards, but there are still some problems with the implementation. For example, PowerScript functions can’t return arrays, and the proxy object is limited to what PowerScript can support. As a result, you currently can’t create a proxy for a web service method that returns an array and expect to be able to do anything with the result (it gets cast as an “any” data type). There is also currently no support for WS-Security (most likely because that’s an add-on feature for .NET 2.x, not part of the original SDK) and for protocols other than SOAP (e.g., REST, JAX-RPC). It’s possible that those latter two issues will be addressed as Sybase implements support for WCF (Windows Communications Foundation) in PowerBuilder 12.0.

DataWindow.NET
DataWindow.NET hasn’t stood still since it was first introduced and packaged with PowerBuilder 10 either. Version 1.5 introduced the WebDataWindowControl. Version 2.0 added support for ADO DataSets as a data source, the TreeView presentation style and autosize height for non-detail bands. Version 2.5 finally brought the DataWindow Designer into the VS IDE, added support for the TreeView presentation style to web DataWindows, and added web services as a data source.

There are still some impediments to acceptance of DataWindow.NET into traditional .NET shops though. The first is the requirement to keep the DataWindow source in a PBL. A PBL makes sense to PowerBuilder developers because the compiled version of objects is kept there. It makes absolutely no sense in a VS.NET environment, particularly because a DataWindow isn’t compiled. It makes it confusing for new developers to get started and hinders proper source code management. Perhaps a bigger issue is the amount of work it takes to deploy an application that uses DataWindow.NET. The developer has to remember to include the PBD that contains the DataWindow, four or more unmanaged code runtime files, and (if PDF is used) download and install GhostScript.

WinForm Targets
WinForm targets were introduced in PowerBuilder 11, which is pretty much just a .NET compile of the Win32 version of the application. Somewhat akin to the machine code compilation, the PB source code is converted to C# and then compiled. One difference though, introduced in PowerBuilder 11.1, is the ability to do an incremental compile (machine code compiles are always an all or nothing proposition).

In the future, this particular target may become more useful as Win32 is phased out in future versions of Windows. However, at the moment, the primary advantage of this particular target is that you can include conditional code blocks within PowerScript that reference non-visual .NET assemblies (either .NET system assemblies or third-party assemblies) and that code becomes active when compiled in a WinForm target.

Unfortunately, the syntax that you need to use within the conditional code block is neither C# or PowerScript, but a morph of the two that is poorly documented and does not yet provide full support for all .NET language features. That, and the limitation of such usage to non-visual assemblies, has restricted the traction this particular feature has obtained. Because there are some Win32 features that are not supported in a WinForm target, a lot of testing that has to be done to ensure that a WinForm target works the same as the Win32 version and it has limited advantages.

Perhaps a bigger question surrounds the future of WinForms, regardless of the tool used to create them. Microsoft added WPF (Windows Presentation Foundation) to .NET as of version 3.0. There is a great deal of emphasis on it as the future for doing graphical interfaces. This has resulted in a great deal of debate within the .NET community about whether WPF is currently robust enough to handle LOB (line of business) applications.2 Sybase has already demoed the WPF DataWindow, so they are working toward supporting WPF.

SmartClient Targets
SmartClients are actually a subcategory of the WinForm target, but I thought that they are worth a special mention. This is the other major advantage I see to a WinForm deploy, the ability to deploy a “rich client” application to a client without the impact on the client configuration that rich clients generally require. Usually this feature works well. There’s still some area for improvement though, mainly having to do with the ability to easily customize how the application is deployed (how the web page appears, etc.). ClickOnce technology, which the SmartClient is based on, is also supported as a deployment option for WPF-based applications, so we should continue to have that capability regardless of whether we use a WinForm or WPF approach in later versions of PowerBuilder.