Eliminate use of Remoting as a Transport between Engine and Agents

[CharliePoole]

We currently use Remoting when communicating to a .NET Framework agent and TCP with a .NET Core agent.

Since the standard engine itself targets the .NET Framework, we are capable of using TCP in both environments.

I propose we eliminate Windows Remoting and use TCP for all agents.

Although this would give us a single common Transport, I would keep the existing class structure, which permits us to add new transports to the engine.

@nunit/engine-team Thoughts on this?

[stevenaw]

This approach makes sense to me. It sounds like it will modernize the transport and improve consistency between our agents. Leaving the class structure in place would also make it easier to evolve in the future if we were to ever need to.

[manfred-brands]

I agree, it removes differences between frameworks and is less code to maintain but allowing for future new communications to be introduced.

[CharliePoole]

OK, let's proceed with that approach. It's all internal, so a Feature rather than a Breaking Change.

[mikkelbu]

I also agree with the above mentioned suggestion

[CharliePoole]

If anyone wants to work on this, the code that selects which transport to use is in the agent, in Program.cs. It simply uses conditional compilation to decide which transport should be used.

On the engine side, TestAgency.cs constructs, starts and eventually stops both transports. It responds to whichever transport is used by the agent. A minor wrinkle, however, is that it passes an argument representing the endpoint to be used to agent when it is launched. This is in AgentProcess.

Changing the above will trigger lots of other code changes. I suspect most of it will have to do with getting the TCP code on the agent side to work under .NET Framework as well as removing vestiges of Windows Remoting code everywhere.

[CharliePoole]

Update: @veleek worked on this but created a PR for main rather than version4.

Because V4 has deviated so much from V3, simple cherrypicking of his commits didn't work very well, so I'm following along with his changes and have created a new branch for this issue. Currently, it's all working with one outstanding problem I intend to document separately. New PR soon.

[veleek]

@CharliePoole let me know if you've made progress on this that you want me to pick up.