Setting PrivateBinPath and ApplicationBase with VS Adapter

[Mkinnari]

Hi,

I'd like to use a particular development structure for some upcoming projects, but I'm running into difficulty in resolving assembly references from my test assemblies to my application assemblies. I want unit testing to work consistently between the VS test adapter and the console runner. The cleanest way of making this work (that I can see) would be to have a custom PrivateBinPath and ApplicationBase set when running tests through the VS Adapter.

Lets say I have a solution with two dll projects, "Application" and "Tests". The tests.dll contains the unit tests for the code in application.dll. I want to have the output for the projects in my solution set as follows:

C:\SolutionDir\output\Debug\Program\application.dll

C:\SolutionDir\output\Debug\Test\tests.dll

The Tests project references the Application project, but sets copy local to false. The tests.dll needs to be able to resolve the reference to the application.dll. If I use an nunit project file, I can set something like appbase="C:\SolutionDir", and binpath="output\Debug\Test;output\Debug\Program". When I run that project file in the console runner, the assembly resolves correctly. In the VS Adapter, the reference doesn't resolve. I poked into the source code for nunit and the test adapter, and I didn't see any place where it would have the option to load any configuration information like that, when running through the VS adapter.

Since the Program folder isn't a subfolder of the Test folder, I can't use a config file to set a <probing privatePath="..."\>. It doesn't look like there's a way to set the System.AppDomainSetup.ApplicationBase to a higher level folder in the config file to allow that kind of probing path to work. I can make the probing path with the config file work by nesting the Program folder inside the Test folder (rather than in parallel), or even creating an NTFS junction point to make it appear that way, but those are ugly hacks I'd really like to avoid... I don't have strongly named assemblies, so a codebase wouldn't work either.

The nunit engine has settings capable of making it work the way I want, I just can't access them when using the VS adapter... Ideally I could specify these in a .runsettings file, but nunit isn't looking at it...

[Charlie Poole]

There's a general problem with getting settings like this honored by
the adapter. Put simply, we just don't have any established way to do
it. A few key settings are taken from the registry, but that's really
only useful when you _always_ want things to work the same way on a
given machine.

RunSettings is not very convenient to use AFAIC but it's really the
only standard way we have to apply special settings on a run-by-run
basis. I would be open to an issue that proposes a specific list of
settings we should honor in the RunSettings file. Basically, someone
could take a look at the console command line, and pick out those
things that apply to execution under the VS adapter. We would define
the particular syntax to use for each in the RunSettings file and
implement it, at least for the NUnit3 adapter.

> --
> You received this message because you are subscribed to the Google Groups
> "NUnit-Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nunit-discus...@googlegroups.com.
> To post to this group, send email to nunit-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/nunit-discuss.
> For more options, visit https://groups.google.com/d/optout.

[Mkinnari]

Done. I filed this as an issue at https://github.com/nunit/nunit3-vs-adapter/issues/49.

I couldn't find any solid documentation on how to use the runsettings file in an extension, but it looks like the Chutzpah test adapter can use that file for a few settings. It appears to be getting the settings through the IDiscoveryContext object that is passed as a parameter through some of the interface methods.

[Charlie Poole]

Thanks, I commented on the issue and gave it a high priority because a
number of other things depend on it.