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!