.NET Remote Symbol Loading Changes in Visual Studio 2012 and 2013
In this blog post, we will cover the changes we have made in the way we load symbols in the remote debugging experience for .NET languages. This applies to remote debugging for .NET languages and other languages will load symbols locally.
Visual Studio 2010 experience
In Visual Studio 2010, we would look for symbols deployed onto the remote machine that matched the target you are debugging. What this means is that when you wish to debug your app on a remote target, you need to have on the remote target/machine matching symbol files (PDBs) for the version of your app that you are trying to debug.
Many customers told us that it was a pain to have to remember to deploy their (typically large) symbol files to every machine where they wanted to remote debug their code.
Visual Studio 2012 experience
In Visual Studio 2012, the debugger was changed to look for symbols on your local machine instead. Because of this change, you can now maintain all the symbols on your primary machine (instead of finding PDB files deployed onto the remote system).
An exception to this is with server-side compiled ASP.NET. In this case, the matching PDB will be built remotely and Visual Studio will load the symbols from that remote location. If you need to duplicate this behavior for other platforms, we added an exception through the registry to load remote symbols as well. This exception requires the platform to build in a well defined path and for the PDB to be found in the same exact spot it was built. Continue reading further below for details on how to implement this exception in the registry.
Visual Studio 2013 experience
In Visual Studio 2013, you continue to enjoy the same experience as VS 2012. Additionally, we also added support for the rule LoadPdbsNextToModule. This prefix allows the remote matching PDB to be located if they are simply found next to the module being debugged. By using this rule, the matching PDB file no longer has to be in the same exact spot it was built. This rule requires the matching PDB to be specifically stated by the rule.
Visual Studio 2013 Update 2 experience
In Visual Studio 2013 Update 2, we have added a new flag to the remote debugger. If you call the flag /FallbackLoadRemoteManagedPdbs on the remote machine, it will look for the PDB next to the module being debugged after searching the original PDB location. This differs from LoadPdbsNextToModule in that it will do this for every matching module without having to be specifically stated by the rule. You can find more detailed information by looking through the help documentation for msvsmon (msvsmon.exe /?).
Implementing the Registry Exception
Create a new .pkgdef file containing the following.
[$RootKey$\Debugger\RemoteClrPdbNamePatterns] "MyExampleRuleName" = "LoadPdbsNextToModules:[a-z]:\\.*\\My example dynamic compilation directory\\[\x20-\x7E\\]+\.pdb"
MyExampleRuleName = A name for your rule. It must be less than 128 characters and should be unique enough not conflict with any other rule name
LoadPdbsNextToModules = the prefix flag to automatically load the PDB next to the dll
RegEx = This is a regular expression for the location of the path to the PDBs
Then drop this new .pkgdef file into Visual Studio. This can be done in the following 3 ways.
- Manually drop the file into Common7\IDE\Extensions
- Add the .pkgdef to a .vsix for simple deployment. This can be done through the Visual Studio SDK.
Then add a reference to the .pkgdef file as an ‘Asset’ in the ‘Assets’ section of the .vsixmanifest file
<Asset Path=”MyExampleCompany.pkgdef” Type=”Microsoft.VisualStudio.VsPackage” /> - Create an ‘extension.vsixmanifest’ to be dropped along with the .pkgdef file into a Windows Installer (MSI).
Then add a reference to the .pkgdef file as an ‘Asset’ in the ‘Assets’ section of the .vsixmanifest file
<Asset Path=”MyExampleCompany.pkgdef” Type=”Microsoft.VisualStudio.VsPackage” />
In closing
Visual Studio 2012 and 2013 look for symbols on the local machine rather than the remote machine during remote debugging – this is a change from VS2010. If you have any troubles, questions are welcome in the comments and our MSDN forum.
Light
Dark
0 comments