Comment 5 for bug 860558

> 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.