Fails to resolve assembly for base type of TestFixture if placed in a different dll

[initram]

We have a set of classes that are used as base classes for several TestFixtures in many different projects, so they have been placed in their own project and compile to a separate dll (that is placed next to the assembly containing our TestFixture).

When I try to run my unit tests Mono.Cecil fails to load the assembly containing the base class. After debugging the issue it seems that the working directory is not set correctly when trying to resolve the base type of a TestFixture class. I managed to fix my issue by setting the working directory before trying to resolve a base class.

I Changed NavigationDataProvider.cs:56 from typeDef = typeDef.BaseType.Resolve(); to var tmp = Directory.GetCurrentDirectory(); Directory.SetCurrentDirectory(Path.GetDirectoryName(typeDef.Module.FullyQualifiedName)); typeDef = typeDef.BaseType.Resolve(); Directory.SetCurrentDirectory(tmp); // be a good citizen and reset path to what it was before.

I do not really like this way of solving the problem, but I do not know the codebase well enough to come up with a proper fix for this.

If you want me to create a pull request with my changes or create a reproduction solution, then let me know.

[CharliePoole]

1. What version of the adapter are you using?

2. Where is the base fixture assembly WRT the original test assembly?

3. Is the problem only with locating the source code (as your change would suggest) or is the test not found in discovery and/or execution? To put it differently, exactly what symptoms do you see.

[initram]

I was using latest extension available for vs2017. But was also seeing the issue when building from source (master)

The two assemblies are side by side in the output directory of the test assembly project.

I could see the tests in the test explorer but was unable to run them. When trying to run the test the output was that it could not load my test assembly due to missing dependency.

[CharliePoole]

Just to confirm: you are using the NUnit (2) VS Adapter and not the NUnit 3 VS Adapter, right?

[initram]

That is correct and also the latest nunit 2 release to go with it.

[OsirisTerje]

See comment on #143 , contains a zip file with nuget and vsix with a beta fix

[initram]

Your version solves my issue. I used the VSIX. Thank you! When can I expect this as part of a normal release?

[OsirisTerje]

I am a bit uncertain. I'm waiting for @CharliePoole's answer to my last comment in #143. It will probably be in 2.2, but it could also be out on a beta-feed. The version number will be above the one you have now, so it will be upgrade-able. The same applies for the nuget package.

[CharliePoole]

@OsirisTerje I checked #143 but didn't see any questions for me to answer.

[initram]

When will you release 2.2? I just had to help a fellow developer getting the custom build from the zip you provided to be able to run our unit tests. It has been almost a year... I do not understand what is holding back a release.

[OsirisTerje]

Sorry for being unclear. We try to not release updates to the 2.X series, instead see what prevents people from moving to NUnit3. Are there any particular things that prevents this?

In itself this fix do deserve a new release, but it would be interesting to hear what is your upgrade blocker.

[OsirisTerje]

I'm closing the issue, as the PR is merged to master.

[OsirisTerje]

@initram The pre-release package for the 2.2 adapter is now available on https://www.myget.org/feed/nunit/package/nuget/NUnitTestAdapter If you could check it out, it would be awesome.

[initram]

Wow, a blast from the past...

We have since migrated to NUnit 3 and no longer have this issue. But good luck with your release.

[OsirisTerje]

@initram Good to hear that you have migrated! That is what we want to hear :-)