Visual Studio Test Adapter (NUnit 2) Crashes, Will Not Run or Debug Tests

[CharliePoole]

@DarthGregarious commented on Fri Mar 10 2017

I tried to run tests in Visual Studio 2015 for the first time since the latest adapter extension update. In one of my solutions, it just crashes. I am using NUnit 2.6.4 with the latest Visual Studio adapter and targeting .NET 4.5.

When debugging a test, it starts to run, but it stops abruptly when it says "loading symbols for Mono.Cecil..."

I found an older issue that suggested adding an ".addins" file to the output directory, so I tried that but it didn't help.

Whether "Running" or "Debugging" a test, "Test Output" includes:
Dependent Assembly of C:\projects...Tests.dll not found. Can be ignored if not a NUnit project.

Debug Output:

---

@DarthGregarious commented on Fri Mar 10 2017

I should add that I tried a smaller solution, and it works just fine - running and debugging. It still has the "Cannot find or open the PDB file." errors but it does not have the "Dependent Assembly..." warning. I also used the separate NUnit desktop program with no problems.

---

@DarthGregarious commented on Fri Mar 10 2017

NUnit VS Adapter 2.1.0.7 executing tests is started Loading tests from C:\projects\...Tests.dll Dependent Assembly of C:\projects\...Tests.dll not found. Can be ignored if not a NUnit project. NUnit VS Adapter 2.1.0.7 executing tests is finished

[OsirisTerje]

@DarthGregarious Which framework version are you targeting ? Can you please check with the nuget or vsix package enclosed with issue #142 , so that we can see if it is related to Mono.Cecil versions.

[OsirisTerje]

The "Cannot find or open PDB file" issue is the same as we had in the NUnit3 adaper, nunit/nunit3-vs-adapter#276, so I created a corresponding here #144 , and has done the same fix, pushing soon.
This issue can be the same, but the exception points to the mono.cecil pdbs, should they have been included too?

[andkvo]

@OsirisTerje I downloaded the VSIX from #142 and tried to debug a test in Visual Studio 2015. It did the same thing. A pile of "Mono.Cecil.AssemblyResolutionException" (looks like one per test) culminating in the abrupt crash.

Let me know if you need me to try anything else.

[OsirisTerje]

Which framework are you targeting?
Have you checked that your own dll's have corresponding pdb files ?
When it starts the test run, it writes out the version number, you should see 2.1.0.8, did you see that, or 2.1.0.7 ?

[andkvo]

It says 2.1.0.8 now.

[andkvo]

Debug output says "symbols loaded" for all of my DLLs.

[andkvo]

I'm currently targeting .NET 4.5 but based on other issues I read, I tried adjusting it all the way up to 4.6.1 without success.

[OsirisTerje]

You're having something "interesting" in your code base, it is worthwhile to try to get to the root of this. My standard repro, which checks mainly that it works on 3.5, and 4.6, works as it should. Do you have any possibility to extract a small repro of this issue and upload it? There might be something you do that triggers this behaviour and I am very curious about what that can be.

[initram]

I think this could be the same issue that I reported in #147. I got the same error message: dependant assembly not found.

[andkvo]

You might be on to something there. I removed everything except a very simple Assert(true, Is.True)` test from my test project and I was able to debug the test. I added my base "UnitTests" class back and inherited from that, and the NUnit Adapter crashed again. The base class is not in another DLL though.

The base class has some set up code. When it is commented out, debugging works. When it is not, it crashes. I am going to keep working through line-by-line until I can isolate the problem.

Thanks for the tip!

[initram]

What I did was to download the source of the adapter to build it and get pdb files. With that you can debug the unit test and set break on all exceptions (remember to find and uncheck "only my code" debug setting). With this you can step through the adapter code when it fails.

[andkvo]

OK, I'll give that a shot.

I found that the line that's killing the adapter is coming from another DLL: our proprietary ORM library. I know it does all kinds of assembly loading, so it could be something in there causing a problem...

[andkvo]

@OsirisTerje I think this project reproduces the problem. Git history of attempting to reproduce is included.

break-nunit-adapter.zip

[andkvo]

The basic setup:

1. A "main" test library (the one you're trying to debug). At least one test extends a base class from the secondary test library (see below).
2. A secondary test library (contains a base class for one of the tests in main that extends a base class in the precompiled shared test library, below)
3. A precompiled shared test library (contains an abstract base class for one of the tests in the secondary library)