Mixing Vb.net with C#

Question

Hi

We have an existing project - asp.net website using Vb.net - that was developed +- 2 years ago. The client would now like to add a substantial list of features to the system.

My Question :

What are the pros and cons of writing all the new features in C#? All our new pages and new assemblies will then be done in C#.

Some of the developers working on the project has never worked in Vb.net and are not familiar with the syntax. C# is also our language of choice, and we are familiar with the syntax.

Is mixing languages a good idea? Will this make maintenance difficult?

Thanks

Answer 1

I currently work in a mixed environment and usually its fine. The biggest annoyance is that I often come across small speed bumps when changing from 1 language to another.

e.g

• semicolon at the end of vb lines
• mixing square and curved brackets up
• declaring variables with Dim in c#

Answer 2

I think I read on the ms site once that it (MS) considers that most C# devs can read enough vb.net to get on with it, so I think maintenance should be not that much of an issue. Use what works for you going forward.

As you need to you can rewrite bits that need work

Answer 3

I think you biggest long-term problem will be maintenance; you'll need to hire employees which know both languages and a "mono-languaged" programmer can slow development progress.

Can you ask your stakeholder to consider that changes as an opportunity to refactor/rewrite some pieces as technological upgrade? You said that application was written some time ago, so probably it can benefit from a newer framework version.

I understand rewrite a running application isn't a very popular subject, nor should be suggest everytime, but seems to fit in this specific scenario.

Answer 4

My main language is C# but I had to switch to VB.NET for a project. I just used a simple cheat sheet (like this) to help me. Otherwise the syntax is not hard to understand and the available things are similar.

Answer 5

Maintenance, maintenance, maintenance.

The actual language barrier should not be a problem, however after 2 years of not looking at VB and boom, a problem arises in the old code, the code will take a lot longer to maintain correctly, as people won't be looking at the code "natively". If there's a language problem though, have a look here:

http://www.developerfusion.com/tools/convert/vb-to-csharp/

Makes life a lot simpler to understand between the two languages, specifically for the "oddball" scenarios.

Answer 6

I have had to switch environments twice for special projects. One was from C# to VB.NET, the other was from C# to Java. The second one was way more difficult for me; at the end it's all in the framework.

Answer 7

The difference between VB and C# is just syntax - I switched from VB to C# and it only took about four days before I could write C# without making syntax mistakes. After about three weeks I was at full speed again. The platform and the tools are (obviously) all the same.

Your C# programmers will probably complain initially if they are asked to work on VB, but if it's a large project they will familiarize themselves in less time than it would take to rewrite the application.

I think that the key issue that determines how you approach this is that you should minimize context switching for each developer. As John Nolan says, moving between languages requires mental context switching, which always hurts your productivity - this speed bump never quite goes away.

If a developer is working on VB, arrange things so that they are working on VB all of that day, rather than asking them to switch between languages. Depending on the project and your setup, this may mean keeping the whole application in VB, or dividing up the work so that some of your developers use VB whilst other write C#.

Answer 8

Other than the issues already mentioned here (primarily maintainability), there are minor differences in the offered functionality of each language. As a best practise, you should take care to conform to the Common Language Specification in all your code, so there are no cross-language compatibility issues. Note that these rules only apply to externally visible and accessible members.

There are some speed bumps. For example, if your VB.NET code uses named parameters heavily, using C# (until .NET 4.0) might be a bit clunky.

Answer 9

We have a few projects that mix VB.net and C#.

The biggest problem we had is when C# uses case to distinguish public methods. VB.Net just can't handle it. (But even that is only an issue if you have VB.net consuming C# components.)

If you know the framework going back and forth between VB.net and C# is only a very minor issue for even mid-level developers. And I think it adds to everyones understanding.