What are the most common ways used to migrate a Delphi application incrementally to .NET?

Question

If you have several million lines of Delphi code and want to incrementally migrate to .NET/C#, what strategy would you use?

Answer 1

I'd take a long hard look at Delphi Prism to migrate to .NET without rewriting in C#.

Answer 2

Option1:

• Step 1: Find what pieces of the application can be broken off and rewritten individually.
• Step 2: Get cracking. (It may take a while)

Option 2:

• Step 1: Don't rewrite it because it may be a bad idea.

Answer 3

I had to do exactly this, although it wasn't several million lines, it was an order of magnitude lower than that.

I did it by implementing web services in .NET. Even the old versions of Delphi have decent SOAP support, so you can just start swapping out entire modules for web services written in .NET (just use the basic profile, no WS-* extensions).

And when you're done, you have a beautiful loosely-coupled SOA.

Answer 4

Here is another alternative that I have found to be very effective. Now keep in mind that no matter what you do it will be a hell of a lot of work but by taking in all this advice I think you can pull it off.

One of the great things about C# is that it can register your assemblies for COM interop and will generate all of those nasty interfaces for you. What we did was take modules from our poorly designed VB6 application and have them use functionality from .NET.

Something you really need to remember is to keep your interfaces simple. Try to only require simple types to be passed to .NET. Also you will need to have a considerable amount of upfront planning to layout what functionality you will expose from .NET. You will need to perform extensive refactoring to make sure your new objects will integrate properly with the legacy code.

Once again there is no way you can turn this into an easy task but it can be done.

Answer 5

I've seen several attempts at this. So far I can't call any of them a success.

Why do people suggest to spend tons of man-hours to port something to another language?

Usually it's a combination of these:

• lacking programming skills and knowledge of the original language

• developers not wanting to learn another language, so instead they want to convert all code to their favourite language.

• developers not understanding the existing code base, so they underestimate the amount and complexity of existing features

• overestimating the advantages that a port would bring

• people not having read Joel Spolsky's "things you should never do" :-)

Slap those together, and you've got yourself a recipe for disaster.

Answer 6

Identify the part of the delphi code not being used and mark it to not be converted. Press those in charge to make a solid commitment to keeping any of the functionality. When they say, "Well we may need it." get rid of it and promise to add it back to the new version.

See if you can rework any current change requests to the new language. There have been good suggestions on creating services.

Identify problematic pieces of code that has had a lot of bugs identified. It may be worth a rewrite.

It is tough to justify converting what is left, but eventually, the rest of the code may fall under the first three suggestions as time goes by. Business rules may change along the way.

Answer 7

The two methods I've used in the past are

• COM interop (i.e. register either/or/both Delphi and C# for COM and then each can instantiate each others' objects pretty easily)

• Use mixed-mode C++ as an intermediary to marshal data between Delphi and C#. The C++ can be spoken to from Delphi as a standard DLL and spoken to by C# as a standard .NET library.

Answer 8

You can actually use RemObjects Hydra to combine Delphi and .NET code into a single application. It lets you create plugin modules with either tool, and then combine them together. I've talked to people who have used it to add .NET features to legacy Delphi applications, as wall as others who have used it to move parts of their legacy Delphi application into a new .NET application.

Full disclosure: I work for RemObjects, but I honestly think Hydra is a great tool. More Delphi developers need to know about it because it means you can keep using the best tool for each part of the application: .NET or Delphi.

Answer 9

I just started working with Hydra and in my view you still have to expose interface yourself. Because I didn't need much it was not a problem for me, but it might be a pain if you need a bunch.

That said I think Hydra is great for having the opportunity of using .net in Delphi fast. I was forced to implement a .net SAML client because Microsoft not always follows the exact standard. For this purpose Hydra worked fine.