@adamsitnik Thanks for the quick review! I see what you mean about making it more generic, and not just limiting this to CoreRT. I actually first put the extra space inside the DotNetCliCommand.GetRestoreCommand method, but then realized it would be needed inside Build and Publish also. I don't love the idea of putting the extra space at the end of GetCustomMsBuildArguments because then the extraArguments tightly depends on GetCustomMsBuildArguments being directly before extraArguments in the list of arguments. If someone was to change or move GetCustomMsBuildArguments later, that could break this again.

What do you think about instead creating an extension method called AppendCliArgument or just AppendArgument which would check that any argument being added has a leading space. Then we can replace the calls to Append with AppendArgument so it would look like this:

new StringBuilder()
                .AppendArgument("restore")
                .AppendArgument(string.IsNullOrEmpty(artifactsPaths.PackagesDirectoryName) ? string.Empty : $"--packages \"{artifactsPaths.PackagesDirectoryName}\"")
                .AppendArgument(GetCustomMsBuildArguments(buildPartition.RepresentativeBenchmarkCase, buildPartition.Resolver))
                .AppendArgument(extraArguments)
                .AppendArgument(GetMandatoryMsBuildSettings(buildPartition.BuildConfiguration))
                .ToString()

It seems like there are a lot of places where either leading or trailing spaces are hard-coded as magic strings, which seems dangerous and inconsistent. Such as these places:
Leading space
Trailing space
Leading space
Trailing space

To me, it seems better to just deal with the spaces between arguments in one place, like this proposed AppendArgument method.

Thoughts?

What do you think about instead creating an extension method called AppendCliArgument or just AppendArgument which would check that any argument being added has a leading space.

It's a very good idea! 👍 AppendArgument sounds best for me!

@adamsitnik I've opened a new PR with the changes we talked about plus some other cleanup and the other output path fix. It's here: #1955

I thought it would be easier to have it all in one place with a better-named branch.