What tools exist to convert a Delphi 7 application to C# and the .Net framework?

Question

I maintain an old PC-only application written in Delphi 7. Although Delphi has served me very well in the past I now only use it for this one application and find my skills with the language diminishing. Its syntax is too different from my 'day job' languages of Java/Ruby so it takes me longer to get into the groove of writing new code, plus it is so old I have not used many interfaces so the code is not managed which seems ancient to me now!

Many of my users are moving to Vista which may run the app in compatibility mode or may have GPF problems depending on how their PC is configured by their IT department, so I have to do some maintenance on the application. I'm wondering if I should jump to a more familiar stack.

Is there an automated tool that will do the legwork of converting the code base to C#, leaving me to concentrate on the conversion on any non-standard components? I'm using an embedded database component called AbsoluteDatabase which is BDE compatible and using standard SQL throughout, and a native Delphi HTML browser component which can be swapped out with something from the Microsoft world.

How good are these conversion tools?

Answer 1

I am not aware of any automated tools for making that conversion. Personally I would suggest you stick with Delphi, maybe just upgrade to a new version. I have seen a couple code DOM's that attempt to convert from Delphi to C#, but that doesn't address the library issue.

CodeGear (formally Borland) has a tool for going from C# to Delphi that works OK. I would assume the tools that go the other direction will work the same (requiring a lot of editing). Here is a Swedish tool that works on the same CodeDOM principle to go from Delphi to C# (and a number of other languages). There are others, I just can't find them right now.

Another option would be to upgrade to a more resent version of Delphi for .NET and port your code to .NET that way. Once you get it working in Delphi for .NET (which will be pretty easy, except for the embedded DB, unless they have a .NET version) you can use .NET Reflector and File Disassembler reverse the IL to C#. You will still be using the VCL, but you can use C# instead of Object pascal.

Another similar solution would be to port it to Oxygene by RemObjects. I believe they have a Delphi Win32 migration path to WinForms. Then use .NET Reflector and File Disassembler reverse the IL to C#.

In short, no easy answers. Language migration is easier then library migration. A lot of it depends on what 3rd party components you used (beyond AbsoluteDatabase) and if you made any Windows API calls directly in your application.

Another completely different option would be too look for an off shore team to maintain the application. They can probably do so cheaply. You could find someone domestically, but it would cost you more no doubt (although with the sagging dollar and poor job market you never know . . . )

Good luck!

Answer 2

Many of my users are moving to Vista which may run the app in compatibility mode or may have GPF problems depending on how their PC is configured by their IT department, so I have to do some maintenance on the application. I'm wondering if I should jump to a more familiar stack.

Unless you are doing something non standard, D7 applications should run fine in Vista.

As for conversion to C#, I would think that most conversion tools would be a waste of time. A better approach may be to rewrite the application from scratch.

Answer 3

There is no easy answer, but bear in mind that the Delphi.net variant of the language targets the .net runtime, and that different languages on .net can interoperate closely.

You could try getting it to compile in Delphi.Net, factoring into different assemblies and then converting the assemblies by hand one by one. Reflector could help be reverse-engineering compiled code into a skeleton of C# code - equivalent but without comments, internal variable names etc.

On the other hand, Delphi.net may be good enough (TM) for this project.

But unless you have a good test suite (I'm guessing probably not, given the state of the art in Delphi 7) you're going to introduce bugs.