PTVS and Zip files and Find Source.

Jun 25 at 3:48 PM
I am using PTVS with various zipped packages I have an issue with the way that exceptions are being displayed.

For instance I have a 3rd party python package and if I have exception catching enabled, PTVS will report the exceptions that occur in the package. That's okay because I turned the feature on and it's expected.

But if the package is zipped, something is unzipping the package and then trying to find the exception-ing python file. This part fails.

I am prompted with the 'Find Source' dialog and it is viewing inside the zip file and has navigated to the file (the folder path includes the zip file as a folder). But when I try and select the file, I get an error saying "You selected the file 'file[1].py'. Please select a file named ''"

I don't know what is happening with PTVS but the unzipping process seems to create file[1].py if a already exists. But I cannot see the file[1].py and I'm stuck in the Find Source dialog, looking in the zip file contents. My only option is to cancel.

The solution seems to Delete Temporary Internet Files But after a couple of iteration the problems occurs again and I have duplicate files again.

So, is there a better way of using zip files and exceptions?
Jun 25 at 4:56 PM
Our support for .zip/.egg files is limited at the moment. In particular, when handling exceptions, PTVS will not be able to properly determine whether they are handled or unhandled if the handler is in a source file that is zipped:

PTVS itself does not unzip the package when working with it - it reads compressed files directly from the archive. However, when an exception happens, VS pops up its standard "locate the source file" dialog. The Python path of the package does, indeed, include the zip file as if it were a folder, and that's what we report to VS.

That's where it gets tricky; the Open File dialog has support for .zip archives (completely unrelated to PTVS and Python), and treats such paths correctly. However, in order to handle them, it transparently extracts the archive somewhere in your temp file folder, so that when the file inside is selected, it can hand the path to that extracted file back to whatever opened it (in this case, VS+PTVS). It seems that it uses some scheme to avoid filename duplication there that produces "file[1].py"; on the other hand, VS debugger requires the source file name to match to use that code for debugging.

It's unfortunate that this is working in such a strange way as a result, making it confusing as to what is actually supported. I'll see what can be done about it, at least to make it less confusing (ideally, of course, we just want to support .zip/.egg everywhere and be done with it, but this is a fairly big feature, so it is not happening this late for 2.1).

For the time being, the suggested workaround is to unzip the file yourself, and when VS pops up that dialog asking for sources, navigate to where you unzipped it to.
Jun 25 at 5:48 PM
Thanks for replying.

Your suggestion works as a workaround but I have just noticed that I too am suffering from the handled exceptions being reported.
Jun 25 at 5:54 PM
The short-term fix will likely be #2337, which will provide an option treat all exceptions as handled so long as they remain within .zip boundaries, enabled by default.

This is not perfect, since it means that if the exception is actually unhandled, it will be reported once it crosses that boundary and leaves the .zip, so you will lose the context where it originated from. On the other hand, most exceptions like that are actually handled, and when they're not, it's usually a third-party package and you only care about your part of the call stack.