pnunit-agent can't run a tests from another folder

I don't understand what the problem you want to solve is. There should be no need for the nunit core to load nunit-agent.exe - or any .exe for that matter. Rather, NUnit runs a process using the file path to nunit-agent.exe.

Can you provide a reproducible error situation?

I'm sorry. Instead of "nunit-agent.exe" should read "pnunit-agent.exe".

Consider a simple project. It depends only on the "nunit.framework.dll".
The result of compilation is placed in the subdirectory "bin".
To run the "pnunit-agent.exe" type the command "pnunit-agent.exe 8000 ." in the "bin" directory.
When you start the tests will be displayed error:

ERROR PNUnit.Agent.PNUnitTestRunner - Error running test Couldn't find assembly 'pnunit.framework, Version=1.0.4357.24760, Culture=neutral, PublicKeyToken=null'

To correct this error in the directory "bin" should be present copies of the files "pnunit-agent.exe" and "pnunit.framework.dll".

I reviewed various possibilities fix this problem. The easiest way to - modify the behavior of "NUnit.Core.AssemblyResolver".

Initially, the bug is reproducible under DotNet 4.0
The solution proposed for the "NUnit-2.6.0.11340" under Mono.

Example - is attached.
"agent" and "agent2" - examples run of "pnunit-agent.exe"
"launch" - examples run of tests
NUnit files will be searched for the path "/home/$USER/bin/NUnit-2.6.0.11340/bin"

sample test project

Some background some questions:

Normally, a pnunit test references pnunit.framework.dll, so the assembly
is copied to the bin directory. In this case, you are using pnunit to run
tests that make no use of pnunit, so the problem arises, which does not
come up in the use for which pnunit is intended.

Are you trying to use pnunit to parallelize arbitrary tests, rather than
distributed tests that interact with one another? This is not a recommended
use pattern, since it's not what pnunit is designed to do.

Normally, the NUnit AssemblyResolver is used _only_ to inject files requred
by NUnit which should _not_ be referenced by the user into the test
AppDomain. This is the case for nunit.core.dll and nunit.core.interfaces.dll.

Even so, I'd like to experiment with this problem. I have installed your
project on my Linux system and placed NUnit 2.6 in the same directory
as your setup. What commands do you issue to run the test?

Charlie

> Normally, a pnunit test references pnunit.framework.dll, so the assembly
> is copied to the bin directory. In this case, you are using pnunit to run
> tests that make no use of pnunit, so the problem arises, which does not
> come up in the use for which pnunit is intended.
If a pnunit test references pnunit.framework.dll, it does not correct the error.
We need a copy of pnunit-agent.exe in the bin directory.
If a pnunit test does not refer to pnunit.framework.dll,
it is still loaded through AssemblyResolver.
So I decided to abandon the link to pnunit.framework.dll.

> Even so, I'd like to experiment with this problem. I have installed your
> project on my Linux system and placed NUnit 2.6 in the same directory
> as your setup. What commands do you issue to run the test?
The attached archive is a script for bash.
Run from the directory of the project (SimpleNUnitTest)
"./agent" - launching pnunit-agent.exe from the current directory SimpleNUnitTest/bin
"./agent2" - launching pnunit-agent.exe from the current directory of pnunit-agent.exe
"./launch" - runs the test.

If you use the original NUnit-2.6.0.11340, then the command "./Launch":
1. works properly only if there is a SimpleNUnitTest/bin directory for both files pnunit.framework.dll and pnunit-agent.exe
2. freezes in all other cases.

If for NUnit-2.6.0.11340 I apply the suggested fix then
the command "./launch" works fine without any additional files or links.

> Are you trying to use pnunit to parallelize arbitrary tests, rather than
> distributed tests that interact with one another? This is not a recommended
> use pattern, since it's not what pnunit is designed to do.
I agree.
Unfortunately I have a project that involves a large number of simple tests related to I/O on the network (check the behavior of a network API).
This leads to a very great running time for all the tests. I didn't find another tool for parallel execution.

I responded to your last comment about 18 hours ago and it hasn't shown up here. I'll try again using the online interface to give you a summary of where I think we are.

1. The need to have a reference to pnunit.framework makes sense since that contains the common interfaces used by both the launcher and the agent.

2. The need to have pnunit-agent makes no sense at all. The test domain should not be referencing the agent.

3. While forcing the success of a reference through AssemblyResolver appears to solve your problem, it really doesn't deal with the basic question of why such a reference should be needed. I need to look into this further.

4. Running the equivalent test under MS .NET on Windows, it runs without the error. So this seems to be peculiar to Mono on Linux.

5. I'm asking the authors of pNUnit for help.

6. I'm not opposed to putting in the change you request temporarily if we don't find any better solution.

Charlie

Are you running the distributed binaries of NUnit 2.6.0.11340 or did you build from source?

Charlie

All tests and fixes have been made ​​only for NUnit-2.6.0.11240. This theme was created September 27.

Later I will also clarify the error under Windows. To test the project now will be using NUnit 2.6.0.11340

The upstream developers confirm that this bug exists and will work on it. As a temporary measure, I'll add the two assemblies to those supplied by AssemblyResolver.

However, the change you made won't do it because it merely includes .exe files in the directory searched in addition to dlls. However, NUnit does not use assemblyResolver on the directory containing pnunit-agent or the one with pnunit.framework. It only adds the lib and addins directories to AssemblyResolver.

However, these two assemblies can be handled specifically, using their known locations.

I go into this detail in case you are using a non-standard layout of the nunit files. If so, the fix won't work for you.

Temporary fix is committed. It will be removed when a more permanent correction is ready.