I mean, does the ptvsd page even load up for you?
(if it does, this indicates that web.config at least is okay and has no errors, and the proxy should be there)
Nevermind though, I poked the endpoint and it's there and reporting that everything is a-ok.
I think it's one scenario that we haven't really thought of. The problem is that to attach to Python code, you actually need to be running Python code. But if your request handler immediately terminates (e.g. because some code somewhere throws an exception),
you simply don't get any opportunity to attach...
The proxy could handle this better by faking the debugger protocol for the initial handshake if the actual debugged process is not there yet, and wait for it to appear, then transparently hand it over - then you could attach without anything running on the
server, and run all Python code on the request handling path from start to finish. But this would require making the proxy much smarter than it currently is, so that's a significant change.
In the meantime, here's something that I think might help. You need to find the file on your system at the following path (adjusting as needed):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Python Tools\ptvs_virtualenv_proxy.py
Inside it, there is a line of code that reads:
Immediately after it, insert:
Then re-publish your project. The effect should be that (when deployed in Debug configuration - i.e. when WSGI_SECRET is set in Web.Debug.config), request handling simply won't proceed until you attach the debugger.
The annoying part will be that whenever you want to not have it wait anymore, you'll have to re-publish in Release.