I started with VB4 way back in the day, so working in VB.NET isn't entirely new to me.
Recently, I've been working mostly with C# (I also have a background in C++), but I started maintaining a project that was written in VB.NET. Most of my existing .NET and VB skills transferred over, which was nice, but I would imagine that other people may not have worked with VB before C#.
How important is it in the real world to be fluent in both C# and VB.NET?
That entirely depends on your context - it sounds like it's important for you to be at least reasonably comfortable in VB, as you're maintaining a VB project.
Many C# or VB developers will never need to deal with code in the other language - although for the sake of having a wider variety of blog reading, it's at least useful to be mildly familiar. (That's probably more important for VB developers - there seem to be more blogs giving sample code in C# than in VB.)
I'd say it's important so that, regardless of your own preference, you can look at other developers' code and even work with them on it without being useless. That said, it's very easy to be fluent in both if you're fluent in one. It's pretty much only syntax differences (very few minor exceptions to this rule), which makes it a lot easier to translate between them conceptually than for any other arbitrary pairing of different programming languages -- even quite similar ones like C# and Java.
If you use VB.NET, it is almost a requirement to be able to read C#, because of the amount of information on the web that is written in C#. The reverse is very much less useful.
It's certainly handy from the perspective of online help and tutorials to at least be able to understand what is hapening with code in "the other language"...
Personally, I prefer C# but use VB.Net as well - not because I want to, but because anythign that ends up going near the office has to be in VB.Net as that is the agreed .Net language we use...
I started with VB3 all the way to .NET before switching to C#. The "importance" is subjective, as it depends on what you work on. Plenty of companies use VB.NET and look for VB.NET Developers. I personally prefer C#. If you have to choose between the two, I always find Microsoft's comments on each of the targeted audiences for VB and C#:
Microsoft® Visual Basic® 2008 Express Edition is ideal for the developer learning to program on Microsoft® Windows®.
Microsoft® Visual C#® 2008 Express Edition offers a greater combination of power and productive for Windows developers building on .NET.
C# is significantly more marketable, a quick check on JobServe shows that there are currently 1702 jobs being advertised mentioning C# and only 344 mentioning VB.Net.
I know of companies that have taken C# devs to work on VB.Net, but not the other way round.
I used to use both VB.NET and C#. Now I'm writing all new code in C# but still have to maintain some older projects that use VB.NET. I find it fairly easy to switch between the two as the .NET library is largely the same in both. There are a few differences but if you are fluent in one, working in the other isn't too difficult. It's just a matter of knowing the differences and adjusting. It usually takes me a few minutes to make the switch to VB.NET as I keep trying to put curly braces and semi-colons everywhere but after a little while my brain makes the switch. Focus on one language and just know that working in the other will take a bit more time.
If you are a VB programmer, I think it's almost crucial that you know C# because there are a lot more C# jobs out there than VB. And there is still the stigma attached to VB programmers, even if it is unfounded.
If you are a C# programmer, there is no reason at all to know VB. You will almost NEVER be asked to convert a C# application to VB, at least I've never heard of such things.
I would say that a working knowledge of the differences between your language of choice, and the "other .NET languages" is important, especially if you are doing any project based work or consulting work.
I can't tell you how many times as a C# programmer I had the possibility to go to a client that was only a "VB House", and only wanted to see people who had "VB.NET" experience, no matter how good they were in C# and .NET in general.
This is mostly an educational issue with technical recruiters and HR people, who don't understand how .NET works, and the fact that a C# person can easily integrate into a VB House, and vice versa.
Having a working knowledge with project background (even if minor) that you can place on your resume goes a long way to opening doors to clients or projects that might normally have rejected you for that one stupid reason.
These days, I am primarily a C# programmer, but recently I had to deal with (and modify) a bunch of VB.Net code. Rather than learn the ins and outs of the VB.Net syntax, I used this online code converter:
http://www.developerfusion.com/tools/convert/vb-to-csharp/
Note that Reflector can also do similar conversions, but the online converter was simpler to use because it would convert snippets of code.
It's an important indictator of your ability. If you say you know C# really well, then you should have no problem understanding VB.NET; if you do, that means you really don't understand general programming concepts as well as you should. Especially since VB and C# really are very similar (aside from certain special features, which the C# and VB.NET teams have decided to "co-evolve"; instead of having different features, they will always have the same set of features, just implemented differently, at least that's the current plan as stated by the VB and C# team(s)).
As a programmer you should be able to learn new languages, ever faster and easier.
I think it's a matter of looking at the easy win - learning the syntax for the other language is not so hard, and it's an easy addition to what you are able to do when looking for a job. I think that there are a number of houses that have gone the route of 'classic' ASP > VB.net and then decided that C# is more pleasant and thus have a variety of projects in different languages.
Being able to dip in and out of whatever .net language is required of you when asked to maintain something is a useful thing to be able to do (although when you start writing If... Then and then trying to close it with a curly brace, you might be switching around too much).
My experience has been that recruiters and HR people are thick when it comes to understanding the differences between VB.NET and C#. If you say you know C# and not VB.NET and their job requirement is VB.NET, they'll pass you over.
For the purposes of actual job performance, what matters is knowing the framework. Knowing the syntax of Javascript gets you no where if you don't know the DOM. So, in my experience if you know one you can easily learn the other. I've hired smart VB.NET only developers on C# jobs and they have been able to quickly adapt. In a way, it is harder for C# people to adapt to VB.NET because VB.NET went off the reservation with key concept terminology (Shared instead of Static, MustInherit instead of Abstract etc.)
A good programmer can switch back and forth and pick up the core of a new language and start coding in it after a day and will learn the majority of its features quickly. With .Net and C# the only real difference is the syntax. They both use the same framework.
Knowing a language does not mean you know how to program. I may know English, but that doesn't mean I can write a play like Shakespeare.
You should be fluent in a lot of languages, not only c# and vb.net. Sticking to one language or two will be bad for your career.
You should diversify your knowledge. C#, Java, Python, Ruby, Objective-C, AS3 at least.
Not very :)
You can specialize in either of the two, and have plenty of work.
Even if you only code in one you should be able to read code in both. If you can't that tells something about your ability (or inability).
Being able to read VBNET is one thing. Being able to read C# is one other thing. Being able to know the difference between what is doable in C# and not in VBNET and vice-versa, is THE thing.
I'm a C# programmer with Assembler, C/C++ background and about 8 years of experience, and I have already used VB6 a little, enough to be able to debug code, etc. So VB syntax is nothing new to me.
However, when you know how to do something in C# using the lambda expressions, the predicates, etc. and try to bring this with you in VBNET, you might get a hard time trying what VBNET ends not offering at all.
The .NET Framework makes it easier in our situation since we're always talking .NET, the objects are the same, they do the same, and they all have the same behaviour. However, when using Linq and the .NET 3.5 features, you need to know for instance that VBNET doesn't support lambdas which don't return a value, you need to pass in the AddressOf Sub in order to do the same.
But that said, once you understand what you're doing in .NET, one may grow fluent in both easily enough to be at ease in C# and VBNET. Thus, you perhaps need to know that Microsoft's .NET façade language is C#. They tend to bring some more features in VBNET2010 from C# 4.0 so that these differences are no longer a matter of choosing C# against VBNET. Let's hope they succeed! =)
I wouldn't worry about ti too much. Becasue of the similarities in the semantics of the two languages, if you're fluent in one of them you are already 90% of the way there in the other one.
I think its important to know both, looks better on a resume. I think if you learn C# first and then learn VB.NET its easier than going the other way. VB.NET lets you get away with a lot of stuff that C# doesn't put up with. I prefer C#, especially if you are working with JavaScript a lot since the syntax is similiar.
Both are complimentry to each other and so it is always good to have knowledge on both but again it is not an requirement that to understand C# you need to know VB.net but yes having knowledge of VB.net would always help you to understand C# better.
One thing missed in all these answers is that VB .NET is the macro language in Visual Studio. If you can't write VB .NET, you can't write Visual Studio macros to automate common tasks.