Home/ Questions/Q 1063409
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T18:46:49+00:00

First, let me ask you to consider this as a real question, and not

  • 0

First, let me ask you to consider this as a real question, and not a subjective one.

That out of the way, here’s my situation: We are looking to port our existing classic ASP application to .NET, but we’re unsure of what language to use for the new app.

I personally would ‘prefer’ C#, as I’m more familiar and comfortable with that languages way of doing things, but, the original code is VBScript, so it would possibly be easier to port to VB.NET … One possible situation I fear would be that, because the code is so similar between the two variants of VB, that we might end up getting stuck on something that is not similar between the two, even though it looks like it would work. A shift to a wholly different language might avoid that kind of situation.

Does anyone have any practical examples of this kind of situation? Insights to illuminate the issue with? Do the potential benefits of a complete paradigm shift outweigh the gains from a high degree of ‘copy-and-paste-ability’ ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    3 years ago I had to make this same decision. My preference would have been C# but we ultimately went with VB.Net because that was the closest language available to the developer base we had. All of the developers had experience with VBScript, so learning VB.Net was easier for them. While the framework is the framework and the rest is just syntax and best practices, you’d be surprised the difference in learning curve just by adding a few curly braces for VB developers (the reverse seems to be exactly the same for C# developers going the other way with an itchy semi-colon finger, learning new keywords and relearning event syntax).

    You should look at your developer pool and consider what is the easiest for your team to perform development and maintenance. If this is not a serious criteria (because the developers are proficient equally in both), then I would recommend a C# approach. The primary reason is that the VBScript will be relying on outdated methodologies, but converting to VB.Net will not necessarily throw exceptions for these methods whereas C# will. It will also force you to touch every aspect of your application, which (while tedious) will provide your team an opportunity to evaluate how older methods may be refactored into more efficient processes.

    Just keep in mind – the “easiest” seeming solution seldom is.

    • 0