Why does this work?

[Scott M.]

You assert that this behaviour is 'correct' without any supporting
argument (other than that it seems sensible to you).

Perhaps you would like to refer us all to your MS reference for this
single exception to the standard name resolution rules in VB. Or some
other case where VB similarly ignores the standard rules without any
warning.

I'm sorry, did you provide a MS reference to the "standard name resolutions
rules for VB .NET"? It seems to me that you simply made an assertion of the
way naming works without any reference to support your statement as well.

 

[Herfried K. Wagner [MVP]]

No. The difference between what the code is doing and what the compiler is
doing is the reason for the warning.

Exactly. This is especially important if the shared member is accessed for
an object returned by an expression, which may change the application's
state, but the expression gets removed by the compiler:

\\\
Dim c As Color = Foo.DoSomething().AliceBlue
///

 

[James Hahn]

Well, how about
http://msdn.microsoft.com/en-us/library/aa711879(VS.71).aspx
http://msdn.microsoft.com/en-us/library/aa711882(VS.71).aspx

 

[Family Tree Mike]

This note at the bottom of the second reference confuses me regarding the
color instance versus color class name:

Note An implication of this resolution process is that type members do not
shadow namespaces or types when resolving namespace or type names.

 

[Bob Altman]

I'll be at PDC (the Microsoft Professional Developer's Conference) this
week. I'm going to see if I can get any insight from any of the MS
developers hanging out in the lounge.

Bob

Getting back to the original question, I talked to a VB compiler guy at PDC
(I don't remember his name, but I know I've read his blog) and he says that
the lack of a warning in this case is a bug that should be reported to MS
Connect, which I will do.

Bob (the now infamous OP)