1

I was running a unit-test in Visual Studio today using FakeItEasy. I was offline and found the following symbol-loading to be happening and taking a long time:

FakeItEasy symbol loading

My question is, where does the path Z:\Builds\work\... come from and why is Visual Studio trying to load symbols from that path. Could it be that this path corresponds to the CI that the binaries were built on? If so, is it a thing that the maintainer of the library should fix, or something that I must locally configure? I am using the FakeItEasy 1.25.2 binaries that I fetched via NuGet.

I am aware of the fact that you can disable symbol loading (e.g. see this question), but actually I want the symbols to be loaded if possible.

Alexander Pacha
  • 9,187
  • 3
  • 68
  • 108

2 Answers2

1

Yes, Z:\Builds\work\… is the path from which TeamCity builds FakeItEasy.

I'm not a big symbol user, so am not sure what you want "fixed". Why are you loading the symbols, and what behaviour would you expect in this case? If we push the symbols to SymbolSource.org you'd still need to be online to access them, no?

Can you give an example of a NuGet package that behaves how you'd like? How does it behave in your situation?

Blair Conrad
  • 233,004
  • 25
  • 132
  • 111
  • If the symbols were shipped with the library, then I would expect to be able to debug into the library. I would need to be online only while downloading the package with NuGet, but not while debugging my application. MvvmLight ships with the pdb-files. In my situation Visual Studio just blocks for quite a while because I do have a Z: drive on my PC and VS tries to load from the symbols from there (and does not find them). – Alexander Pacha Sep 03 '15 at 13:22
  • 2
    Ah, I could take a gander at MvvmLight, but lean toward what appears to be standard recommendation for publishing symbols: [Creating and Publishing a Symbol Package](https://docs.nuget.org/create/creating-and-publishing-a-symbol-package). Maybe it's more of a suggestion? – Blair Conrad Sep 03 '15 at 13:29
  • I guess pushing the symbols to symbolsource.org would be the best way to go. – Alexander Pacha Sep 03 '15 at 15:11
1

PDBs can be built for debug configuration and release configuration and it's typically a good idea to keep them for debugging purposes. FakeItEasy or any other DLL or EXE, contains the full path to the PDB file where it was located during compile time. If that path is part in a DLL (or EXE), Visual Studio will try to load symbols from there.

To see that information, get DebugDir and run debugdir <path to>\FakeItEasy.dll. Or, in any hex editor, search for pdb.

You'll find the full path of the PDB along with some other information. Since it wasn't you who built the DLL, the PDB is not present on your disk and you'd need to download it from a symbol server.

The Sourforge clone of DebugDir contains supports a command line parameter clean which can remove debug information. If you want to get rid of Visual Studio accessing the non-existing Z: drive, you can remove the path to the PDB file.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222