By "best agent" we mean the agent able to run the test assembly, based on the target runtime. If there is more than one such agent, we want to use the closest runtime to the target runtime. For example, .NET 5.0 tests could be run by a .NET 5.0, 6.0 or 7.0 agent. If 5.0 is not available, we would prefer to use 6.0.
Currently, the first agent found which is able to run the tests is used and the normal ordering of agents, from lowest to highest runtime, meets our expectations for how agents are selected.
When we initially created pluggable agents, we decided to check those first. This is generally how all our extensions work because it allows replacement of an existing built-in implementation with that of the extension. So long as we only created legacy pluggable agents like .NET Framework 2.0 and .NET Core 2.1, this approach worked for us. With the introduction of a pluggable agent for the .NET 8.0 preview 1 release, it no longer works. That agent is capable of running any .NET 8.0 tests.
Consequently, we need to have some code in the engine which (1) locates all agents capable of loading and running a test assembly and (2) decides which one is the best fit using one or more criteria. At a minimum, it should use the target runtime. Ideally, this ought to be done without the engine having any knowledge of the extensions beyond what is revealed by their API.
By "best agent" we mean the agent able to run the test assembly, based on the target runtime. If there is more than one such agent, we want to use the closest runtime to the target runtime. For example, .NET 5.0 tests could be run by a .NET 5.0, 6.0 or 7.0 agent. If 5.0 is not available, we would prefer to use 6.0.
Currently, the first agent found which is able to run the tests is used and the normal ordering of agents, from lowest to highest runtime, meets our expectations for how agents are selected.
When we initially created pluggable agents, we decided to check those first. This is generally how all our extensions work because it allows replacement of an existing built-in implementation with that of the extension. So long as we only created legacy pluggable agents like .NET Framework 2.0 and .NET Core 2.1, this approach worked for us. With the introduction of a pluggable agent for the .NET 8.0 preview 1 release, it no longer works. That agent is capable of running any .NET 8.0 tests.
Consequently, we need to have some code in the engine which (1) locates all agents capable of loading and running a test assembly and (2) decides which one is the best fit using one or more criteria. At a minimum, it should use the target runtime. Ideally, this ought to be done without the engine having any knowledge of the extensions beyond what is revealed by their API.