Choosing Between VCL for .NET and WinForms
Choosing Between VCL for .NET and WinForms
Introduction
Delphi for .NET developers have two choices for developing Windows user interfaces: Microsoft’s Windows Forms framework, and Borland’s VCL for .NET framework. Neither of these is appropriate for all applications. This article is a simple guide to how to determine which choice is right for your projects.
Factors You Need to Consider
| Factor | VCL for .NET | WinForms |
|---|---|---|
| Avalon migration | If you have a large body of VCL for Win32 source code and intend to migrate to Avalon when Longhorn becomes popular, it may not make sense to migrate to WinForms in the meantime, since it appears to have little more in common with Avalon than the VCL does. Also, Borland has announced that the VCL will be ported to Avalon. | Microsoft has made it clear that WinForms will not (at least immediately) disappear when Avalon is released, and there will be some level of interoperability between WinForms and Avalon. But to get the full benefits of Avalon you will probably need to rewrite your UI layer. |
| Compact Framework support | None right now. It has been announced for the future, though. | Supported by the CF and the Delphi 2006 compiler, but the IDE support is not as good as for the desktop framework — you essentially use the IDE to design a desktop app and then manually remove the stuff which doesn’t work on CF. You will probably not want or be able to use a single application on both Windows desktop and Compact Framework due to limitations of the latter both in terms of what is included and UI considerations. |
| Component selection | The included selection of components is very good, but the third-party market is more limited than it is for the Win32 VCL. | The included selection of components is quite limited, but the third-party market is fairly good. |
| Developer skills | Developers familiar with the VCL for Win32 will feel right at home with the VCL for .NET. There are a few changes, but it will be a very smooth transition. However, no .NET developer should be ignorant of WinForms, so you should learn both frameworks even if you intend to use only the VCL for .NET. | Developers unfamiliar with the VCL for Win32 should probably learn WinForms first since most .NET UI documentation is written around WinForms. |
| Deployment concerns | If you choose to reference rather than link the VCL for .NET assemblies, administrators may need to grant these assemblies full trust privileges when your app will be run under restricted security settings, such as in a browser or on a network share. The VCL for .NET adds to the size of your deployment, but it’s small in comparison to the .NET framework itself. | Nothing beyond what is already involved in deploying .NET. |
| ECO compatibility | Works, but is more limited than WinForms | Excellent. |
| Framework source code | Included, except for dbExpress/BDP drivers, ECO, and midas.dll. | Not included. |
| Interoperability with non-Delphi code | .NET applications not written in Delphi won’t deal well with VCL classes. You may need to write a separate interop layer using FCL classes. However, Delphi for .NET can automatically generate wrapper components allowing you to use WinForms controls on a VCL for .NET form, so this isn’t necessarily a very difficult task. Non-UI code — even code which uses the Delphi RTL — may work fairly well in other languages, although certain constructs, such as virtual constructors, will look a little odd to a C# programmer, if you choose to use them. | Excellent |
| Linking | You may either statically link the VCL assemblies, creating a monolithic (save for the FCL) EXE, or reference them. | You must reference the WinForms assemblies. It is not possible to statically link them, unless you use a tool not included with the framework. |
| Performance | Good. | Very limited at present due to lack of video hardware support in GDI+. |
| 64 bit .NET compatibility | Delphi 2005 executables can run in the 64 bit .NET CLR if you don’t do stuff which is incompatible with that platform. Note VCL for .NET currently (as of D2005) does stuff which isn’t compatible with the 64 bit CLR, so VCL for .NET apps will run in the 32 bit CLR, even on 64 bit Windows. Borland will support VCL for 64 bit .NET in a future release. | Fully compatible, if using .NET 2.0+. |
| Third-party component availability | Some, but limited. Developer Express, Woll2Woll, and others make VCL for .NET components, but the selection is not as big as for VCL for Win32. | Excellent. |
| Use of legacy code | Excellent. You may have to change code for performance reasons, but most legacy code will at least work without modification. Exceptions include DataSnap servers and dbGo (ADO). Also, Bold applications must be ported to ECO, which is largely a rewrite of implementation code, although you should be able to keep your model. | You will need to rewrite your UI code. However, you can use the RTL portion of the VCL for .NET and may be able to get much of your business logic working this way. If you have any code which uses a TDataset subclass it may help to know about the TADONETConnector. |
| Win32 ("native") support | Excellent. In many cases you can create both Win32 and .NET applications from a single source base. | None whatsoever, and probably never will support this platform. |
| Win64 ("native") support | Coming in a future release. | None whatsoever, and probably never will support this platform. |
Have I missed any considerations in this chart? If so, please leave a comment.