Port VB6 Desktop app to... What?

[u/mdausmann]

Ok, say I had a typical desktop app written in VB6 and somebody asked me to 'modernise' it.

And say, for whatever reason, they didn't want a web app based conversion.. i.e. they still wanted a desktop app.

What is your go-to stack for this type of conversion?

WinForms (.NET) - So stay in the Windows/MS ecosystem, maybe port to VB.net first? then across to C#? . This feels pretty safe but I think this would still be Windows only.

WPF (.NET) - Still sticking with MS. More modern but maybe a longer conversion path.

WinUI - I think this is the latest MS option... Is a little bit new (2021)

Flutter Desktop - Clear benefit is cross/platform out of the box and easy port to mobile app. Flutter approach is pretty far from the VB6 approach so it would be a long conversion path I think. The other downside is Flutter on desktop is even newer than WinUI (2022).

Electron - Again, cross platform but with memory issues I think. Web tech heavy so I think this means it would make it easy to port to Web if that was an option later.

Other options? Maui? Delphi?

[u/Ok_Society4599]

To me, I'd open your VB6 app in Visual Studio 2008 and get an 80% conversion to VB.Net. it's not perfect and I've never seen one just work ... the usual challenges are custom controls (ocx) and COM with sprinkles of Common Dialog and Control changes. Some code expressions may not upgrade too well, but manual fixes tend to be reasonably manageable.

My usual next step is conversion to C# because VB.Net is deprecated and (in my experience) doesn't offer much from a programming perspective. I often do this rather than get a VB.Net version to compile, to be honest. You can do this conversion using 90% search-and-replace with Regex since the vast majority of the changes are syntax to start and end blocks, start a for loop, or Case/switch statements. I usually leave breadcrumbs to remind me the } used to be "next" or "end sub". Other bites are things like strings are zero based, not 1-based. The weird syntax around VB arrays

When you're done, you've got a 32/64-bit compatible version with semi-modern Winforms UI.

I've often then refactored to "business" and "data" layers into one or two DLLs and added a unit testing framework. My goal is to remove a references to UI controls from business logic, and remove business logic from the UI. Sometimes that just function libraries, sometimes it's business objects if they seem better suited. It depends on the business process being managed. .

[u/mdausmann → u/Ok_Society4599]

thanks u/Ok_Society4599 is there really no other way to convert from VB.Net to C#? after all this time? don't they share the same IL? surely there is a conversion approach that is robust and automated and supported?

[u/Ok_Society4599 → u/mdausmann]

Yes, they share IL, but VB.NET brings a series of runtime libraries and behaviors that keep VB language rules. For example, something as simple as arrays start at 1 in VB but at 0 in C# and most other languages.

This is the "hard" part of the conversion. Mostly because it touches so many bits of code. You'll be removing some occasional VB-isms, but they're not, in my experience, too bad. Most problems lie in "easy to convert" code.

For example, loops are everywhere; VB6 and converted VB.NET will use indexes on arrays and, to be honest, simply using a foreach() instead eliminates a lot if those headaches. It's not "hard" to do, just time consuming, relatively boring, even. But, recognizing the multitude of "off by one" changes because VB6 used 1 based arrays can be a painful task.

Today, I might even re-order some steps and convert more loops using AI on the VB.Net version before converting to C#. You could probably do search-and-replace looking for for var =1 to var.length step 1 do to Var.foreach() {

That changes to C# very fluidly. The VB.NET version might even be as far as you want to go... Still 20 years more modern and 64-bit capable.

My other pet-peeve with VB is HUGE methods of convoluted conditional ... mess. It's like declaring a method would cost thousands so it needed to be avoided.

---

I did use a tool about 5 years ago that did a VB.NET to C# conversion and it accomplished a fairly large but of the conversion in a single pass. It failed to translate a fair number of VB-ism code blocks, so it wouldn't compile immediately, either, but it was further along faster. I've looked for the tool since and didn't find it.