Why is IntelliSense support for C # missing compared to VB.NET?

For me, development for the Java ecosystem has paid bills for years. However, for several years now I have been working mainly in the .Net space. My initial transition to the .Net world was to write and maintain VB.Net code. VS provided almost all the nice intellisense support that I expected after several years of working with Eclipse / Java combos. In the end, my employer decided to do a new development in C #. My initial impression of Intellisense support for C # was less than stellar. From time to time, it seems that VS does not have a background compiler for C #, but sometimes it does something clever, indicating that there is some background processing there, but not enough to really improve performance in meaningful ways. Is there a reasonable technical reason for this inconsistency regarding intellisense support between the two languages?

+6
visual-studio intellisense
source share
1 answer

Some time has passed between C # and VB. VB generates a lot of code for you. For example, pressing the enter button after the β€œIf” statement is completed will automatically add β€œThen” at the end of this line if you disable it and close it with the β€œEnd If” part. In C #, you need to add those that start and close {} curly braces.

VB had a background build long before C #. In fact, this was one of the main attractive factors for using ReSharper, which provided such functionality. However, with VS 2008 / .NET 3.5 SP1, everything has changed. You can read Scott Goog's post about what is here , but I will insert the appropriate part:

"The C # code editor now identifies and displays red errors with errors for many semantic code problems that previously needed explicit compilation to identify. For example, if you try to declare and use an unknown type in C # code-editor today you will not see a compile error, until you build, now with SP1 you will see live red error errors immediately (no explicit compiler required).

Using CodeRush or ReSharper definitely enhances the experience of auto-filling general statements that would make the VB developer feel like a smooth transition has taken place.

This does not completely address technical issues, but the development teams are different and do not necessarily do the same. In other words, there is hardly a general approach. An excerpt from this blog , the technical manager of the VB team, supports this:

Background Compilation is in VB, which gives you a full set of errors as you type. People who move between VB and C # notice this, but VB-only developers may not understand that other languages ​​like C # do not always give you 100% accurate Intellisense and do not always give you all the errors that exist in your code. This is because their Intellisense engines are separate, shorthand compilers that do not perform full compilation into the background. VB, on the other hand, compiles the entire project from get started with Visual Studio inactive, which allows us to immediately fill out the task list with completely accurate errors and give you perfectly accurate Intellisense.

One final note: a recent Channel9 interview with a PM group from the C # / VB / F # team, Luca Bolognese, where he emphasized that languages ​​will no longer deviate in different directions and begin to share their similarities. So it looks like the future holds big things!

+14
source share

All Articles