One of the things we have been working on recently was publishing sources of VisualBasic runtime library. I am very excited to announce that the sources of VB runtime (Microsoft.VisualBasic.dll) are publicly available now!  This is a part of a more general work on making .Net Framework sources available to public ( http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx ). The most important result of this is that developers can see and debug through VB runtime code.

There is a very detailed description on how to set up VS debugger so that it could use framework sources (that includes VB runtime too). http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx  . The article also describes possible issues and workarounds. For most cases everything should work fine, but in case if you have problems, you can refer to this article.

 

Let’s see some examples how this functionality can be used.

Debugging without runtime sources (normal case) .

I have created a simple VB app with a latebound call and then I have started a debugging session and stopped inside the function. Normally VS tries not to bother user with details of such calls and in the call stack it simply says “[External Code]”.

Disabling “Just My code”.

Next step is disabling “Just My code” in debug options so that you could see calls that are not part of your code.

After disabling “Just My code” in debug options, you will notice that were couple calls performed before we reached the target function. Indeed since compiler does not know at compile time what function will be called it delegates the call to the latebound call support in the runtime library. What we see on the stack in between our functions is the code in VB runtime library. At this point these stack frames are grayed out and pretty much useless as VS does not have sources that correspond to these frames. Double clicking causes this message:

Configre source location information

Now, since the sources of Microsoft.VisualBasic are now published we can tell VS where to get them. For that we will use source server support in VS.
(note that for this to work you will need to make sure you have installed the following QFE Visual Studio 2008 QFE as this hotfix updates a debugger component that fetches the source files).

1.            In Visual Studio 2008 and select Tools -> Options -> Debugging
2.            On the “General” Tab
             a.            Uncheck “Just My Code”
             b.            Check “Enable Enable Source Server Support”

Here we will tell VS where the sources are located and where to cache them locally. The caching is important when sources are accessed from a remote server as it is much faster to get sources from a local cache.

On the “Symbols” tab
a.            Click the “new” icon and enter: http://referencesource.microsoft.com/symbols
b.            Check “Search the above locations only when symbols are loaded manually”
c.             Enter a path in the textbox in which to cache symbols.  Make sure this is somewhere that your user account has permissions to write to (for example d:symbols)
d.            Hit OK

Right click the first runtime frame and select “LoadSymbols”. Wait for symbols to load (may take a moment or two and the first time it will also ask to agree with EULA). Doubleclick the first runtime frame… What a difference!!! We can see the runtime code.
(at thirst it may take some time as VS is fetching sources from a remote server, but once they are in the cache it will not do it again)

Setting breakponts inside VB runtime.

Even more – We can F11 through the runtime code and set breakpoints. If you are very curious, you can set a break point at the beginning of the latebound call helper and restart your project. Once you hit the breakpoint you can F11 through latebinder code to see how it was implemented.

Note that there is one caveat – while the sources on the server contain the same code as original sources they are not “exactly” the same. They have small changes such as copyright banners at the end etc. As a result VS complains about source difference.

This can be safely dismissed by right clicking the breakpoint, opening “Location” menu and selecting “Allow source file to be different from the original location”. Tere is a way to do this globally, but I would not recommend this since this would affect all you projects.

Also to make sure that symbols are loaded before execution gets to the breakpoint, you will need to disable “manual only” loading for symbols.

This will cause all the symbols to be loaded on demand and that includes many .NET FX libraries so this may take some time when you launch debugging session.

This will cause all the symbols to be loaded on demand and that includes many .NET FX libraries so this may take some time when you launch debugging session. After symbols are loaded you should be able to hit the breakpoint in the runtime.

What is inside MsgBox

Another interesting scenario that should work now is F11 into VB runtime functions. One that I use the most seems to be MsgBox so let’s take a look what is inside.
In a hello world project we can set breakpoint on the call to MsgBox.

When breakpoint is hit just do F11. Wow!! Now we are inside MsgBox and can step through it to see how it works.

Known issues, FAQ

1)      Accessing remote symbols is not very fast. This causes delays in VS when sources are fetched. Even with caching enabled in some scenarios VS checks whether information is current. You may get around this by going to Tools -> Options -> Debugging -> Symbols configuration and unchecking  “Search the above locations when symbols are loaded manually” checkbox and then debug you project. It may take some time to load all sources (including various .Net libraries) in this configuration (often more than 50Mb will be loaded). After VS finished loading, go back to Tools -> Options -> Debugging -> Symbols and check the “Search the above locations…” checkbox and hit OK. This will prevent the debugger from connecting to the server when you do not want it.

2)      Sometimes you may notice that some variables or methods are not available. The reason for this is that you are using Retail/Optimized version. One result of the retail optimizations is that certain information is not available or “inlined”. You will still have the source information, but you may not be able to access the data or set breakpoints. For the most part however everything should be normal.

3)      Will this work with VB Express?
No. This functionality relies on some VisualStudio components that Express versions do not have.

– Vladimir, VisualBasic team