0

I have a source indexed PDB, but Visual Studio does not attempt to download the appropriate source when debugging (verified using Fiddler), even though it does create the proper directory structure in the symbol cache (i.e. under the src/ subdirectory). To troubleshoot the issue I used srctool.exe:

srctool -x myfile.pdb

However, this just causes the URLs to be listed; it does not try to download them:

https://myurl.com/bitbucket/projects/BLAH/repos/MyRepo/browse/Src/SomeDir/SomeFile.cs?at=05bff5155beece6c7e6acde97f7aeefc7b65e2cf&raw
...
myfile.pdb: 20 source files were extracted.

The output of pdbstr is the following:

SRCSRV: ini ------------------------------------------------    
VERSION=2    
SRCSRV: variables ------------------------------------------
RAWURL=https://myurl.com/bitbucket/projects/BLAH/repos/MyRepo/browse/%var2%?at=05bff5155beece6c7e6acde97f7aeefc7b65e2cf&raw    
SRCSRVVERCTRL=https    
SRCSRVTRG=%RAWURL%    
SRCSRV: source files ---------------------------------------   
E:\AnotherDir\work\9f49bd3ba978a6f5\Main\Src\SomeDir\SomeFile*Src/SomeDir/SomeFile
...
SRCSRV: end ------------------------------------------------

If anyone could point me in the right direction to figure out what is going on, I would greatly appreciate it.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
Sally Richter
  • 271
  • 2
  • 9

1 Answers1

1

SRCSRV doesn't work with query URLs (see this issue and this issue).

If you're using a public Bitbucket repository, you can use a pattern like this acceptance test; that is,

RAWURL=https://bitbucket.org/BLAH/MyRepro/raw/05bff5155beece6c7e6acde97f7aeefc7b65e2cf/%var2%

I'm not sure if private Bitbucket installs support this kind of syntax, though. Check out this issue for more info - from my brief reading, it appears that they support raw files without query strings, but it's not clear whether you can specify the commit hash without a query string.

From comments on the other issues, it looks like a common workaround (for private Bitbucket installs) is to set up url rewriting or a small passthrough web service that can take SRCSRV-friendly URLs.

Regarding srctool, I believe its output is a bit misleading but technically correct. It does behave the same for correctly-source-indexed PDBs that VS can download.

PDBs mapped this way specify SRCSRVTRG (the target) but not SRCSRVCMD (the download command). SRCSRV is supposed to check the target and - if the file is not there - it will execute the download command:

Next, it expands the SRCSRVTRG variable using VAR1 to VARn. If the file is already in this location, it returns the location to the caller.

Otherwise, it expands the SRCSRVCMD variable to build the command needed to retrieve the file from source control and copy it to the target location. Finally, it executes this command.

In this case, the targets are the actual HTTPS URLs. Technically, the file is already "at" that location, so SRCSRV just returns the file location, and srctool reports that it's already there (with a misleading "extracted" message).

When VS does actually download the file, it will store it locally under its symbols cache, but that is a further step in this process; storing it there is not strictly necessary.

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
  • Yeah, my issue indeed was the query URL, as VS tries to create a directory/filename based on the URL, and a question mark is not a valid character for those. The actual *retrieval* of the file turns out to not be a problem, though; it tries to created the directory/file first, and when that fails it quits. Got around the problem by setting up a simple client redirect from a "valid" URL to the one with the query string, as VS creates the directory/filename based on the initial URL, not the redirected one. – Sally Richter Sep 07 '16 at 16:30