Is there a way to debug a VB.NET With clause in Visual Studio?

Sometimes you donโ€™t care about the name of a variable, because it does not go beyond your subclause. In fact, specifying the name will add an extra line of code. You also now have this name that you may encounter, which may add to potential refactoring efforts (if you decide to rename it later). Take a look at the code below:

Dim fileInfo As New FileInfo("filename.txt") With New FileSystemWatcher .Path = fileInfo.DirectoryName .Filter = fileInfo.Name .EnableRaisingEvents = True AddHandler .Changed, AddressOf OnChanged End With 

This is the perfect VB.NET design that looks neat and clean. However, when it comes to debugging and it is assumed that you have set a breakpoint inside the With clause, there is no way to capture this .Path to make sure it is set correctly.

Am I missing something here or is Visual Studio really not providing debugging for .Property syntax inside With statements? I am using 2010.

Obviously there is not much debugging in this code, but there can be many examples of when such an unnamed With approach comes in handy.

BTW called With sentences have the same problem, i.e. if I had to write:

 Dim fsw As New FileSystemWatcher With fsw .Path = fileInfo.DirectoryName .Filter = fileInfo.Name .EnableRaisingEvents = True AddHandler .Changed, AddressOf OnChanged End With 

I still cannot pull out the .Path value, always putting it in the fsw prefix.

The problem grows in size when you insert With sentences into each other.

+4
source share
2 answers

The With statement with an unnamed variable is a serious problem for the debugger, there is no workaround for this. There is simply nothing wrong with a small, named auxiliary variable such as "fsw"; it exists anyway, automatically generated by the compiler. This is not anonymity, simply inexpressible. Like VB$t_ref$L0) , the debugger will not allow you to enter it, since it uses characters that are not allowed in VB.NET identifier names. This is intentional, it ensures that it never comes across the name you used. It also prevents showing in the Autos window.

You have already found a suitable workaround by naming this variable. Debugging from there is simple, just hover over the name of the variable, not the name of the field. And, of course, it works well in all other debugger windows, in particular, the Autos window will spring to life. And feel free to drop the โ€œCโ€ statement in favor of simply writing the full statement, IntelliSense helps make this a less difficult task.

+2
source

The option should be to add these variables to the watchlist instead and view the values โ€‹โ€‹from the viewport.

0
source

All Articles