Migrating projects from Delphi to .Net

[Mike Torrettinni 198]

Looking for some input on successful and non-successful migration from Delphi to .Net, why yes and why no, what to look for and what to avoid.

 

I'm seriously considering porting my projects from Delphi to .Net. I'm not an expert in .Net so this would be also learn as I go. 

I have fairly simple projects, no db access, no relying on complex UI controls or using any framework that would prevent me to migrate because nothing like that exists in Visual studio.

 

I use a lot of VirtualTreeView control which is just probably find comparable .Net control that fits and use that. I don't see a problem with that. 

 

I found this presentation https://www.slideshare.net/SergeyPilko/migration-of-legacy-delphi-projects-to-net-framework-desktop-web-mobile and 2 interesting slides:

 

 

 

 

 

 

And I guess the UI in failed case was too complex and wasn't adapted to .Net controls.

 

 

Not interested in automatic converters, I will do all the coding myself. I have no time limit on this.

 

Any input on this topic is more than welcome!

 

 

[Lars Fosdal 1793]

My advise would be to write a few test apps in .NET before you start your migration. Learn how to do databases, files, classes, interfaces, OS and UI.

Understand the new paradigms before you try to csharpify Delphi code, so that you know how things work in C# and what you need to change from Delphi.

 

Sadly, UI is still much more work in .NET compared to all the "freebies" in Delphi - and there are several flavours. WinForms, WPF, MAUI, ASP.NET, Blazor.  

You need to find the one that suits the needs for your app. You will most likely find yourself wanting to acquire some third party UI controls.

 

For any complex Delphi app, you are not looking at a migration, but a rewrite.

[Keesver 23]

Checkout RemObjects Elements, you should be able to re-compile much of your Delphi code to .Net (Elements. Build native projects for any modern development platform, using the language(s) of your choice. Oxygene (Object Pascal), C#, Swift, Java, Go. | RemObjects Software).

[Mike Torrettinni 198]

3 hours ago, Lars Fosdal said:

but a rewrite.

Yes, I guess this is more accurate. 

 

3 hours ago, Lars Fosdal said:

Sadly, UI is still much more work in .NET compared to all the "freebies" in Delphi - and there are several flavours. WinForms, WPF, MAUI, ASP.NET, Blazor.  

 

Shame, but the more I think about this, the more I realize none of the cool, smooth, flicker free UI elements were never really commented from my users - the sale would happen even without carefully designed and customized views.

Starting again, I don't see any reason to focus on more than 'as long as it doesn't look like it's from 1999, is almost good enough, with a few exceptions'.

 

 

[Clément 148]

How productive is you customer using you application?
That's the question you should ask yourself. You can take whatever IDE you like... and what? Clone you exact application UI, behavior and functionality. All the fancy .NET stuff would still be under the hood.
So.. what does he need.... exactly!

Ah! He wants something new, which means something different. What exactly? less clicks? More "live" information on screen? Dashboards? Notifications?
Users wants productivity. Developers wants fast time to market, One excludes the other

 

[Mike Torrettinni 198]

6 hours ago, Keesver said:

Checkout RemObjects Elements

Thanks, but the main idea is to migrate and learn on the go, so quick conversion is not what I'm looking for.

 

28 minutes ago, Clément said:

How productive is you customer using you application?

Actually, at the end, they should not notice the difference between a solution written in Delphi or C#, except of course for the gazillion dlls being installed instead of 1 exe 🙂 .

 

[Mike Torrettinni 198]

The way remote work is changing the whole software employment opportunities, I'm realizing being an expert is becoming a niche and not a must. And since I'm not a Delphi expert, after 20+ years, I can freely let go an illusion that I can become one at some point, or that this is a prerequisite for a job.

 

So, it seems one way to get to a good remote work salary opportunities, is to develop something and sell it. And as my projects are Windows apps, C# seemed like a natural step in the right direction. 

[Lars Fosdal 1793]

17 hours ago, Mike Torrettinni said:

except of course for the gazillion dlls being installed instead of 1 exe 🙂 .

It has become possible to create completely self-contained .NET apps as well.

[Mike Torrettinni 198]

29 minutes ago, Lars Fosdal said:

It has become possible to create completely self-contained .NET apps as well.

Interesting. I see they even went a little further and you can deploy your app without the need for making sure the OS has the right framework installed:

 

Quote

Publishing an app as self-contained includes the .NET runtime with the app, and users of the app don't have to worry about installing .NET before running the app. Publishing an app as framework-dependent doesn't include the .NET runtime; only the app and third-party dependencies are included.

 

[Brandon Staggs 283]

On 3/20/2023 at 3:15 AM, Keesver said:

Checkout RemObjects Elements

I found this to be far more trouble than it was worth. Obviously it depends on the project, but I would rather make a clean break than try to fake it with something that can compile "alot" of my Pascal code. Learning the syntax is a breeze, so that is not an issue. You're going to have to change frameworks and learn the "way" of development with .Net. May as well just do it.

[Walter Verhoeven 4]

I understand that you have concerns regarding the reliability of .NET for projects with long investment horizons. From my experience, it is important to note that support for any given version of .NET typically ends within approximately three years. For instance, long-term support for .NET 8 is scheduled until November 10, 2026. This may not be ideal for projects that require stability over time, considering operating system compatibility and security updates.

https://dotnet.microsoft.com/en-us/download/dotnet

If you plan to move to production quickly, you will have approximately one year before needing to migrate to the next version. Additionally, it is worth noting that native compilation, such as converting .NET IL to native code using tools like the native AoT c++ copiler, can pose some problems you will not be able to fix like loose all meaningfull stack on a exception. This approach can be problematic given how many NuGet packages and elements of the .NET technology stack rely heavily on reflection. Currently, no UI framework supports Ahead-of-Time (AoT) compilation, and most complex code does not function cross-platform.

Moreover, utilizing third-party code can be beneficial, but it often requires significant effort to maintain, and performing risk analysis on such code can be challenging. Additionally, ensuring service level agreements (SLA) when the implementation correctness of the code is uncertain can be difficult. Based on my personal experience managing 22 NuGet packages with over 17 million downloads, maintaining them feels like a full-time job. As a result, we are currently transitioning from .NET to Delphi and creating wrapper classes to interface with the original C# code while ensuring that nothing breaks for my users during the process.

If you need more convincing have a  look at the security updates, I know as I reported several of them that are still not resolved. You can check out the .NET 8.0 Downloads page.

https://dotnet.microsoft.com/en-us/download/dotnet/8.0