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!

Can be a hassle, that’s why I’m writing this post for you:

First of all some prerequisites:

• VMware Workstation 7 (6.5 probably will be the same)
• A VM, XP / Vista / 7, whatever you want
• Visual Studio 2008 SP1

Second of all: VMware can be a little cryptic with it’s error messages so stay calm!

We start by having our sample application we want to run on the VM:

<screenshot>

Next we click the wrench tool on the VMware toolbar in Visual Studio:

This opens the following dialog:

For your convenience I highlighted the settings you need to change.

The following order is not the order in the window, but the order that seems the most understandable in my opinion:

Virtual Machine: The VM you want to debug into, just select a suitable vmx.

Remote Debug Monitor Path: The path to Remote Debugger folder on the host computer NOT on the guest! So for 32-bit debugging that would be:

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe

Replace x86 with x64 if you require 64-bit debugging.

Shared Folders: This one is not used

Guest Command: The command to be executed on the guest to start the application. This one was quite the hassle for me. If you leave it on the standard it will result in the following (cryptic) error:

So instead of leaving it on default you enter this;

\\vmware-host\Shared Folders\test\application.exe

Please replace application.exe to the name of your executable!

The last item, Guest Logon Credentials, is the easiest. This should be the username and password you use to log in to the VM.

Next up is setting the shared folder between the guest and the host.

While I tried this with the Shared Folder Item in the window we just filled in, I just can’t seem to get it to work. So I bypassed this.

Go to the settings of the VM (in VMware Workstation –> VM –> Settings (CTRL+D)):

On the second tab, you take shared folders, and click add (as pointed on the picture).

On the wizard I would suggest opening the shared folder in the debug folder of your application and name the shared folder ‘test’

Enable the share in the following window, and make it read-write.

Now we can start the debugging from Visual Studio. The application will then be started through the shared folder we just created.