Would having a nice little feature that makes it quicker to write code like Automatic Properties fit very nicely with the mantra of VB.NET?
Something like this would work perfect:
Public Property FirstName() As String
Get
Set
End Property
UPDATE: VB.NET 10 (coming with Visual Studio 2010 and .NET 4.0) will have Automatic Properties. Here's a link that shows a little info about the feature: http://geekswithblogs.net/DarrenFieldhouse/archive/2008/12/01/new-features-in-vb.net-10-.net-4.0.aspx
In VB.NET 10 Automatic Properties will be defines like this:
Public Property CustomerID As Integer
One reason many features get delayed in VB is that the development structure is much different than in C# and additionally, that often more thought goes into details. The same seems to be true in this case, as suggested by Paul Vick's post on the matter. This is unfortunate because it means a delay in many cases (automatic properties, iterator methods, multiline lambdas, to name but a few) but on the other hand, the VB developers usually get a much more mature feature in the long run (looking at the discussion, this will be especially true for iterator methods).
So, long story short: VB 10 will (hopefully!) see automatic properties.
It also wasn't as big of a pain point in vb.net, since visual studio will automatically create 90% of the skeleton code of a property for you whereas with C# you used to have to type it all out.
If you want to do properties a little quicker, try code snippets.
Type:
Property
and just after typing the "y", press the Tab key :-).
I realize this doesn't answer the particular question, but does give you what the VB team provided...
I know this post is old so you may already know but VB is getting Auto Properties in next version of VS.
Based on response to feedback and Channel9.
C# and VB.NET don't exactly line up on new features in their first versions. Usually, by the next version C# catches up with some VB.NET features and vice versa. I kind of like literal XML from VB.NET, and hoping they add that to C#.
There's no particular reason really. It's been always been the case that even when VB.NET and C# are touted to be equally powerful (and to be fair, they are) their syntaxes and some of the structures sometimes differ. You have two different development teams working on the languages, so it's something you can expect to happen.
automatic properties are not necessary in vb
the concession one makes by using an automatic property is that you can not modify the Get and Set.
If you dont require those, just make a public data field.
VB has had automatic properties for years. They just called them something else.
Related
I'm just starting out with C# and to me it seems like Microsoft Called their new system .Net because you have to use the Internet to look everything up to find useful functions and which class they stashed it in.
To me it seems nonsensical to require procedure/functions written and designed to stand alone ( non instantiated static objects) to have their class not also function as their namespace.
That is Why can't I use Write or WriteLine instead of Console.WriteLine ?
Then when I start to get used to the idea that the objects I am using ( like string) know how to perform operations I am used to using external functions to achieve ( like to upper, tolower, substring, etc) they change the rules with numbers, numbers don't know how to convert themselves from one numeric type to another for some reason, instead you have to invoke Convert class static functions to change a double to an int and Math class static functions to achieve rounding and truncating.. which quickly turns your simple( in other languages) statement to a gazillion character line in C#.
It also seems obsessed with strong typing which interferes somewhat with the thought process when I code. I understand that type safety reduces errors , but I think it also increases complexity, sometimes unnecessarily. It would be nice if you could choose context driven types when you wish without the explicit Casting or Converting or ToStringing that seems to be basic necessity in C# to get anything done.
So... Is it even possible to write meaningful code in notepad and use cl with out Internet access? What ref book would you use without recourse to autocomplete and Network access?
Any suggestions on smoothing the process towards grokking this language and using it more naturally?
I think you're suffering a bit from the fact that you've used to working in one way during some years, and now must take time to get yourself comfortable using / developing in a new platform.
I do not agree with you , that MS hasn't been consistent on the fact that a string knows how it should convert itself to another type, and other datatypes (like ints) do not.
This is not true, since strings do not know for themselves how they should be converted to another type as well. (You can use the Convert class to Convert types to other types).
It is however true that every type in .NET has a ToString() method, but, you should not rely on that method to convert whatever you have to a string.
I think you have never worked in an OO language before, and therefore, you're having some difficulties with the paradigm shift.
Think of it this way: it's all about responsabilities and behaviour. A class is (if it is well designed) responsible for doing one thing, and does this one thing good.
There is no excuse to use notepad to code a modern language. SharpDevelop or Visual C# Express provide the functionality to work with C# in a productive way.
And no, due to the complexity, not using the internet as a source of information is also not a good option.
You could buy a book that introduces you to the concepts of the language in a structured way, but to get up-to-date information, the internet is neccessary.
Yes, there are drawbacks in C#, like in any other language. I can only give you the advice to get used to the language. Many of the drawbacks become understandable after that, even if some of them don't become less annoying. I recommend that you ask clear, direct questions with example code if you want to know how some language constructs work or how you can solve specific problems more efficiently. That makes it easier to answer those questions.
For notepad, I have no useful advice, however I would advise you to use one of the free IDE's, Microsofts Express Editions, or Sharp Develop.
The IDE will speed the groking of the language, at which point, you can switch back to notepad.
Reading your post I was thinking that you worked mostly with C or dynamic languages previously. Maybe C# is just a wrong choice for you, there are IronPython, F# and a bunch of other languages that have necessary functionality (like functions outside of classes etc.)
I disagree with you about consistency. In fact there are small inconsistency between some components of .NET, but most part of FW is very consistent and predictable.
Strong typing is a huge factor in low defect count. Dynamic typing plays nice in small/intermediate projects (like scripts, etc). In more or less complex program dynamism can introduce a lot of complexity.
Regarding internet/autocomplete - I can hardly imagine any technology with size of .NET that doesn't require a lot of knowledge sources.
Programming in c# using notepad is like buying a ferrari to drive in dirt roads.
At least use Visual Studio Express Edition. For what you wrote I understand that you come from a non OO background, try to learn the OO concept and try to use it. You will eventually understand most design decisions made for .Net.
http://en.wikipedia.org/wiki/Object-oriented_programming
Oh boy where do i start with you(this will be a long post hahaha), well, lets go little by little:
"Microsoft called their system .NET because you have to use Intenet...", the reason why is called .NET is because the SUITE OF MICROSOFT LANGUAGUES(and now some other ones too like Phyton and Ruby, etc) CAN CALL ANY LIBRARY or DLLs, example you can "NET"(Network OR CALL) a DLL that was built in Visual Basic, F#, C++ from WITHIN C# or from any of those languagues you can also call(or ".NET") C# libraries. OK ONE DOWN!!!
NEXT ONE: "it seems nonsensical to require....to have their class not also function as their namespace", this is because a Namespace can have AS MANY CLASSES AS YOU WISH, and your question:
"That is Why can't I use Write or WriteLine instead of Console.WriteLine ?".
The reason is because: "Console"(System.Console hense the "Using" statement at the beginning of your program) Namespace is where "Write" and "WriteLine" LIVES!!(you can also FULLY qualify it (or "call It"). (all this seems to me that you need to study C# Syntax), ok NEXT:
"when I start to get used to the idea that the objects...", ok in simple words:
C# is a "Strongly Type-Safe language" so that SHOULD-MUST tell you what "you are getting in to" otherwise STAY WITH "WEAK or NO TYPE SAFE LANGUAGES" LIKE PHP or C , etc. this does NOT means is bad it just MEANS IS YOUR JOB TO MAKE SURE, as i tell my students: "IF YOU NEED AN INT THEN DEFINE AN INT INSTEAD LETTING THE COMPILER DO IT FOR YOU OTHERWISE YOU WILL HAVE A LOT OF BAD BUGS", or in other words do YOUR homework BEFORE DESIGNING A PIECE OF SOFTWARE.
Note: C# is IMPLICITY TYPE SAFE language SO IF YOU WANT YOU CAN RUN IT AS UNSAFE so from then it wiLL be your job to make sure, so dont complain later(for being lazy) when bugs arrive AT RUNTIME(and a lot of times when the customer is already using your crappy software).
...and last but not least : Whey do you wan to shoot yourself by using notepad? Studio Express is FREE, even the database SQL SERVER is FREE TOO!!, unless you work for a company I WILL ASK FOR PRO, ETC. all the "extra" stuff is for large companies, teams, etc, YOU CAN DO 99% OF THE STUFF WITH THE FREE VERSIONS(and you can still buy-update to full version once you want to scalate to Distributed Software or a Large Project, or if your software becomes a big hit, Example: if you need millions of queryes or hits PER SECOND from your database or 100 people are working on same project(code) but for the majority of times for 2 or 3 "normal" developers working at home or small office the FREE ONES ARE ENOuGH!!)
cherrsss!!! (PS: Software Developer since the 80's)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What in C#.NET makes it more suitable for some projects than VB.NET?
Performance?, Capabilities?, Libraries/Components?, Reputation?, Reliability? Maintainability?, Ease?
Basically anything C# can do, that is impossible using VB, or vice versa.
Things you just have to consider when choosing C#/VB for a project.
C# and VB are basically the same however there are some minor differences. Aside from the obvious grammar differences you have the following differences:
C# can call unsafe code
VB has optional parameters (Coming in C#4.0)
VB is easier to use when making late bound calls (Coming in C# 4.0) This and number make 2 make using VB to do office automation much cleaner.
VB has a bunch of "helper" functions and class like the My namespace; however, all of this are accessible to C#
VB is case insensitive
C#'s syntax follow a similar grammar to c and java, which make it a much more comfortable transition from those languages, where as VB can be more comfortable to VB users. As far performance, and libraries or components they are nearly identical.
As for which one to choose, unless you have a need to do unsafe operations, then choose the language which is most natural to you. After years of being a VB developer I loved not having to write If yadada then.....End If if (yadaya){....} saves my carpal tunnel a few extra keystrokes (Which can then be used on answering SO questions)
Edit
Just learned one more difference btw C# and VB is that VB supports filtered exceptions so you could something like this pseudo:
try
{
//do something that fails
}
catch(Exception ex when ArgumentException,
ArgumentNullException, FormatException)
{
//Only handle these three types
}
This should not be confused with the ability to do:
try
{
//something that fails
}
catch(ArgumentException)
{
//Log Error
}
catch(ArgumentNullException)
{
//Log Error
}
In this case you are going to handle the exceptions differently in the VB world you could define one piece of code to handle multiple types of Exceptions.
Edit
Some more differences.
VB's Is operator compares two objects to determine if they are the same it compiles to the CEQ IL instruction where as C# compiles to isinst IL. So the following are equivalent statements
c#
if (foo is FooObject){}
vb
If TypeOf foo is FooObject then
Also as mentioned in the comments and I wish I could see them to give you credit but C# doesn't have a like parameter. You need to use the RegEx class.
I think this blog post by Kathleen Dollard provides an excellent overview to the question:
What a C# Coder Should Know Before They Write VB
and her first advice is:
1) Get over the respect thing or quit
before you start. VB is a great
language.
Street cred among geeks.
(And don't pretend that's not important!)
Others have covered a lot of the differences - as has been said several times, they're nearly equivalent languages. A few differences which haven't been covered as far as I've seen:
VB9 has:
XML literals
Mutable anonymous types (urgh)
More LINQ support in the language (C# only covers a few operators)
A whole bunch of extra bits in the language which get compiled down to calls to the Microsoft.VisualBasic assembly. (C# prefers to be a small language with the weight of the .NET framework behind it.)
DateTime literals
C# 3 has:
Better support for lambda expressions: IIRC, you can't write a lambda expression with a block body in VB.
Iterator blocks.
Syntax for extension methods (instead of decorating the method with an attribute)
I suspect there is more, but I thought I'd just throw those into the mix.
When you hit a problem, you'll often be able to Google for a code sample that shows how to solve it in minutes. This is a significant factor in improving productivity. When I was working with Delphi, I had to convert code samples from C into Object Pascal - doable, but tedious, i.e. lots of friction. So don't underestimate the fact that...
The vast majority of .Net code samples are in C# !
In early versions of VB.NET, the difference was more obvious, however with the current version, there are no significant differences.
VB supports XML literals directly in code, which is not supported by C#. C# supports unsafe code and VB don't. Technically these two are the biggest differences. There are many small variations but they are not important. I like C# more because I think the syntax is much less bloated. It's easy to recognize the blocks of code instead of seeing a bunch of keywords, but that's a pure personal preference.
Choose the one you and your team are more familiar with.
VB.Net has a root namespace and C# has a default namespace which is not the same. Because when you have a root namespace in VB.Net it will always add that before the namespace.
For example: if you have a rootnamepsace in VB.Net named namespace1 and then you add this to your file.
Namespace namespace1
Public Class class1
End Class
End Namespace
then you will have to refer to it as namespace1.namespace1.class1
in C# if you have a default namespace called namespace1 and you this in your file.
namespace namespace1{
public class class1{}
}
Then you can still just refer to it as namespace1.class1
My favorite feature of C# that VB doesn't have is the yield statement. It lets you easily return an lazily evaluated IEnumerable from a method.
Here is an article that covers it: http://msdn.microsoft.com/en-us/magazine/cc163970.aspx
VB has a better feedback on errors. In C# you have to compile more often to get all the errors in your syntax.
The big advantage i see with C# is that the vast majority of open source projects, sample code and blog snippets are written in C#. Although it’s easy to convert these to VB.NET with tools (or your head) it is still a monotonous task for VB devs (like me).
Even if you write in VB.NET day to day, you will still need to be able to read C#
Technically, they share the same framework with same performance and memory characteristics and same type systems, so I find it hard to hard to split the two.
Most good developers should be able to shift between the two with a few days adjustment time.
My core frustaration lies with the hundreds of time I have written:
String lastName as String
and wondered why it never compiles!
In C# you can have more fine tuned control over events/delegates. But you rarely need this.
There are a lot more code examples for C#.
In VB.Net it is (a lot) easier to use late binding. For example to COM objects (in C# from version 4.0).
I use C# for 90% in my projects
I use VB.Net for interop to Excel, etc
As soon as I know F# better, I will probably use it for the parts that F# is better suited for.
Performance?
No difference, though VB historically uses a weird indexing in loops which means that you have to subtract 1 from the highest index most of the time:
For i = 0 To someArrayOrString.Length - 1 …
Though I doubt this impacts performance in any measurable way.
On the other hand, due to background compilation, VB actually compiles seemingly faster. Some people claim that this makes the IDE react sluggishly but I've never noticed that myself.
Capabilities?
In a few instances, C#'s yield statement is really useful. VB requires more manual work here. Also, lambdas are much better implemented in C#, especially syntactically. Consider these two statements:
Parallel.For(1, 10000, i => {
// Do something
});
versus
Parallel.For(1, 10000, Sub() _
' Do something '
End Sub)
Besides the fact that VB can't do this yet, and that a comment at this place is forbidden, it's just more clutter and generally a no-go.
Libraries/Components?
Identical.
Reputation?
Not important. “Street cred”? Sorry. Not a factor. Get over it, Nick.
Reliability?
Maintainability?
Ease?
More or less identical. I claim that VB is easier but that may be biased and in any way, it's only marginal.
As I understand it, there are differences between the languages though they are minimal. I would suggest working with the language that you/your developers would feel most comfortable with. If they already have VB experience then I'd suggest VB.Net/vice-versa.
Though I prefer the terse syntax of C# personally. :)
Since C# and VB.Net both compile into MSIL, both have nearly identical Performance, Capabilities, Libraries and Components. Reflection can deassemble MSIL code into either C# or VB.NET (or a number of other languages)
This basically leaves us with, C# looks a lot like Java and C++ which gives it more credibility.
I think Josh gave a good rollup on the language differences.
Tooling Support
There are however also differences in how Visual Studio handles these languages.
Code Snippets are easier to use from the C# editor and the refactoring is better also.
The VB-editor simplifies intellisense by not showing all options at all times.
I'm sure there are more things, but those are the ones that I as a C#'er (doing very little VB) have noticed.
Here is another point not yet covered in this trail:
Higher Degree of Employability + Better (more) Dev Resources
Now I don’t agree with this point of view however:
There are more C# dev shops that VB shops
Some backward c# employers will put you at a serious disadvantage if you are stronger with VB. So maybe C# is the better choice here.
On the flip side, when you go to hire people for your C# project, you will be able to attract more candidates to iterview and get better skills as a result – I don't think detail should be overlooked.
I have to say it's been my experience when using Google to search for examples or documentation that C# examples are of better quality than VB examples. This isn't to say that there aren't bad C# examples, but if you search for something like "dictionary drop down" adding C# will provide a better quality answer higher on the list.
This doesn't apply to examples that display both C# and VB code side by side.
for the moment VB.Net has a very poor implementation of lambda expressions. Meaning that you can't do the neat things that you can in C#. Well you can, but it needs a very ugly workaround in most cases.
This is solved in VB.Net 10.0.
Free from old cruft, array declaration in C# is not padded with extra element. VB.NET array is padded with extra element, so legacy VB6 code migration is easier.
C# is more consistent than VB.NET
Button1.Color() = Color.Red
Button1.Color = Color.Red
I can't give an answer when one student asked me when to use parenthesis on properties of VB.NET. It's hard to give an insightful reasoning for this kind of misfeature.
Consistency with instance and static members. VB.NET allows accessing static members on instance e.g. yarn.Sleep(1000), this is a misfeature. https://stackoverflow.com/questions/312419/language-features-you-should-never-use
I've been hearing/reading a lot about the new language enhancements for C# 4. I'm a little curious if these same enhancements are also going to be applied to VB as well, or what. Does anyone know where I can get some insight here? With all the new changes happening to C#, it seems like there will very little reason left to be using VB unless you happen to like the syntax. Are there enhancements that MS isn't making to VB this time that are getting included in C#, or visa versa?
I'd actually overlook the dismissal of VB.Net by Lou Franco. Checkout Panopticon Central:
http://www.panopticoncentral.net/archive/2008/10/31/24803.aspx
http://www.panopticoncentral.net/archive/2008/10/29/24764.aspx
For example:
Then Lucian did a really wonderful
demo of VB 10.0, which is shipping in
Visual Studio 2010. He showed (IIRC)
the following features that should be
familiar to the readers of this blog:
array literals, collection
initializers, automatic properties,
implicit line continuations, statement
lambdas, generic variance, and a
feature that embeds primary interop
assembly types in your assembly so you
don’t have to deploy the PIA. I may
have missed some, so check out the
video when it’s posted!
Some of the changes to C# (e.g Named Optional Parameters) were already in VB. The main strength of VB.NET over C# was Office/COM integration, and the new C# is addressing that.
If you need to target an older .NET version, VB.NET will still be the one to use if you need these features.
Something still missing from C# that vb.net has had a little while: xml literals. But this isn't exactly new.
Certainly there's the difference in general syntax, but what other critical distinctions exist? There are some differences, right?
The linked comparisons are very thorough, but as far as the main differences I would note the following:
C# has anonymous methodsVB has these now, too
C# has the yield keyword (iterator blocks)VB11 added this
VB supports implicit late binding (C# has explicit late binding now via the dynamic keyword)
VB supports XML literals
VB is case insensitive
More out-of-the-box code snippets for VB
More out-of-the-box refactoring tools for C#Visual Studio 2015 now provides the same refactoring tools for both VB and C#.
In general the things MS focuses on for each vary, because the two languages are targeted at very different audiences. This blog post has a good summary of the target audiences. It is probably a good idea to determine which audience you are in, because it will determine what kind of tools you'll get from Microsoft.
This topic has had a lot of face time since .Net 2.0 was released. See this Wikipedia article for a readable summary.
This may be considered syntax, but VB.NET is case insensitive while C# is case sensitive.
This is a very comprehensive reference.
Since I assume you can google, I don't think a link to more sites is what you are looking for.
My answer: Choose base on the history of your developers. C# is more JAVA like, and probably C++ like.
VB.NET was easier for VB programmers, but I guess that is no really an issue anymore sine there are no new .NET programmers coming from old VB.
My opinion is that VB is more productive then C#, it seems it is always ahead in terms of productivity tools (such as intelisense), and I would recommend vb over c# to someone that asks. Of course, someone that knows he prefers c# won't ask, and c# is probably the right choice for him.
Although the syntax sugar on C#3 has really pushed the bar forward, I must say some of the Linq to XML stuff in VB.Net seems quite nice and makes handling complex, deeply nested XML a little bit more tolerable. Just a little bit.
One glaring difference is in how they handle extension methods (Vb.Net actually allows something that C# doesn't - passing the type on which the extension method is being defined as ref): http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Apart from syntax not that much any more. They both compile to exactly the same IL, so you can compile something as VB and reflect it into C#.
Most of the apparent differences are syntactic sugar. For instance VB appears to support dynamic types, but really they're just as static as C#'s - the VB compiler figures them out.
Visual Studio behaves differently with VB than with C# - it hides lots of functionality but adds background compiling (great for small projects, resource hogging for large ones) and better snippet support.
With more and more compiler 'magic' in C#3 VB.Net has really fallen behind. The only thing VB now has that C# doesn't is the handles keyword - and that's of debatable benefit.
#Tom - that really useful, but a little out of date - VB.Net now supports XML docs too with '''
#Luke - VB.Net still doesn't have anon-methods, but does now support lambdas.
The biggest difference in my opinion is the ability to write unsafe code in C#.
Although VB.NET supports try...catch type exception handling, it still has something similar to VB6's ON ERROR. ON ERROR can be seriously abused, and in the vast majority of cases, try...catch is far better; but ON ERROR can be useful when handling COM time-out operations where the error can be trapped, decoded, and the final "try again" is a simple one line.
You can do the same with try...catch but the code is a lot messier.
This topic is briefly described at wikipedia and harding.
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET
http://www.harding.edu/fmccown/vbnet_csharp_comparison.html
Just go through and make your notes on that.
When it gets to IL its all just bits. That case insensitivity is just a precompiler pass.
But the general consensus is, vb is more verbose.
If you can write c# why not save your eyes and hands and write the smaller amount of code to do the same thing.
One glaring difference is in how they handle extension methods (Vb.Net actually allows something that C# doesn't - passing the type on which the extension method is being defined as ref): http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Yes VB.NET fixed most of the VB6 problems and made it a proper OOP language - ie. Similar in abilities to C#. AlthougnI tend to prefer C#, I do find the old VB ON ERROR construct useful for handling COM interop timeouts. Something to use wisely though - ON ERROR is easily abused!!
Certainly there's the difference in general syntax, but what other critical distinctions exist? There are some differences, right?
The linked comparisons are very thorough, but as far as the main differences I would note the following:
C# has anonymous methodsVB has these now, too
C# has the yield keyword (iterator blocks)VB11 added this
VB supports implicit late binding (C# has explicit late binding now via the dynamic keyword)
VB supports XML literals
VB is case insensitive
More out-of-the-box code snippets for VB
More out-of-the-box refactoring tools for C#Visual Studio 2015 now provides the same refactoring tools for both VB and C#.
In general the things MS focuses on for each vary, because the two languages are targeted at very different audiences. This blog post has a good summary of the target audiences. It is probably a good idea to determine which audience you are in, because it will determine what kind of tools you'll get from Microsoft.
This topic has had a lot of face time since .Net 2.0 was released. See this Wikipedia article for a readable summary.
This may be considered syntax, but VB.NET is case insensitive while C# is case sensitive.
This is a very comprehensive reference.
Since I assume you can google, I don't think a link to more sites is what you are looking for.
My answer: Choose base on the history of your developers. C# is more JAVA like, and probably C++ like.
VB.NET was easier for VB programmers, but I guess that is no really an issue anymore sine there are no new .NET programmers coming from old VB.
My opinion is that VB is more productive then C#, it seems it is always ahead in terms of productivity tools (such as intelisense), and I would recommend vb over c# to someone that asks. Of course, someone that knows he prefers c# won't ask, and c# is probably the right choice for him.
Although the syntax sugar on C#3 has really pushed the bar forward, I must say some of the Linq to XML stuff in VB.Net seems quite nice and makes handling complex, deeply nested XML a little bit more tolerable. Just a little bit.
One glaring difference is in how they handle extension methods (Vb.Net actually allows something that C# doesn't - passing the type on which the extension method is being defined as ref): http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Apart from syntax not that much any more. They both compile to exactly the same IL, so you can compile something as VB and reflect it into C#.
Most of the apparent differences are syntactic sugar. For instance VB appears to support dynamic types, but really they're just as static as C#'s - the VB compiler figures them out.
Visual Studio behaves differently with VB than with C# - it hides lots of functionality but adds background compiling (great for small projects, resource hogging for large ones) and better snippet support.
With more and more compiler 'magic' in C#3 VB.Net has really fallen behind. The only thing VB now has that C# doesn't is the handles keyword - and that's of debatable benefit.
#Tom - that really useful, but a little out of date - VB.Net now supports XML docs too with '''
#Luke - VB.Net still doesn't have anon-methods, but does now support lambdas.
The biggest difference in my opinion is the ability to write unsafe code in C#.
Although VB.NET supports try...catch type exception handling, it still has something similar to VB6's ON ERROR. ON ERROR can be seriously abused, and in the vast majority of cases, try...catch is far better; but ON ERROR can be useful when handling COM time-out operations where the error can be trapped, decoded, and the final "try again" is a simple one line.
You can do the same with try...catch but the code is a lot messier.
This topic is briefly described at wikipedia and harding.
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET
http://www.harding.edu/fmccown/vbnet_csharp_comparison.html
Just go through and make your notes on that.
When it gets to IL its all just bits. That case insensitivity is just a precompiler pass.
But the general consensus is, vb is more verbose.
If you can write c# why not save your eyes and hands and write the smaller amount of code to do the same thing.
One glaring difference is in how they handle extension methods (Vb.Net actually allows something that C# doesn't - passing the type on which the extension method is being defined as ref): http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Yes VB.NET fixed most of the VB6 problems and made it a proper OOP language - ie. Similar in abilities to C#. AlthougnI tend to prefer C#, I do find the old VB ON ERROR construct useful for handling COM interop timeouts. Something to use wisely though - ON ERROR is easily abused!!