I often get asked this question: how do we decide between C# and Visual Basic .NET? (Not “Should we use C# or Visual Basic .NET?”) 

I generally make the points that the languages are pretty much on par, feature-wise; that I usually see organizations with a VB legacy shifting to VB.NET; that organizations with a C++ or Java legacy usually move to C#; that the big learning curve for VB developers is OO and the framework, not the syntax change; and that an organization should stick to one language within some sensible boundary – an application, a team, a development group.

A new argument came to me when visiting a customer yesterday.  When I said “you should stick to one language for a given group”, they said “what about components that are shared across the enterprise?”  They were concerned that a group that’s using, say, VB.NET, wants to edit a shared component in, say, C#.  First off, I made the point that a VB.NET developer is going to be able to read C# - the framework is the common language – so debugging shouldn’t be a problem.  More interesting, though, is the point that components that are shared this way better need precious little editing by groups around the organization – they’d better be tested, tested, tested, and have a well-defined process for submitting change requests.  Some of my larger customers are beginning to undertake efforts to build repositories of shared assets, and a strict process of ownership and control for those assets is a critical element for success. (Open source comes to the enterprise.)