Meta runner fails to start xunit.console.exe after the package version update

[ghost]

We use the xUnit + dotCover as one of the build steps in a TeamCity configuration. The step started failing consistently around 7/17/2018 on some of the branches with the following message:
##teamcity[buildStatus text='Cannot find path 'C:\BuildAgent\work\a089c236b45ffff1\xunit.runner.console.2.3.1\tools\net452\xunit.console.exe C:\BuildAgent\work\a089c236b45ffff1\xunit.runner.console.2.4.0\tools\net452\xunit.console.exe.config' because it does not exist.' status='FAILURE']
We use git and 'Automatically on server' checkout mode for the version control.

Upon further investigation, we discovered the following:

• Meta runner installs the latest version of the xunit.runner.console nuget package into the working directory.
• Version 2.4.0 of the xunit.runner.console package came out around the same time our builds started failing.
• The working folders on all build agents had both xunit.runner.console.2.3.1 and xunit.runner.console.2.4.0 folders at the time of the failures.
• Meta runner code at MRPP_xunit_dotcover.xml#L78 is using Resolve-Path on xunit.runner.console.* which I believe returns an array of strings in case if both xunit.runner.console.2.3.1 and xunit.runner.console.2.4.0 folders are present.
• The meta runner also appends .config suffix to the path and then fails because the path 'C:\BuildAgent\work\a089c236b45ffff1\xunit.runner.console.2.3.1\tools\net452\xunit.console.exe C:\BuildAgent\work\a089c236b45ffff1\xunit.runner.console.2.4.0\tools\net452\xunit.console.exe.config' does not exist.
• Manually deleting xunit.runner.console.2.3.1 folder on a build agent fixes the problem.

Is this a bug in the meta runner code? Or is it something wrong with the configuration we use? It seems like meta runner code should account for having multiple version of the xunit.runner.console package in the working folder and only use the most recent one. Or even better, the version of the xunit.runner.console package should be a configurable parameter.

[codekaizen]

The fix to #123 will partially fix this, but not if there are more than 1 xunit packages found, since the wrong xunit might be selected.