Technology choice for redesigning an old VisualBasic-Application

Question

Completely unexpectedly, I (a webdeveloper, with a decent knowledge in OO), am tasked to re-design our old flagship Windows-application and drag it screaming and kicking into the next century.

Here's what we have now:

• 15 year old code, originally written in Delphi, about 8 years ago ported to Visual Basic (Kept in Visual Studio 2008).
• Some .net 2.0 uses.
• A lot of highly mathematical code in models, ready to be packed away in .dlls and sold seperately (Note: I don't dare to touch these, too specialised).

Here's what I intend to do:

• Using Visual Studio 2008, port the whole thing to Visual Basic and .net 3.5.
• Redesign the front-end completely with WPF.

Rejected ideas by the management:

• Porting to Java or any other, platform-independent language.

My questions: Is this a valid technology choice or should I start mixing in C# for the frontend?

Answer 1

I really think you should use the .NET language that you and/or your team are most comfortable/competent in.

"VB6 to VB.NET" vs "VB6 to C#" to me doesn't have much difference in learning curve.

Portability of your VB codes to VB.NET is well, as good as a code rewrite.

Answer 2

If you like to leave the platform-independence aside, this would be a valid choice in my opinion. Personally i would prefer C# because of the various language possibilities.

Answer 3

Using VB.NET is a double-edged weapon IMHO. It can help you porting the old VB6 code due to the similar syntax, but it can give you the false feeling that VB.NET is just "VB7" when in fact .NET is a whole different universe. That's why I always recommend to switch to C# instead of VB.NET for people willing to do the jump frm VB6 to .NET. But as o.k.w. says at the end it does not matter that much since the .NET Framework is the same regardless of the language you use.

Answer 4

The professional thing to do is to port to VB .NET 3.5.

The fun thing to do is to port to c# .NET 3.5 :)

I find it is faster to write code in VB, but the resulting code is prettier in c# - so again, it depeneds whether you're a profesisonal or an artist.

Also, porting to c# will allow you and your team more bragging points - and better employability.

Now that I've convinced you to rewrite it in c#, I guess you'll have to read the other posts for reasons to justify it to your employer :)

Answer 5

Is it still the same management that decided to move from Delphi to VB? If so, do not ask it for directions.

Answer 6

You already have lots of good advice here - I'd second @o.k.w - VB6 to any .net language has about the same learning curve.

I'd add two things though:

Are you keeping these mathematical functions in separate DLLs? If so how do you plan to access them. I'm asking because for COM interop VB.Net is much better than C#. VB.Net supports optional parameters and late-binding while C# doesn't - two things that make calling many COM functions from C# result in truly horrible code.

At least for the time being - C#4 (due next year) supports optional parameters and dynamic types - it should be as good for COM interop as VB.Net then.

Secondly I'd consider WPF vs Windows Forms very carefully - WPF is a whole new paradigm, more like developing web pages than traditional desktop apps. Even though you can do amazing things with WPF an awful lot of standard functionality is much harder to do in WPF than in old-school forms.

If you have lots of input boxes, menus, ok & cancel buttons, dialogs and the like then consider Forms instead. If you have a unique interface with lots of drawn graphics and few standard buttons or input boxes then consider WPF.

Since you have a team of Delphi/VB6 desktop developers moving to .Net (something I've done with a team myself) you may find it easier to start building your application in Windows Forms (something a Delphi expert can pick up very quickly) and then look at moving to WPF (or adding it) when you come to part of the interface that you can't do easily in Forms.

Also bear in mind that (at the moment) it's much easier to add WPF to a Forms application than the other way round.

Answer 7

Help the management define their goals. Then make technical choices that achieve the management's goals.

• Do they want a prettier user interface?
• Do they want to make the code more future-proof?
• Do they want the code to be more maintainable - if so, what are the skills of the proposed maintainers? What other code do they have to maintain?
• Do they want new functionality?

Answer 8

A lot of highly mathematical code in models, ready to be packed away in .dlls and sold seperately (Note: I don't dare to touch these, too specialised).

Having pulled my company's CAD/CAM through several platforms (HP Workstation, DOS, Win16, Win32) I strongly recommend that your mathematical assemblies remain in VB.NET. If you have a strong suite of unit tests then you can get away with switching to another language. Although C# is nearly identical to VB.NET/VB6 in math there is always a hassle when convert pure mathematics. Unlike a faulty UI problems this area don't show up right away unless you have a good suite of unit tests

Answer 9

I was in a very similar situation when we moved a large legacy application from VB6/ASP Classic to the .NET platform. I agonized over it quite a bit.

Ultimately we went with Vb.NET instead of C#. I wrote a retrospective about how that turned out including the good and bad from the viewpoint of 6 years after the decision. It might be of some of use to you: "A Manager's Retrospective on the C# versus VB.NET Decision"