5

I was reading this question when I noticed a curious comment underneath:

not sure what the question is: you can use VB.NET and C# projects in one solution (though I wouldn't recommend doing so).

I do this quite a bit, as we have legacy VB.Net code, and new code is written in C#. Is this really not recommended? Why not?

Community
  • 1
  • 1
JMK
  • 27,273
  • 52
  • 163
  • 280
  • 3
    Ask Mitch Wheat why he does not recommend it. – Anthony Pegram Mar 29 '13 at 15:48
  • VB.NET is not recommended in general. let p = vb.net is recommended let q = c# is recommended p := F q := T p && q := F – Moho Mar 29 '13 at 15:57
  • 6
    @Moho I'm a C# guy - but there really is no reason to not recommend VB.Net in general. It's a great language, and does some things better than C#... – Reed Copsey Mar 29 '13 at 16:13
  • @ReedCopsey, agreed. The syntax is pretty :| if you've done anything else in any other languages, and in general I find that C# provides me more without missing out on much, but there's no reason to just throw the language out as a whole. – antinescience Mar 29 '13 at 16:23
  • @ReedCopsey Totally agree, as long as Option Explicit is specified I'm happy enough! – JMK Mar 29 '13 at 16:24
  • I suppose for the same reason that you rarely mix two human languages in one book. But sometimes there are good reasons to do so - you just limit the audience capable of understanding all of it a bit. – JDB Mar 29 '13 at 16:25
  • 1
    @JMK Yes, that's one where I absolutely agree. VB.Net without Option Explicit scares me - but otherwise, it's a great language – Reed Copsey Mar 29 '13 at 16:25
  • Some people mix languages in solutions so that can use language-specific features. See http://stackoverflow.com/q/11003736/211627 – JDB Mar 29 '13 at 16:31

6 Answers6

11

There is no real reason to avoid this, other than adding complexity from having two languages in one "solution".

Your scenario (working with a legacy product, but adding new features) is a valid reason to have both languages used in a single solution, in my opinion.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
8

The only reason that it wouldn't be recommended is consistency. Most developers prefer to deal with a single language when working on an application. Having a single language also means that your developers only need to know a single language rather than knowing both VB.NET and C# (even though the two are extremely similar).

If you need to mix legacy VB.NET and C#, there's no reason not to.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
  • I am working with 2 projects where (simplified) the GUI is written in vbnet and the server side in C#. It helps me switch context - like "do not write business logic in gui/vb" and respectively "i am on a server and share this machine with others". When working with web I say the same with C# on the server and Javascript on the client and HTML for "layout". – LosManos Oct 01 '14 at 07:47
4

It's a matter of "use the best tools available to you for what you're building". Mixing C# and VB within a project isn't recommended (for obvious "it won't compile" reasons), but there's no point in continuing to write old code in VB if you feel your development team can operate faster and in a more maintainable fashion using C#.

We've been doing this at my office for the past few months (in a similar legacy code situation) and have yet to run into any major issues (beyond potential lost dev time due to context switching), and we've gained incredibly from working with a language that we all feel more comfortable with.

More information on task switching here. I really do feel like the benefits we see on a daily basis from our level of comfort with C# outweighs the cost of occasionally having to dip back into the legacy pool.

antinescience
  • 2,339
  • 23
  • 31
  • 2
    I'd agree that context switching between the two languages can add some time, but in the case of a legacy system like the one(s) mentioned, it doesn't generally make sense to take all the time to get the whole legacy system into C#. Legacy VB.Net side by side with new C# actually sounds like the better solution in cases like this. – Justin Edwards Mar 29 '13 at 16:25
0

Its just a matter of person choice. if you are comfortable with both the languages, You surely can use them in same solution.

Using a single language in a solution seems easily maintainable. hence it is preferred.

Parimal Raj
  • 20,189
  • 9
  • 73
  • 110
0

Mixing code in solutions can get real messy real quickly, its never clear what method you are calling from where, to keep it nice. Develop in separate Solutions, it will keep your projects easier to track and make sure you are not confusing languages inside projects

Jakob Bowyer
  • 33,878
  • 8
  • 76
  • 91
0

Why would you want to do that? If you have legacy code what you want to use, you keep that code in its own components, you don't mix it with the new code. It is not recommended because it does not promote "Clean Code". It can lead you to have a solution that is difficult to read and maintain.

MeTitus
  • 3,390
  • 2
  • 25
  • 49