Managing multiple .NET languages in a web application

I am part of a development team building a new ASP.NET 3.5 web application. Two of us are C# coders, and the other is a VB.NET coder.

I know that we can mix languages on a per-project basis, and one can build classes in one language that inherit from classes written in the other language in a different project (which we are already doing), but I can see us getting into a situation where we might well end up with cyclic dependencies between our various project DLLs.

Other than simply having a high number of projects (more seperation of concerns into more libraries), how have you managed this situation on your own projects?

Note - I believe this question to be different enough from the only similar match I could find (this one) on the basis that we are not wanting to use different languages i开发者_如何学Gon order to take advantage of their specific features per se, but rather to make use of what developer resource is available to us (i.e. one dev just happens to be VB.NET only).

---

I got to be honest in saying that I would get the vb.net guy to move to c#.

Sooner or later you are going to want him to work on part of the solution that is a c# project. Its an artificial barrier you're creating when transitioning to a new syntax is relatively straight forward.

Most developers would welcome the opportunity to transition to c#.

I was recently involved in a decision at a major corporate to move to c# from vb.net and we found that this increased morale and was easier to find good candidates.

---

If your shop is predominately C# and that's really what you want your project to be developed in, I would encourage the other developer to learn C# rather than compromising your project to account for lack of knowledge of one of your team members. That's not to put down your other team member, but if he/she has a good grasp of .Net in general, then there's no reason that this person couldn't learn C#.

We have a mix of both at my company, however, the choice to use VB.Net always depends on if we are porting an existing VB6 application to .Net, in which case it makes sense to use VB.Net since less code has to be rewritten (in most cases).

But we'd never let developer skill dictate whether to use C# or VB.Net, we'd choose the best tool for the job, and that should always be the decision point.

---

I would avoid this if possible. Try to gave the VB coder improve their C#. It doesn't have to be immediate, let them write VB for now until they are comfortable with C#, then you may want to go back and refactor the old VB into C#. They are already used to the .NET libraries and tools, it's mostly just the syntax (but yes, there are some language differences).

The reason I suggest this is for future maintenance - you will have to maintain and debug code in two languages. Not a problem if you all know all languages, but can you ensure this will be the case forever?