For me, developing for the Java ecosystem payed the bills for many years. However, for several years now, I have been working primarily in the .Net space. Initially, my transition into the .Net world consisted of writing and maintaining VB.Net code. VS provided almost all of the nice intellisense support I came to expect after years of working with the Eclipse/Java combo. Eventually my employer decided to do new development in C#. My initial impression of the intellisense support for C# was less than stellar. At times it seems as if VS has no background compiler for C#, but occasionally it does something smart, indicating there is some background processing there, but not quite enough to really boost productivity in meaningful ways. Is there any sane technical reason for this discrepancy regarding intellisense support between the two languages?
It (Intellisense for C#) works for me, very well IMO (though I've never run VB to cmompare it). Maybe there's some other thing wrong with your machine: for example maybe now you don't have enough RAM for whatever you're running, so everything's swapping and thus extremely slow?
There has been a gap between C# and VB for awhile now. VB generates a lot of code for you. For example, hitting enter after finishing an "If" statement will automatically add the "Then" at the end of that line if you left it off, and close it off with the "End If" portion. In C# it's up to you to add those starting and closing {} curly braces.
VB has had background compilation long before C#. In fact, that was one of the major appealing factors of using ReSharper, which provided such functionality. However, as of VS 2008 / .NET 3.5 SP1 that all changed. You can read Scott Gu's post about that here, but I'll paste the relevant part:
"The C# code editor now identifies and displays red squiggle errors for many semantic code issues that previously required an explicit compilation to identify. For example, if you try to declare and use an unknown type in the C# code-editor today you won't see a compile error until you do a build. Now with SP1 you'll see live red squiggle errors immediately (no explicit compile required)."
Using CodeRush or ReSharper definitely enhances the experience with the autocompletion of common statements which would make a VB developer feel like there has been a seamless transition.
EDIT: more details below
That doesn't quite address technical concerns, but the development teams are different and didn't necessarily do the same thing. In other words, there's not likely to be a shared approach. This blog post excerpt, by a Technical Lead on the VB team, supports this:
“Background compilation” is the feature in VB that gives you a complete set of errors as you type. People who move back and forth between VB and C# notice this, but VB-only developers may not realize that other languages such as C# don’t always give you 100% accurate Intellisense and don’t always give you all of the errors that exist in your code. This is because their Intellisense engines are separate, scaled-down compilers that don’t do full compilation in the background. VB, on the other hand, compiles your entire project from start to finish as Visual Studio sits idle, allowing us to immediately populate the task list with completely accurate errors and allowing us to give you completely accurate Intellisense.
One final note is the recent Channel9 interview with the Group PM of the C#/VB/F# team, Luca Bolognese, where he emphasized how the languages are no longer going to stray off in different directions and will begin to share their similarities. So it looks like the future holds great things!
Intellisense is actually lacking in VB.NET vs C#. Try calling Dispose via intellisense on a class that inherits from disposable but does not directly implement it. It won't show up. There are many other examples that I cannot recall at this time, but basically, VB.NET hides most "advanced" members from intellisense. Hardly productive, and I get the feeling it implies that VB.NET developers are less knowledgeable about such "advanced" members.