@adamralph while the fix is not major, my only concern is that it could break people who are parsing the console output for vstest.console, which is why I would be reluctant to take this.

@singhsarab for additional input.

@mayankbansal018 the changes introduced by this issue, and released in SDK 2.2.300, are way more likely to break anyone than the removal of a blank line: #1836

@adamralph yeah that's actually more disruptive, & I had totally forgotten about that change 😢.

In which version of the .NET SDK can we expect this change?

You change is included in 16.2.0 onwards, so that would be sdk 3.1.100 and newer.

Thank you @nohwnd.

Would it be a good idea to assign milestones? Then I wouldn't have to ask.

@nohwnd it's still there in 3.1.200

@adamralph you are right, the space is still there. And I can see the line you removed is still gone in the master. Looking at the code it only affects situations when we have attachments (say a code coverage log), so I am guessing it is not impacting this situation.

I will be revisiting the console output in the next sprint in the other issue. We can polish it there. 🙂

Would it be a good idea to assign milestones?

I am adding milestones, but the mapping between our release and dotnet/sdk is not that easy. We don't control what they take, and where they take it. I am monitoring this, and believe me, it is also my goal to get this more transparent. Because right now it is very hard to see where each fix will end up and how to update to that version.