Engineering in the white spaces
After our first and second investigations into the different way in which the C# and VB compilers handle method overload resolution, this article highlights another oddity of the C# method overload resolution algorithm.
The VB code shown above results in the following method call, which the majority of developers would agree is the most intuitive result given the slightly ambiguous circumstances.
Now translate the above VB code into C#, and ask a C# developer to predict what this program will produce.
Remember that after reading this article, our hypothetical C# developer knows that any method marked with override is not included in the group of methods considered for overload resolution. So he or she might be justified in feeling really confused with the following result.
The reasoning behind this is quite obvious once you've seen it, but it's rather subtle. Just as the C# language specification states, the Derived.DoSomething(long nNewValue) method is not considered for the method resolution because it's marked with override. In fact, Base.DoSomething(long NewValue) is the only member in the group of possible overloads, so unsurprisingly that is the method actually chosen. But of course a derived member overrides that base member, so the derived method is the one executed. The trick here is to remember that the overload resolution process is just one step in the process of deciding which method is executed.