Should we select VB.NET or C# when upgrading our legacy apps?

Question

At the company where I work, we have a number of legacy apps written in Visual Basic 6.0. Without casting aspersions on the developers who wrote them, suffice it to say we have decided to rewrite the applications from scratch due to several compelling factors:

1.) Lack of documentation.

2.) Lack of exception handling.

3.) Lack of logging.

4.) Lack of extensibility.

Because these applications have a lot of duplicated code shared among them (copy-paste reuse), we want to rewrite it in a way that emphasizes reusability, testability, and extensability. I am therefore considering a move away from VB 6.0 and into .NET. That leaves me with a choice between VB.NET and C#. The development team is open to suggestion. However, they have no familiarity with C#, and are more familiar with Visual Basic (classic). In either case, they'd have to learn .NET.

Teaching is not my issue. I've done it before, and I have no qualms about doing it again.

It bears noting that the source code is going to have to be rewritten, because a redesign is called for. So, at this point, we get to choose which language we want to use. I am personally leaning towards C#, feeling that it enforces more disciplined coding practices (it's a more intrinsically type-safe language and comes with a far stricter compiler).

I am, however, very interested in the thoughts of my peers before I make a decision. So, if you have done this before, or if you have any words of wit or wisdom to impart, I'd really appreciate it.

I suppose, in closing, that the question is, which language would you go with if you had the opportunity to make a clean break from VB6.0 and move to .NET?

UPDATE: I apologize if anyone thinks that I started this thread for the sole purpose of being argumentative. That was the furthest thing from my mind. Instead, I wanted to make sure that I was making the right decision at a crucial point in our company's decision making procesesses. To do so, I thought it best to seek input from those who had been through the process themselves. Stirring up strife was the last thing I wanted to do.

Thank you all for your input. It was thought provoking and I'll be going over it with my colleagues as we select a language for our future development.

Answer 1

In my experience, most ex VB developers don't mind moving to C#.

C, C++, perl etc developers would rather gouge out their eyes than code in VB.NET.

If you don't mind doing it, I'd say go to C#. There seems to be far more support for it in the community and because of what I said above, that isn't going reverse any time soon.

Answer 2

At my last company, we concluded that it would be harder for the VB6-ers to learn VB.NET than C#. Why? VB.NET is almost exactly unlike vb6, save syntax. That syntax can become more of a challenge than making it easier to learn.

Answer 3

I think the biggest reason to use C# over VB.Net is that almost all code samples, discussions, etc. on the web are in C# when you discuss the .Net framework.

If you're on an MS site, they always show both, but on sites like these and things you'll find searching Google, you'll find almost all examples are in C#.

You can get good at translating them in your head, but that gets tiring after a while.

As a minor aside, C# will also probably look better on your, and your teammates', resumes.

Either way, good luck ramping them up, just learning true OO will be tough enough. :)

Answer 4

If a rewrite is necessary, and you are going to have to teach a new language, why are C# and VB.Net the only choices?

That being said, I would most certainly go with VB.Net. If your developers are much more comfortable with VB, it will make the process that much easier. Also, you may want to hire a few people who are very well versed in .Net. It's going to be a nightmare to get people who are just learning .Net to try and rewrite an entire application and apply all the best principles pertinent to .Net.

Answer 5

I'd say move them to C#, that way it looks different enough that hopefully they won't fall back on any bad habits picked up from VB6.0

Plus, trying to describe the difference between "AND" and "AND ALSO" (or whatever it is) is probably more trouble that it is worth.

Answer 6

When moving to .NET, the “similarity” between VB6 and VB.NET is no real advantage, in my experience. This is because VB.NET is actually much more similar to C# than it is to VB6, despite their syntactic differences.

So from this point of view it's quite unimportant which to choose. However, this:

… feeling that [C#] enforces more disciplined coding practices (it's a more intrinsically type-safe language and comes with a far stricter compiler).

I cannot agree with. In fact, VB is just as strict as C#, even more so with a little discipline (alluding to casting between types). All that is required for this is to make Option Explicit On and Option Strict On a requirement for all projects. Which it should be in any self-respecting company.

Option Strict may be switched off selectively when dealing with lots of late binding APIs (see PIA). Option Explicit, never.

When this simple constraint is regarded, VB.NET is an extremely strict, extremely explicit and thus extremely expressive language.

Answer 7

I would personally recommend C#. That would also add a new skill to their skillset. We had the same situation were we work. A lot of apps are in VB6 - though I must say they are well designed and well documented for the most part. But for the upcoming versions, we are moving onto using C#.

Answer 8

It's a judgement call.

If you feel your team is up to it, and accepting that there will be more of a productivity hit, IMHO you should move to C# if possible. From the sounds of it though, if these are the same devs who had a hand in the 6.0 code, you might do better to move them to the more comfortable VB.Net and try and progress to C# from there.

Of course, they both compile down to the same IL, so there's an argument to say "either/both", but that of course could be it's own special headache.

Answer 9

To be honest, the technology doesn't matter. What matters is in the end having legible, maintainable code.

Answer 10

This sounds like an excellent time to make the move from VB6 to .NET. Ultimately the choice of language largely comes down to a decision on syntax and style more than anything else. Yes, there are features available in either language that aren't available in the other but for the most part those differences are negligible.

That being said, I would recommend moving to C# for the following reasons:

• The learning curve for C# isn't difficult (my opinion, but based on being part of a VB6 team that migrated to C#).
• C# forces the developers to "unlearn" any bad habits that VB6 allowed. The corollary to that is that VB.NET will still allow those bad habits.

The harder part for your developers will most likely be the concept shifts from VB6 to .NET in general and learning what features are available to them from the runtime.

If there is any trepidation on the part of your developers, choose a single volunteer (preferably a senior developer) and a small proof of concept project to be written in C#. This allows the team to see an experienced VB6 dev using C# and seeing how quickly that person is able to come up to speed. In my expereince, when we did this, our candidate VB6 dev was as proficient in C# as he was in C# in under 2 months (and this was a dev who had only done VB6 development his entire career).

Answer 11

Having made this change myself, I'd suggest C#. I've found that VB.NET encourages the same mistakes as VB 6.0 did (declaring variables with no type, which leaves them implicitly as object, using modules with globals, etc). Also it seems that there are more C# developers for hire. In addition there are many useful tools that work with C# but not with VB.Net. Doxygen in particular is great for creating class documentation for your C# (it even imports your standard XML comments), but does not work with VB.NET.

Good luck!

Answer 12

This is like the eternal debate isn't it? This discussion has been going on for years, do a google search and you will see what I mean.

I would have to say that the best option is going to be C# for your organization. My reasoning is for the following reasons.

1) Most example material is in C#, including books 2) There are a lot more C# developers than VB.NET developers 3) You write about 25% less code with C# 4) Language upgrades usually hit C# first, VB.NET is like the redheaded step child :D

With all this said they both use the same IL, and they both use the .Net framework so in theory they are the same. It's just that C# as you mentioned will teach better discipline to your VB6 developers. For the record I was a VB6 developer who went to C#, and then later was forced to use VB.NET for awhile and hated it. Take it for what you will.

Answer 13

I have also seen a couple of examples on the web where the IL created by VB.NET was not the same as the IL created by C#. The IL from C# was shorter and more concise. I guess since different people wrote the compilers (I assume anyway), they don't alwasy compile to the same IL. If C# compiles to more efficient IL, then that's certainly an advantage for C#.

Answer 14

I suspect you'll find most people will recommend C#. Realistically there's not a lot of difference between the two from a language perspective. With .NET it's really all about the framework, which is immense.

Personally, I prefer VB because it is easier to read. I spend much more time reading code than I do writing it, so I prefer VB's english-like syntax. But I also find it easier to type. Even though I'm a good typist, all the special characters of C# are not as easy to touch type for me.

In the end, I would recommend you don't choose either. Let your developers work with what they feel more comfortable with.

Lastly, are you sure .NET is the right choice? I work with a lot of companies that move from VB6 to REALbasic because it is a more straightforward transition that addresses the limitations of VB6 without adding the complexity of .NET.

Answer 15

I would recommend C# because C#:
Is an ISO standard (ISO/IEC 23270)
Is an ECMA standard (ECMA-334)

Answer 16

If you intend to take advantage of OO programming, I find it much easier to do so in C#. IMHO, VB.NET's implementation of inheritance, delegate definitions, event definitions and wiring, etc., are much more cumbersome.

Answer 17

Select a language you feel most comfortable with. VB might have the easiest migration path due to a lot of code in VB already. Don't pick a language because it makes you feel smarter, pick one that allows you upgrade with minimal retraining.

Although, it really depends on what your doing. At my company, we upgraded a lot of our apps to C# because most of us have C++ background. We kept a handful in VB because they deal with Office interop (After writing "Type.Missing" and "Missing.Value" about twenty times).

Answer 18

I'm not biased to either language but you do have to factor in that if the majority of developers are into c# then that makes recruiting these developers easier, you may also find more examples and resources in this language as well.

At the end of the day you are learning about the .net framework as much as you are learning about the language, for me this is where the majority of the learning is.

Answer 19

I asked a question similar to this once It really comes down to personal choice I went from a C++ shop to a C# shop and now program in VB.NET I am of the opinion that C# and VB.NET are not too different and that if you are learning from scratch like I did C# is the language to learn. There is a lot more out there with examples in C# and most .NET books use C# as well.

I say flip a coin!!

Answer 20

The VB.NET IDE, even in VS2008, is still considerably better than the C# one. From a productivity point of view, this is an important factor.

Intellisense, auto-complete, and the ability to have it tell you in real-time what all your compile errors are, so that you can have a compilable application before even trying to build, is a HUGE benefit. Auto-capitalisation, too, that gives you instant feedback on having spelled something right, is another big plus.

I program mostly in VB.NET, having started with C# and moved over, for the simple reason that the IDE works so much better. It was like going back in time several years when I worked on a contract programming in C# a few months ago.

Nothing wrong with the C# language itself, although I happen to find the more verbose style of VB.NET more readable (End If, End Select, Next, etc, are all visibly different, rather than all being '}').

Further, with auto-complete, there isn't significantly more actual typing, so those that seem to believe that you can develop faster in C# because of its terser syntax are, I believe, in error.

Answer 21

Aside from the other comments, you really need to decide based on your applications' interaction with various formats, namely Office and XML.

Pro for VB.NET:

1. Optional parameters -- besides being generally useful, they also make working with Office via the Interop much easier. In C# you'll have to add a Type.Missing to every optional parameter you don't want to include. (Note: These will be available in C# 4.0, and you can also use the Open XML SDK with C# to get around this, so I'm not sure it's such a great pro, just worth noting.)
2. XML Literals -- If you don't mind sprinkling some XML into your code, this is much better than using StringBuilders or string concatenation. (Again, you could use LINQ to XML in C# for a very fluent approach, if not exactly representative.)

Pro for C#:

1. yield -- makes writing iterators in C# far, far easier than VB.NET.
2. Generally more concise syntax should reduce keystrokes, but I'm not sure by how much.

I personally find C# much more concise. I generally build more language-friendly extension methods with which I write the rest of my code, so the language-friendly syntax of VB wouldn't generally get me far. With the addition of yield and the Open XML SDK, most of the reasons I've had for using VB.NET in the past have gone away.

Answer 22

Here's a different reason to pick C#:

Many of the good OO books these days are written using Java in code examples. If you only know VB .NET, they're hard to read. If you know C#, they're easy to read. So even if you plan to mostly do VB .NET development, it's worth knowing C# so that you can follow along when you read programming books.

Answer 23

If you have many math functions I would put those routines in a VB.NET assembly. Convert all Integer to declarations of Int16. and all Longs to declarations of Int32.

Otherwise convert to whatever language you feel most comfortable with. The difference between the two are minimal and are dwarfed by the challenge of learning the .NET framework.

I chose to continue with Visual BASIC as my application (CAD/CAM software running metal cutting machines) is math heavy. I found in past conversions that it much easier to preserve the behavior of math functions if you convert to a language with syntax in the same family. VB.NET broke a lot less compatibility when it comes to transferring over pure code.

However in a practical sense C# is so close to VB.NET even when it come to pure code you are not going to suffer for it. The big challenge is learning the framework.

My personal preference is VB.NET which feels like Object Oriented BASIC done right. Programmers with a solid background and experience should not be hung on the differences no more than getting hung up on the differences between C, C++, C#, and Java.

I feel the terseness of the C-style to be a detriment to long term maintenance (think decades) That BASIC's verbose style makes it much easier to read older code. Provided of course the particular dialect supported long variable names. Finally I don't have to waste time remembering to type the damn semi-colon.

Note this is a personal opinion born of having to maintaining large applications in BASIC and in C++ (CAD/CAM for BASIC, Spacecraft Simulator for C++) In reality for the .NET languages these difference are TRIVIAL.

Answer 24

My language progression was VBScript, VB6, C#, and most recently VB.NET. My pick is still C# based on conciseness and availability of examples. When I use VB.NET, it feels like a square peg has been shoved into a round hole. Several syntax additions to support generics, inheritance and so on feel contrived.

Answer 25

If you are going to be implementing a software development life cycle that is process-oriented and based on an internally designed and developed architecture (with lots of shared class libraries, etc.), then I would go with C#.

The C# language was designed and styled for that kind of development, whereas VB continues to operate as a RAD and prototyping type of language. You will be doing your existing developers a favor, since C# is generally considered to be a more "Pro"-skills type of language in .NET over VB, mostly because of the cutting corners-mindset that many people associate with VB. If they do leave your project, they will have a shot at leveraging their old VB6 skills with C# at organizations that are trying to move away from the RAD development mindset.

On the other hand, choosing C# will also protect your investment to some degree, I'm betting, because the C# job market is more competitive, I believe. So, when your developers are trying to jump ship they'll need to be proficient in .NET, not simply VB, whereas, I think that VB .NET jobs are generally not attracting hardcore developers. If your developers do leave, then you'll be able to get better ones, most likely.

I for one, would avoid a VB .NET shop when I am looking for a job, for many reasons, other than the fact that I simply do not like the wordiness case-insensitivity. I'm a sensitive guy.

Oh, and one more thing: your team will be using the lingua franca of StackOverflow .NET developers, generally speaking.

Answer 26

I'd say go to C# because you will find it easier to recruit better programmers in the future. You get a different set of skills with C# rather than VB developers.

Answer 27

Some good answers, particularly by Joel Coehoorn. But do make sure rewriting is definitely the right move. It may be the right move, but be sure.

It's a common pitfall to start out optimistically rewriting a large piece software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.

...and here's a blog post by a Microsofty that agrees with me:

Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large

And Joel said a while back:

The single worst strategic mistake that any software company can make [is to] decide to rewrite the code from scratch.

Do examine the reasons for rewriting carefully. Here are some comments on the reasons you've given - I guess you may have others but these are the ones you've listed.

1. Lack of documentation. Well, your new software will need documenting, so you may not save much time there.
2. Lack of exception handling. Exception handling can be added automatically to VB6 very quickly using excellent free software.
3. Lack of logging. Is it really that hard to add logging?
4. Lack of extensibility. This rings true. But unless you're planning really massive changes in functionality, is rewriting really going to be quicker and cheaper than some preparatory refactoring to the old code base? You might find the book Working Effectively with Legacy Code helpful. And remember you can use Interop to mix new .NET code with your old VB6 application - you can use VB.NET or C# as you prefer.

Even when support for the VB6 runtime finally ends I would argue that for a large program, semi-automatic upgrade is likely to be much cheaper than a rewrite. In fact, I have argued it on Stackoverflow.

So, strictly speaking I know I haven't answered the question. Please treat this as a kind of sanity check on the user requirements in the original question :) Even if rewriting is correct for Mike Hofer, it may not be for others who read this thread.

Answer 28

I have been programming in C# since 2002, and spent six weeks using VB.NET in a production environment. Here is my experience:

By knowing C#, I had absolutely zero issues with learning the VB.NET syntax and differences, I was able to immediately jump into the projects and get things done.

Now from a perspective of only knowing VB6, it will take a lot more effort to make a switch to C#. So with that respect, you may want to pick VB.NET so you don't lose time, money, and have frustrated and unhappy developers. Now, saying that, once they do make the C# jump if they do, and for some reason you decide you need to use VB.NET, it should be a breeze.

The differences between the two languages are not much, but with the release of the upcoming VS "Hawaii" the differences will be even less.

Overall, I recommend C# because the syntax is more strict, I find it easier to read and maintain. I started programming in C++, so it only makes sense I like an environment with a lot of symbols and brackets as opposed to an English syntax. (I despised English class!) Code is code, not an essay. ;)

Either way, making the jump to .NET is great. .NET is a great platform with a lot of awesome features. Once you make the jump, if you do, either VB.NET or C# won't be much of an issue since either language uses the same underlying technology.

Conclusion: I use VB.NET for web development (Asp.Net stuff), and I use C# for everything else. :) And as a friend of mine said if you use C#, "Learn to make your pinkie more dexterous"

Answer 29

We had a legacy VB6 code base and when we actually took a vote for what to write new code in everyone voted for C#. I would highly recommend C# both to break out of possible bad habits of thinking VB6 while writing VB.NET as well as many handcuffs that VB.NET puts on you that are very easy to avoid in C#.

Answer 30

VB is a more productive language and IDE to use than C#. The language designers did a great job of improving the usability. Because it is a better-designed language, VB will be easier for your developers to learn than C#.

VB really has little in common with VB6 and you should set the expectation that your developers are learning a whole new language. VB and C# have a lot in common -- the .Net Framework. Once they learn VB and .Net they can extend their skills into C# with ease.

Some people comment that C# is more popular, but I think that is a sampling bias. I heard the head of a large, nation-wide consulting company say that his customers request VB about half of the time.

Personally, I use C# most in the past two years because that is what my client wants. But I often miss VB.

Answer 31

Crappy code is crappy code. A new language can't correct for programmer deficiencies.

Of course C# looks more obscure to newbies, so bad VB6 programmers may like the way they feel it hides their poor efforts.

Answer 32

I'm in the middle a VB6 -> VB.NET rewrite. We started in C#, but then moved to VB.NET because we preferred the syntax. Since everyone working on this rewrite is determined to make a true OO program and avoid the pitfalls of some of that nasty, unreadable, undocumented, and copy/pasted code from our VB6 app, we're not worried about falling into the same issues again. Personally I like the verbose styles of 'End Class' or 'End Enum' instead of '}' at the end of each block, for my brain this makes code easier to follow.

I think if you are worried about old habits coming back into VB.NET code, a rewrite in C# would force everyone to write better code. Another option would be to include 'Option Strict On' at the top of each code file to ensure everything is strongly typed and nothing is assumed. From my understanding once they are compiled, there really isn't any significant performance advantage of one over the other. You'll still have some time to decide on this since Windows 7 will still support the VB6 runtime.

Answer 33

I need to provide an additional answer for this question. I missed something important in my original response and it's been bugging me for a while. I think I finally know how to express it, but I can't just append it to the original because I suspect a number of the 50ish people who voted for the original would not agree as strongly if it included this addendum. So... moving on.

As I said before, there is something to be said for programmers from a vb6 background choosing C# when updating to .Net. However, I don't think you want to push that too far. If you do, to be fair the same logic means that a C++ or Java programmer first coming to .Net should prefer VB.Net over C#, because it would provide a cleaner syntax break and help avoid bringing coding paradigms from one language and platform into another where they may not apply.

So again: don't give any extra weight to VB.Net because the syntax is familiar. But that also doesn't mean you should automatically give C# an advantage there, which is I think how many people interpreted the previous post.

Answer 34

I had the same question about 5 years ago for my team that was using VB6/VBSCRIPT in ASP.

We ultimately went with VB.NET for a number of reasons, most of which have already been discussed in other answers. However, to add value to this discussion I'd like to point you to a blog post I wrote recently as a retrospective on that decision and how sound my reasons turned out to be over the long haul. In some ways I was on the money, but I also have a few regrets too (mostly recruiting).

You chan check it out here: A Manager’s Retrospective on the C# versus VB.NET decision

Answer 35

i no well that nb.net is more important

Answer 36

Hello, Just a couple of points and my 2cents worth:

-bad code can be written in any language! -vb.net is closer to c#, I have loaded in functions into vb.net and have just had to remove the semi colon ";".

Ask your devs what they want to use. As for the lack of doc, exception, log and extensibility, what happened there? Perhaps they have learned there lesson? Perhaps it was the approach from the onset.

Get yourself a good book or class and lay down a plan. Put down into a document what needs to be done and how, and use some discipline, (found this online... "In its most general sense, discipline refers to systematic instruction given to a disciple.")

The second time around it gets better, lessons learned, it's just a matter of learning and enforcing them if you will.

Have fun!

-James

Answer 37

One of my favorite blogs on this topic...

http://geekswithblogs.net/bjones/archive/2007/03/04/107915.aspx

I am a vb.net coder (I can read most c# but I have not written 10 lines) but it is not religion for me. I want to learn c# someday.

Nevertheless, I DO think (an opinion mind you) that the vb.net is a more "productive" language than c#. This is not from my own personal experience but most of the programmers I know who routinely code in both languages say they are more productive in vb.net than c#.

And I have to say that this thread does NOT stress enough that getting over the syntactic differences is NOT a minor thing when learning your second language. As Bill implies in his article...a little bit of brain re-wiring does need to happen. Then number 3 and 4 and 5 will come all the more easy.

So, I would answer that on TWO fronts your shop will be more productive if you stick with VB. The jump WILL be easier...I have found a few of the anti-vb comments in this thread to be rather off of the mark. And vb is a very productive language in its own right.

The jump for me was learning the OOP stuff ... and you have to do that in either language.

2 ¢ from someone who only knows one side (which means I am likely wrong.)

Seth