Hands on: The future of C# and Delphi

In programming few things are really new. It is interesting to note that xBase programmers always enjoyed a form of language-integrated query.

All the more ironic then, that Microsoft’s conference included a session on ‘Moving from Foxpro to .Net’, in which the presenter argued that moving away from Foxpro was a necessity in the world of Vista and .Net Framework 3.0.

Foxpro is a Microsoft product, and is being equipped with extensions specifically for Vista and .Net integration, so it is not obsolete yet. Even so, .Net momentum is stronger than ever on Microsoft’s platform.

The Framework 3.0 release changes the game; with .Net 2.0, there is usually a native code equivalent to pieces of functionality in the .Net class libraries. In 3.0 that’s not the case, with both Windows Presentation Foundation and Windows Communication Foundation offering features that are hard to replicate. Another option is to interop with .Net, but this often means long-term full migration is desirable.

Borland Codegear
It was also in November that Borland announced the future of Delphi, its excellent native-code compiler and rapid application development (Rad) tool. Having said in February that it would sell Delphi and its other IDE tools, Borland switched track and announced the formation of Codegear, a wholly owned subsidiary. Why the change of heart? Probably because Delphi looks increasingly out of place in a .Net world.

Although Delphi includes a .Net compiler, Borland has struggled to keep it up to date. Delphi 2006 targets only .Net 1.1, and remains the current release a year after Microsoft issued Visual Studio 2005 and .Net 2.0. Delphi developers therefore tend to migrate to Visual Studio if they move to .Net.

Codegear’s main hope is that native code development remains important. There are dozens of reasons Win32 applications can be better than those in .Net or Java. Two obvious ones are simplicity of use, with few or no runtime libraries to distribute, and the ability to target every version of 32-bit Windows with a single executable. Another factor is low memory and resource requirements. For fast loading and snappy performance, native Win32 code cannot be beaten.

Codegear still has a hot product. Unfortunately, in Enterprise development, where a lot of the money is, the rich class libraries of .Net and its high productivity count for more than fast native code. It is also a tough market for any vendor of developer tools, because of the high quantity and quality of free and open-source options.

Visual Basic not quite dead
Microsoft’s mainstream support for Visual Basic 6.0, the last version to target Win32 as opposed to the .Net runtime, ended on 31 March 2005; and even the last-stop ‘extended’ support ends in March 2008.

Nevertheless, Microsoft is still shipping a Visual Basic editor. This is because it remains the macro engine in Microsoft Office, and the core Visual Basic for Applications runtime is the same as that in VB 6.0, though the forms engine is different.

There is some confusion about this because Microsoft is encouraging Office developers to use .Net VSTO (Visual Studio Tools for Office) in their Office automation solutions. VSTO has substantial advantages, such as access to the rich .Net Framework library and the choice of VB.Net or C#.

It has disadvantages as well, requiring Visual Studio to develop, and deployment of the .Net runtime to users. VSTO also requires at least Office 2003. Another factor is that VSTO is overkill for a simple macro, whereas VBA is ideal. Microsoft Office still makes extensive use of COM, so it works well with the equally COM-based VBA, whereas VSTO is an interop solution.