vb.net overload resolution fails with "multiple members with this name exist in class"

Question

Recently, I received a bug report from a VB.Net user about a strange overload resolution failure when upgrading to a newer version of OpenTK: Error 1 'Uniform3' is ambiguous because multiple kinds of members with this name exist in class 'OpenTK.Graphics.OpenGL.GL'

Why is this strange? Because the overloads in question are identical between the old and the newer versions of the library!

Some testing later, I managed to isolate the problem in a small test case:

// C# library - this one works
namespace Test
{
    public partial class GL
    {
        public static void Foo(float bar) { }
    }

    public partial class GL
    {
        public static void Foo(int bar) { }
        public static void Foo(ref int bar) { }
    }
}

The above code can be consumed by VB.Net without an issue. However, if I re-order the two partial classes:

// C# library - this one fails
namespace Test
{
    public partial class GL
    {
        public static void Foo(int bar) { }
        public static void Foo(ref int bar) { }
    }

    public partial class GL
    {
        public static void Foo(float bar) { }
    }
}

I get a failure!

The VB.Net code looks like this:

REM VB.Net code that consumes the C# library
Module Module1

Sub Main()
    Test.GL.Foo(0)
End Sub

End Module

What is going on here?! Why does the order of the two partial classes matter?

More importantly, is there a better solution than reordering the C# code files and hope the compiler consumes them one way but not the other? (For instance, is there some attribute I can apply to remove one of the overloads from consideration during overload resolution in VB.Net?)

Answer 1

I worked around this issue by changing the order in which the overloads appear inside the compiled binary. This is awful in many different ways, but it appears to work well enough for now.