Hi
I have just moved job and gone from VB 6 to VB.Net and found the learning jump fairly steep, have more a problem with the object / conceptual side of things .. but getting there now ... but as I was a assembler / C++ 10/15 years ago and was considering learning C++/C# .Net (XNA games library calls my name) but not sure if it would hinder my VB.NET learning .... or should I just get myself certified
To me the biggest obstacle for .NET is learn what is available in the framework. Therefore, if you find it easier to code in C# it will mean you only struggle with one thing instead of two. Once you know the framework it's just syntax really as 95% of the stuff you can do with C# can be done with VB.
Also, C# will force you to write code in a more object orientated manner as you can't fall back to coding in a VB6 style.
'yield return' is an example of something that doesn't have an equivalent in VB9 (there are rumours this is being added for VBX though).
I was (back in the day) a VB6 dev, and I would expect it to help. There is a much-commented tendency for VB6 developers to keep writing VB6 in .NET; even just a brief look at C# might help you think about VB.NET as a .NET language, rather than a Visual Studio 6 ancestor.
Of course, you might find (as I did) that you don't want to go back to VB.NET after C# ;-p
But as has already been mentioned - the framework is identical. And with C# 4.0, many of the differences will become even less (with "dynamic" making it easier for C# to talk to late-bound COM, and the named arguments / auto-ref stuff making it easier for typed COM).
There is a lot of drive for converging the feature sets of C# 4.0 and VB.NET in VS2010
I was also a VB6 developer before switching to .NET. First I tried to use VB.Net but it never felt comfortable so I tried C# and fell in love with it. :-)
There are some differences as noted in the previous replies, there are things you can do in VB.Net that you can't in C# (like indexed properties) and vice versa. But apart from that the differences are purely in the syntax. There are in fact several available translators that will convert C# to VB.Net and back.
So I would recommend you to try out C#. Since you know some C++ it shouldn't be very hard to get the syntax right, and the rest is learning to use the framework.
Apart from the fact that a large part of what you need to know is about the Frameworks's libaries learning another syntax that targets the .NET's CLR is useful.
Seeing how another language expresses the same concepts helps you to separate the concepts from the language. This is always useful because the concepts are fairly constant, (for example a shadowed(VB) or hidden(C#) function) whilst different languages use different words to express them.
Understanding the concepts better will help you to utalise them when designing code.
IMX, learning C# helped me with learning VB. It's something about seeing the same concepts expressed in 2 ways rather than just 1.
EDIT: Anthony Jones beat me to it :-)
As a devoted .Net developer I have worked on big projects in both C# and VB.net. Having seen the strengths and weaknesses of both languages I have found VB to be the most frustrating at times.
The problem is that with VB (depending on your project settings) it will magically perform implicit operations such as casts. This can be helpful sometimes, but in the general case you do not want your code to do something unless you explicitly tell it to (this is how C# behaves, in an explicit manner). I would prefer a compiler time error to tell me I cannot convert from one object type to another rather than a runtime exception in our live deployment.
I have found that this implicit aspect of VB tends to hamper the "VB only" developer's understanding of what is going on behind the scenes. For these people, looking at C# seems to trigger some lightbulbs, where they say "aha!, that must be what VB is actually doing when I perform this operation".
I'd recommend you give C# a try, it'll give you a new perspective and you might find that you really like it.
Docta
The only real hindrance learning C# would have to VB is documentation. There seems to be a lot more information out there for C# users and trying to find the VB equivalent syntax of sometimes pretty standard C# can be a pain.
That being said... it never hurts to know alot of different ways to do the same thing.
I agree with Garry, the biggest issue is the API.
The second biggest issue I have personally observed is VB6 developers writing VB6 code in VB.NET. That's a good reason in itself for VB6 developers to learn C# - it forces you to think in .NET style.
Well for one thing if your method does not return anything then you have to create a Sub in VB.NET and if it returns anything then call it a Function!
I just switched from C# to VB.NET (client requirement) and am still getting used to its nuisances :(
I would say coding in VB almost takes the OOPS out of .NET