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 wants to move away from the Borland/Codegear tools.

The application is a single client server executable, utilizing 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 than 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?

Solution 1

I worked at a company that was migrating from Delphi to WPF/.Net circa 2007. 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.

Solution 2

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 :)

Solution 3

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.

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Ash]

Business see lack of web development in Delphi as a major risk. They want a platform that allows them flexibility in choosing different UI layers (Web, Desktop, Service etc).

[Ash]

Thanks for your experiences. The business have now decided to put the decision on hold until new year. It is now likely they will move to .NET3.5. Original decision of .NET 2.0 was the 90+ MB framework installation requirement.

[Ash]

Thanks, they are keen to move away from Delphi/Borland entirely. Looks like piecemeal is going to be the approach used.

[Ash]

Good points and thanks for the links. Complete re-write is certainly the last option. With so much logic in the database though much of it will not need to change, at least initially.

[Ash]

The business want to move away from Borland/Codegear entirely. They also want more flexible UI options, Web, Desktop, mobile, services (in that order).

[Arnaud Bouchez]

+1 For the info. Web site is refactory.com Huge work - and it will depend on how the Delphi was written: e.g. if RAD was used and UI, DB and logic are mixed, it will be pretty painful/impossible to be automated, since you would need to transform the whole VCL class hierarchy. And what is the benefit of a 1-to-1 translation? Changing the algorithms and patterns (e.g. introducing Domain-Driven Design) may be worth it. Not "translating" existing code from one environement to another.

[Arnaud Bouchez]

@Ash ... so stay with Delphi, and migrate it using modern patterns. You have plenty of good frameworks and components around, in pure Delphi, to migrate to n-Tier, ORM, SOA or DDD.

[Stephan Eggermont]

The parts of the VCL hierarchy that were used weer translated, yes. They spend a lot of time mapping from vcl to .net frameworks