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.
{ 17 } Comments
Add a row to point out that VCL can be linked into your exe, to produce a single-exe deployment. WinForms cannot be linked into your app, it’s always an external reference.
Thanks, Danny. I did add that point. But unless I’m missing something, a non-statically-linked WinForms app is still a single EXE deployment, since WinForms is installed with the framework.
Future migration?
(Danny Thorpe wrote
"its reasonable to surmise that VCL for .NET might adapt to the changes expected in Longhorn more readily than WinForms")
Isn’t Danny hinting that VCL might well have more in common with Longhorn and Avalon in the future than WinForms?
VCL code I wrote in Delphi 1 still works in Delphi 8. Borland have clearly put a lot of effort into VCL.NET. I’m not sure that this same long-term commitment applies to WinForms.
In other words there may be a case that new Delphi 8 applications should use VCL, as it has already shown how it can provide continuity and smooth migration.
I’m a little out of the loop on this one, but this is something I am curious about: If I’m planning on using my project with mono, do I need to be concerned which I choose?
Regarding what Danny is hinting, I try and avoid putting words into his mouth. My suspicion is that when Avalon is ready for prime time both WinForms and the VCL for .NET will still be supported, but many developers will want to migrate to Avalon.
Regarding Mono, I avoided talking about it because it would be speculation on my part. Mono’s WinForms implementation — no, implementation*s* — are still in beta, so it’s very difficult to make conclusions right now. One of the implementations is based on WineLib. I don’t know if the VCL for .NET will work with WineLib, but it’s not unreasonable to guess that it’s possible. If so, you could use either one, and the VCL for .NET might work better than Mono’s WinForms. If not, the subset of WinForms features which work in Mono would be the only choice.
But this is all speculation.
About using legacy code: If you rely on setting the value of inherited fields before calling inherited create in any of your classes, you must redesign these classes as this is not supported in Delphi for .Net. This fact is often overlooked in articles about porting old code to VCL for .Net.
ADO.NET (BDP) is not available with VCL
Hi
i have a question about paradox database in for foreign.
i have a databse which have farsi language data how can i sort it according to farsi alphabetic?
thank u
mohammad
info@ekhorasan.com
David (Burke), that’s not quite true. See the Dr. Bob article I linked on TADONETConnector:
http://www.drbob42.com/examines/examin62.htm
I take it that this really surprised you.
Your list looks confused.
Why is this:
"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."
listed under winforms.
Your "remember me" seems to have amnesia.
People have to notice that in the VCL.NET as it is released today there is no way to run programs using it on Mono, so if anyone needs to interop with Mono will have to choose between Windows.Forms and GTK#, at least until Borland makes VCL.NET free from Win32 API PInvoke dependencies.
Alexandre, I disagree that Borland needs to remove use of the Windows API to make this work. One of Mono’s two WinForms implementations, after all, uses the WinAPI (via WineLib). Nevertheless I agree that if you need to run on Mono right now WinForms is a better choice.
How could VCL avoid to call the Win32 API? Performing a full drawing of controls in pure .NET code? Ugh, it will become the .NET equivalent of Java SWING.
VCL.NET is a choice because it works at the same level of WinForms (that calls the Win32 API too…), not because it is build on top of it, which would make it much slower.
There are some parts of ECO sources included in the distro, albeit not all.
–Jesper
Post a Comment