Reflection that works in C# but not VB?

[balabaster]

Why does this work in C#

    class test
    {
        public double Value
        {
            get;
            set;
        }

        public test(double newVal){
            Value = newVal;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            object a = new test(123.45);
            Type dynType = Type.GetType("ConsoleApplication29.test");
            System.Reflection.PropertyInfo dynProperty = dynType.GetProperty("Value");
            double val = (double)dynProperty.GetValue(a,
                                                      System.Reflection.BindingFlags.GetProperty,
                                                      null,
                                                      null,
                                                      null);
            Console.WriteLine(val);
            Console.ReadLine();
        }
    }

But the direct equivalent in VB does not?

    Class Test

        Private _Value As Double

        Public Property Value() As Double
            Get
                Return _Value
            End Get
            Set(ByVal value As Double)
                _Value = value
            End Set
        End Property

        Public Sub New(ByVal Value As Double)
            _Value = Value
        End Sub

    End Class

    Sub Main()

        Dim a As Object = New Test(123.45)
        Dim dynType As Type = Type.GetType("ConsoleApplication28.Test2")
        Dim dynProperty As System.Reflection.PropertyInfo = dynType.GetProperty("Value")
        Dim val As Double = dynProperty.GetValue(a, _
                                                 System.Reflection.BindingFlags.GetProperty, _
                                                 Nothing, _
                                                 Nothing, _
                                                 Nothing)
        Console.WriteLine(val)
        Console.ReadLine()

    End Sub

So much for the two .NET languages doing the same thing... do you think this is a bug?

It fails in VB at the line:
Dim dynType As Type = Type.GetType("C onsoleApplicati on28.Test2")

Which returns nothing to dynType, but in C# it actually returns a type instance!

I'd like not to have to write a C# assembly for the sole purpose of allowing this function in my VB application...

Anyone got any ideas how to work around this?

[balabaster]

No worries, figured it out...

I had my class specified inside a module... and C# explicitly adds the "using System;" clause but VB does not explicitly add the "imports System" clause.

So fixing those two things fixed it...

[Plater]

How did the missing System namespace reference affect things? Shouldn't there have been a compile error?

[balabaster]

How did the missing System namespace reference affect things? Shouldn't there have been a compile error?

You might think...now I'm not exactly sure what the original problem was, I just noted that after some tinkering, it worked. One of the things I did was to add the imports, as I noted that in C# the using line is added by the IDE when you create the project, but in VB the imports line is not, so it was one of the things I added in the course of my investigation.

All other things remaining equal, the code works in both platforms so I was wondering if there's some underlying bug not in the IDE or the compiler, but in the application template (when you create the new application).

I noted that a lot of people came across this issue and most never found the solution so I knew it wasn't just my code that was the problem - and it just didn't make sense to me that Type.GetType("M yClass") would work in C# and not in VB as the two languages are supposed to only differ syntactically, not fundamentally, so I knew there had to be a solution.

I wonder if in VB it may be that the basic GetType() causes some ambiguity. GetType() doesn't have any overloads that accept a string as an argument, but System.Type.Get Type() does. So maybe there's some confusion during the compilation of the code. I'm the furthest thing from the best person to try and pin down what the underlying cause of the issue is in this kind of problem. All I know is that explicitly specifying System.Type.Get Type() instead of just using Type.GetType() OR adding the imports line into the beginning of the code document appears to alleviate it.

Now that I've found a workaround, I've gone onto other tasks - I may come back and further investigate this later to see if I can figure it out in detail.