Can't debug unit tests on VS2015 RC

[huguesv]

VS 2015 22822.1 D14REL
PTVS 2.2 CL1457733_VS2015_22820

Create python app
Add item, unit test

    def test_A(self):
        a = 0
        b = 10
        pass

Put a breakpoint on a = 0.
Debug test

Occasionally, I get this access violation exception (debugger breaks).

But most of the time, it runs without debugging. You don't see the "2nd attach" happening at all. This is worse than with CTP 6 where it would sometimes work as expected (debug and stop at that breakpoint), sometimes get the access violation.

I tried C# and C++ (native) unit test debugging, and haven't had seen any issue yet.

System.AccessViolationException was unhandled
Message: An unhandled exception of type 'System.AccessViolationException' occurred in System.ServiceModel.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

[int19h]

It looks like they have completely reworked the test executor. It is a differently named process now, but the real problem is that it also has a different command line, which doesn't contain the /parentProcessId switch which we used to parse to get back to VS (and it doesn't contain any replacement, either). We'll need to find some other way to communicate with the VS process...

[int19h]

Side note: it looks like we can replace the current double-attach scheme with attaching directly to python.exe if we provide our own ITestExecutorLauncher. We can do so by exporting our own IUpdateTestRunConfiguration via MEF, and replacing the standard launcher with our own.

[zooba]

I'm not sure that particular approach is feasible, but since we define our own test type then we may be able to gain that control by installing a test adapter too (more like VSTestHost than our current adapter). Still won't get us running in-proc, unfortunately, so building new UI is still looking more attractive...

[huguesv]

Pavel, with your fix in progress linked above, how does it behave when multiple instances of VS are running? I would guess there's a race condition if you try to debug tests in multiple VS around the same time, but if that's the only scenario that causes issues, it's better than no debugging at all.

[int19h]

There shouldn't be any race there. The test executor process gets the process ID of the VS instance that launched it, and attaches back to it - same as we did before, except that we're now using a different way to propagate that process ID.

[zooba]

Environment variables are local to the process and its child processes, though there may be a case where we reuse a test executor started from (say) C# that does not see the variable. Though it'll probably crash and restart, thereby picking up our variable. Something to test:

1. Start VS
2. Debug C# test
3. Open Python project
4. Debug Python test

If that works, I don't see anywhere else that may be a problem here. It's much more robust than the previous approach.

[int19h]

Looking at it in debugger, our package gets loaded on VS startup, so we always set that variable before anyone will get a chance to trigger a test run.