Since I’m still working on a VB.NET I start to understand the language more and more. It feels like working with PHP. There are so many hacks, many things happen without you knowing that it happens.

Consider the following classes defined:

class Foo {}
class Bar : Foo
{
    internal static Foo GetInstance()
    {
        return new Bar();
    }
}

In C# you would have:

Console.WriteLine(Bar.GetInstance() as Bar);

the ‘as’ operator tries to cast foo to an instance of Bar. If that doesn’t succeed it returns null.

The code gets compiled to something like this:

{
    Foo __foo = Bar.GetInstance();
    Console.WriteLine(__foo is Bar ? (Bar)__foo : (Bar)null);
}

Doing a cast:

Console.WriteLine((Bar)Bar.GetInstance());

Throws an exception if we cannot cast. So you need to do a try catch around it.

Those are the casting operators in C#.

VB.NET has a little bit more stuff.

I will list them briefly:

CType(obj, Type), DirectCast(obj, Type), TryCast(obj, Type) and some predefined functions like CBool, CStr, Cint.

DirectCast(obj, Type) is the equivalent of the (Type)obj. No problem. TryCast(obj, Type) is the equivalent of obj as Type. No problem either. The problem arrises when we use CType and or one of those predefined functions.

You’d expect CBool(obj) to result in (you cannot do TryCast on a valuetype, hence the DirectCast) DirectCast(obj, Boolean). But no.

Consider the following code:

Dim boolTest As Object = False
Console.WriteLine(CBool(boolTest))

When compiled it gets converted to this:

Dim boolTest As Object
boolTest = CBool(0)
Console.WriteLine(Conversions.ToBoolean(boolTest))

You can take a look at the Conversions class with Reflector. It’s located in the Microsoft.VisualBasic dll (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.VisualBasic.dll) and the full name is Microsoft.VisualBasic.CompilerServices.Conversions.

CBool should just try a DirectCast in my opinion.

But CType has some more nuisances. We are still using the Foo and Bar classes defined above.

Consider this code:

Dim foo As Foo = Bar.GetInstance()
Console.WriteLine(CType(foo, Bar))

Gets compiled to:

Dim foo As Foo
Console.WriteLine(DirectCast(Bar.GetInstance, Bar))

Great, it uses DirectCast. So if the conversion fails it throws an exception…

Now the catch:

Dim test As Object = String.Empty
Console.WriteLine(CType(test, String))

You’d EXPECT it to do a DirectCast but no, this is what gets emmited:

Dim test As Object
Console.WriteLine(Conversions.ToString(String.Empty))

Again a roundtrip you don’t see…

That’s why I don’t like VB.NET. Too much happens behind the screens.

I know that you can program VB.NET without all of this (use DirectCast and TryCast yourself). But the problem is that all legacy developers use these functions because they don’t know better.

I wish these features where deprecated and only available for projects converted from VB6 code.

There is a difference in operators when a C# developer has to do VB.NET

For example: && vs And.

THEY ARE NOT THE SAME. The && equivalent in VB.NET is AndAlso

If you do this:

Sub Main()
    Dim result = Part1() And Part2()

    Console.ReadLine()
End Sub

Function Part1() As Boolean
    Console.WriteLine("Part 1")
    Return False
End Function

Function Part2() As Boolean
    Console.WriteLine("Part 2")
    Return True
End Function

What do you think it prints?

If And would behave like && in C# it would print

Part 1

But unfortunately BASIC is different (sigh), it prints

Part 1

Part 2

This can be solved by using AndAlso, which is the short circuited version of And.

Because With clutters your code, you get too much indentations and it removes readability. Now I saw code with 4 to 5 times nested With statements. Pure Horror. So my first job was to remove all these statements. But what if you get ambiguous Methods/Properties?

The documentation is clear on that:

However, because members of outer statements are masked inside the inner statements, you must provide a fully qualified object reference in an inner With block to any member of an object in an outer With block.

This means that in an inner with block you cannot access the members of the outer with block with the . qualified name. You need the full qualified name.

So when you need to de-with your code you start from the outside, taking the most outer block first, solving the references, building, removing the next one, and so on…

But you shouldn’t use With statements in the first place.

Just name your variable if you don’t want to enter the fully qualified name for every statement.

Today I was working on a project in VB.NET, which I had to convert to C#.

The problem was that they used late binding, they knew that some properties on objects existed, but they couldn’t be deduced by the compiler since the object’s type was Object.

For Example, let’s say we want to get the workbook of a chart.

A chart resides in a ChartObject (the chart.Parent) and a ChartObject resides in a Worksheet.

So chart.Parent.Parent returns the corresponding worksheet.

Like this:

Option Strict Off

Imports Microsoft.VisualBasic

Public Class TestClass
    Public Sub Test()
        Dim chart As Excel.ChartObject

        Dim workbook = chart.Parent.Parent
    End Sub

End Class

Now of course, if you compile this, it will work since Option Strict is off.

But when you set it on (or port it to C#) it won’t compile, since chart.Parent returns a type of Object. And the compiler cannot find the .Parent property on that Object, so we would need to cast to ChartArea to get the .Parent property appropriately, and then cast this result to an Excel.Worksheet.

Option Strict On

Imports Microsoft.VisualBasic

Public Class TestClass
    Public Sub Test()
        Dim chart As Excel.ChartObject

        Dim workbook As Excel.WorkSheet = CType(CType(chart.Parent, Excel.Worksheet).Parent, Excel.Workbook)
    End Sub

End Class

This will work.

Unfortunately sometimes there are properties you can set, but they don’t appear in your Intellisense, so you can’t get/set that property.

If you are using VB.NET with Option Strict Off this is no problem, but again: with Option Strict On or in C# it IS a problem.

Since the late binding internally uses Reflection I thought might fetch the PropertyInfo for that particular property and set it that way:

Dim propertyInfo As PropertyInfo = GetType(Excel.Chart).GetProperty("ThePropertyYouWant")

propertyInfo.SetValue(someChart, someValue, BindingFlags.SetProperty, Nothing, Nothing, Nothing)

This won’t work either, since the compiler cannot find the PropertyInfo of that property, it just doesn’t exist. You will get a NullReferenceException. You can only set it at runtime.

The solution is:

GetType(Excel.Chart).InvokeMember("ThePropertyYouWant", BindingFlags.SetProperty, Nothing, someChart, New Object() {someValue})

This way you just say to the runtime: set that value on that property, don’t try to read the metadata first!