Summary
The hidden --client-port option advertises “a single valid port”, but validation only checks int.TryParse. Negative and out-of-range integers are accepted and then fail later during socket connection.
Evidence
src/Platform/Microsoft.Testing.Platform/CommandLine/PlatformCommandLineProvider.cs:116-119
if (commandOption.Name == ClientPortOptionKey && (!int.TryParse(arguments[0], out int _)))
{
return ValidationResult.InvalidTask(string.Format(CultureInfo.InvariantCulture, PlatformResources.PlatformCommandLinePortOptionSingleArgument, ClientPortOptionKey));
}
src/Platform/Microsoft.Testing.Platform/Resources/PlatformResources.resx:417-418
<value>'--{0}' expects a single valid port as argument</value>
src/Platform/Microsoft.Testing.Platform/ServerMode/JsonRpc/ServerModeManager.cs:16-25
clientPort = commandLineService.TryGetOptionArgumentList(PlatformCommandLineProvider.ClientPortOptionKey, out string[]? clientPortArgs)
? int.Parse(clientPortArgs[0], CultureInfo.InvariantCulture)
: throw new InvalidOperationException(...);
return new MessageHandlerFactory(clientHostName, clientPort.Value, serviceProvider.GetOutputDevice());
src/Platform/Microsoft.Testing.Platform/ServerMode/JsonRpc/MessageHandlerFactory.cs:54-56
await client.ConnectAsync(host: _host, port: _port, cancellationToken).ConfigureAwait(false);
Why this is a real issue
A value such as --client-port -1 passes command-line validation even though -1 is not a valid TCP port. MTP does not reject it until much later, when JSON-RPC server mode tries to connect and the socket layer throws.
That is a validation gap in a core server-mode parameter. Even though the option is hidden, it is still part of the protocol-facing surface used by dotnet test/server-mode integrations, and failures happen in the wrong layer with a much less actionable error.
Suggested resolution
Validate --client-port against the real TCP port range (0-65535, or 1-65535 if 0 is not intended here) during command-line validation so invalid values fail with InvalidCommandLine.
Related issues
Summary
The hidden
--client-portoption advertises “a single valid port”, but validation only checksint.TryParse. Negative and out-of-range integers are accepted and then fail later during socket connection.Evidence
src/Platform/Microsoft.Testing.Platform/CommandLine/PlatformCommandLineProvider.cs:116-119src/Platform/Microsoft.Testing.Platform/Resources/PlatformResources.resx:417-418src/Platform/Microsoft.Testing.Platform/ServerMode/JsonRpc/ServerModeManager.cs:16-25src/Platform/Microsoft.Testing.Platform/ServerMode/JsonRpc/MessageHandlerFactory.cs:54-56Why this is a real issue
A value such as
--client-port -1passes command-line validation even though-1is not a valid TCP port. MTP does not reject it until much later, when JSON-RPC server mode tries to connect and the socket layer throws.That is a validation gap in a core server-mode parameter. Even though the option is hidden, it is still part of the protocol-facing surface used by
dotnet test/server-mode integrations, and failures happen in the wrong layer with a much less actionable error.Suggested resolution
Validate
--client-portagainst the real TCP port range (0-65535, or 1-65535 if0is not intended here) during command-line validation so invalid values fail withInvalidCommandLine.Related issues
--server random#6879