Migrating a Delphi 7 application to .NET

Question

Any advice on how to migrate an existing Delphi 7 business application to .NET 2.0 in Visual Studio 2005?

Visual Studio 2005 has already been purchased, the company want to move away from the Borland/Codegear tools.

The application is a single client server executable, utilitising a number of 3rd party UI controls and Crystal reports 10 for reporting.

There is extensive business logic spread across Delphi types in the UI as well as many SQL Server 2000 stored procedures. Moving much of the stored proc logic into .NET classes is another goal.

To reduce impact on customers, a piece by piece approach rather then a complete re-write/conversion would be preferred, if possible. Thanks in advance.

[Update] Has anyone had any experience, good, bad or ugly, using Managed VCL for this type of scenario?

Answer 1

A piecemeal conversion would mean changing the native Delphi code to use COM so the .NET side can co-exist with Delphi (or possibly using some other technology - hard to say)

If you can, it might be easier to convert the app to Delphi.NET first, then at least the .NET bits will be able to communicate a little easier.

Just a thought.

Answer 2

Only you can really decide if a piece by piece approach is possible. For example can the application be divided up easily or are all the forms too strongly coupled with all the business logic. Technically it's possible but all depends on how the code base is structured really.

Answer 3

That sounds like a really bad idea to me.

Is there any technological advantage for your product to be in .NET, or is it mostly a political decision to be a Microsoft shop? For client-server, Delphi is pretty tough to beat. I've used VS2005/8 and it is really and truly genuinely and sincerely not as good as Delphi for Win32 development. But if you're going to migrate to the web down the road, then VS has definite advantages.

If stubborn business folks simply refuse to use Delphi anymore, then KiwiBastard is correct, IMO. Convert first to Delphi.NET, then migrate from there to VS2005. Or 2010, since that is a more realistic timeline :)

Answer 4

I recently worked at a company that was migrating from Delphi to WPF/.Net. We tried a piece by piece approach. It was painful. We were always running into subtle bugs in the interop. Calling from Delphi to WPF or Winforms and back is painful. If the various UI controls and windows of your application call on each other a lot, I think you will experience significant growing pains.

If you can afford to do the whole conversion at once I would go for it. If not, split out the parts of your app that are stand-alone or have the minimum of interactions with the rest of the app.

I would also suggest jumping into .Net 2008. Why are you picking a technology that is almost 4 years old (VS 2005)? I think it is a very, very bad business decision to choose to jump into .Net 2.0 when .Net 3.5 is very stable. The only valid reason I would ever present to management for .Net 2.0 would be to support Windows 2000. Do you still have customers on Win2k? Will you still have customers on Win2k by the time your conversion is complete? Do you have customers you cannot get to move to XP or Vista? .Net 3.0 and 3.5 are not supported in Win2k. That is the only downside I can think of.

.Net 3.5 and C# 2008 offer significant advantages for your company. You have a number of language features that will accelerate develop time compared to C# 2.0. You have WPF, which is vastly superior to Winforms. I would argue that you can develop the same batteleship-gray Windows you would get in Winforms with WPF, develop them faster, and when you want some eye-candy you will be using a technology that can easily provide it. If you are learning a new windowing platform for this conversion, why not invest in learning the new stuff?

Also, please tell me you didn't actually buy VS 2005. You can buy an MSDN Universal license for about the same cost, and get every development related product Microsoft makes. Buy it from a 3rd party and you will get a good discount.

Sorry if I came off negative. Sincerely, good luck on the migration. I just have flashbacks when I think of having to give up all the goodies in .Net 3.5.

Answer 5

For me the question would be: which language would you be using? I do hope C# and not VB.Net. (With all the awkward politics in this usecase this is not clear by any means.)

The next you will probably hear is that there are converters out there that will help you doing this. We just went through an evaluation of such converters (Delphi 7 to C#) and were very! disappointed.

May I suggest a compromise? How about Delphi Prism? It is Delphi in VS2008. Sure, you still have Delphi and therefore Codegear, but you also have VS (as your company expects you to).

Answer 6

I previously worked at a company that wanted to convert from Delphi to C#.NET because .NET is all cool and shiny. They brought in some more developers who had a lot of C# experience and it ended up taking 3 times the developers twice as long to port the application to C# then it did to write it the first time in Delphi for very little additional ROI (a few new features were added in the process). Plus the customers were not happy with the application performance or the UI.

Case study after case study shows that rewriting is a bad idea. (Hat tip to kogus)

If you must move to .NET (yeah, I know, you didn't make the decision, someone with less information did) then I would suggest using Delphi for .NET or RemObjects Oxygene. The latter being a Visual Studio plug-in. But even marc hofman, the Chief Software Architect of RemObjects Oxygene has said it is a bad idea to migrate a perfectly working application to .NET "just because."

If you can wait for Delphi Prism, which is also a Visual Studio add-in and is expected to be out later this year.

Answer 7

Moving away from CodeGear/Borland tools basically eliminates any Delphi .NET based solution and a total rewrite of your application.

I hope my answer below helps with your decisions.

From experience (having rewritten a Delphi application with a team of people) it boils down to either of two choices below.

But first a warning: you will take at least the total development effort it took to write your current Delphi application.

In our case, this effort was warranted since the old Delphi application (which in fact it was Kylix) had an end-of-life because of various reasons. Our rewrite consisted of two parts: rewrite with limited extra functionality followed by a lot of extra functionality (the design of the first part already took the second part into account).

Back to your choices:

1- a total rewrite in C# or VB.NET in Visual Studio

2- a partial reuse of your existing Delphi business layer code by using Oxygene from RemObjecs (a Visual Studio plugin with a syntax that is very similar to the Delphi syntax). CodeGear will offer Prism soon (likely before the end of 2008), which will also integrate into Visual Studio.

Because .NET data access and UI are totally different from Delphi, you will have to do these from scratch (both for scenario 1 and 2). Visual Studio 2008 offers a lot of benefits here over Visual Studio 2005.

There is no such thing as doing this migration gradually, since you do a complete platform change here, it is an all or nothing approach.

Both scenario's will take a considerable amount of time (even though you have Delphi experience, getting yourself accustomed in the .NET world will take time).

Visual Studio can interact with Crystal Reports, and goes well with SQL Server.

Since Visual Studio 2008 offers a lot of benefits (not only .NET 3.5, but also productivity wise), you'd better go with that. On the UI side, you need to make a balanced choice between WinForms (aka Windows Forms) and Windows Presentation Foundation (aka WPF).

If it is a 1-to-1 rewrite, you might want to stick with WinForms as it is familiar to what you have. You probably need to use some 3rd party components to get your UI going; DevExpress is a good choice here as they have similar components in Delphi and Visual Studio.

But if you want to go for future eye candy, then you might consider WPF. Be prepared for a steeper learning curve here than WinForms as it is very different from what you are used to.

If you decide to stay with Delphi, you might want to look into VCL for the Web (aka IntraWeb) and into Delphi 2009 (a lot has changed in the Delphi world since Delphi 7 was announced 6 years ago).

Good luck making your choices!

--jeroen

Answer 8

I would suggest looking at Hydra from RemObjects. It basically raps the com interface for you and provides an observer pattern for interfacing between your Delphi and .Net application. You can have .Net forms appear on panels inside your Delphi app. This provides a nice migration path where you replace your Delphi code bit by bit as you migrate functionality to .Net.