Run multiple instances of nunit-console on the same PC

[varnk]

Currently our company uses NUnit to test USB devices that we develop. There are several devices that are tested using NUnit3 with NUnit-Console on Jenkins test agents. Currently we test each device on respective test agents using a separate Jenkins job for each device and agent. Our tests typically require over 11 hours of runtime for each device. We would like to consolidate our testing so that we could potentially run more than one Jenkins job in-parallel on an agent so that we could test multiple devices at the same time. I was hoping that NUnit-Console could run multiple instances to do this, but unfortunately I am getting SocketExceptions due to NUnit-Console using the same endpoint. I was told by Charlie Poole that currently NUnit-Console does not support running multiple instances of the process. I would like to suggest that this would be available in future releases of NUnit-Console.

[CharliePoole]

@nunit/engine-team I'd like to clarify what I told @varnk on SO, adding a bit of nuance to my statement there... :-)

When we created the console runner and engine (long ago in a galaxy far away) we had the idea that it would become a centralized controller for running multiple processes as well as threads and would be unique in each machine. As a result, running multiple copies was never a design goal. And, as a result of that, we didn't create any system or other levels of tests to ensure that we could run multiple copies. That's what I mean by "not supported". IOW, if it works (and I think it sometimes does) it's not by design.

OTOH, we decided not to take the further step of preventing the user from running multiple copies, which would be entirely possible. Maybe we should have, but that would have limited our ability to run tests. When running tests of the console we do actually create and run additional copies by controlling the port.

If somebody wanted to fix this, one rather simple approach would be to allow specifying the port to be used by the console at the command-line. This option would have to be used in creating both the remoting transport instance used for running .NET framework and the TCP instance used for running under .NET Core.

@varnk From your comments, this is probably something within your skillset. If @OsirisTerje would consider accepting a PR, perhaps you would consider contributing one. :-) Contact me offline if you need any help.

[CharliePoole]

I should add that it's not yet verified that the port causes this problem. That's just my speculation based on past problems. In fact, any shared resource used by the runner or engine could be the cause, so it will have to be narrowed down a bit first.