This project has moved and is read-only. For the latest updates, please go here.

Remote debugging - how to fetch source code not already on local host

Mar 14, 2014 at 10:57 PM
Edited Mar 14, 2014 at 11:01 PM
Hi there,

Apologies if I'm missing some existing options here - I did spend quite a while searching! Anyway, if I connect to a remote ptvsd-running script and want to see the source files the debugger steps through, as far as I can see I've got to ensure they're in one of the solution properties / Debug Source Files directories...?

I'd love to be able to set a flag to have ptvsd transfer the files to the debugger side so I know they're 100% in sync... is there any feature like that?

Failing that it'd be nice to intercept the debugger side request for specific file paths and dynamically fetch/provide content. I have a proprietary database storing source code, so I need to programmatically retrieve specific files using python or C++ APIs - there're too many files to download everything. I imagine I'd need to save scripts to e.g. C:\TEMP, then give PTVS/VS the local path, but an in-memory file content handover would suit even better. Any tips on where I could surgically inject such source file content? For files running locally,'s Module::init and get_code_filename(code) work fine, but for remote sessions I think ptvsd communicates directly to devenv.exe, and there's nowhere in the PTVS python modules I could intercept this? If that's the case, I may be looking at writing my first VS plugin/extension, but I'm wondering about a couple promising leads that might avoid the need for that...

I've read about the "srcsrv protocol" - sounds like it might be a clean way to ask VS to contact a separate program I could write that gets the content, but I can only find mention of a couple Microsoft programs that implement the protocol, and no actual protocol documentation. I tried running a TCP server and giving the URL to VS / Debug menu / Options and Settings / Symbols / Symbol file (.pdb) locations (even though I just want to server .py files not .pdbs), but PTVS didn't connect to it at all while debugging my python script, even when right-clicking on the Call Stack for "Go To Source Code" I just get "Source Not Available / Frame not in module" etc..

Another option might be using a CVS plugin, as we have some source in CVS and might be able to commit others somewhere inoffensive to make them visible.

Ok - apologies if that's an overwhelming amount... just thought I'd document where I'd got to. Tips on any of the above greatly appreciated.

Mar 14, 2014 at 11:05 PM
We don't currently have this feature, unfortunately. So if you want to debug remotely, you need to have the local copy of the same code. It doesn't necessarily have to be registered in solution properties or be in a project - you can just open the file with the same name and set a breakpoint in it. The only thing to watch out for is if you have your own packages and want to debug modules in them - in this case you need to recreate the same package structure as on the server (i.e. if remote machine has /somedir/foo/, and foo is a package because it contains, then your local filesystem should have something like C:\Temp\foo\, and C:\Temp\foo should also contain

Symbol files are not used at all by the Python debugger, so none of those options are going to do anything useful for you.

VS itself does have the notion of downloadable scripts that are not associated with on-disk files, and we could certainly implement this - there's no need for a separate server in that case, ptvsd itself would serve the source code, it just needs the corresponding commands added to it, and for the VS side of the debugger to use them. We do in fact already have this feature implemented for NTVS, and so know what VS APIs would be involved here - it's just a matter of actually sitting down and doing this.

It seems that we don't have a feature request open for this yet - feel free to create one in the tracker!
Mar 14, 2014 at 11:19 PM
Edited Mar 14, 2014 at 11:27 PM
Hi pminaev,

Thank you for your lightning-quick and very insightful reply. Great to hear that VS supports downloadable scripts, and it's working for NTVS. I'll add a request in the tracker then! (Update - added here:

Thanks again,