What is the difference between the 4 auto-detected build steps in my VS2019 Build Configuration?

Hello - I'm still hoping for an answer to this, because my build is failing and I'm wondering which steps are correct/necessary. 

It looks like the .NET CLI steps are doing the same thing as the Visual Studio (.sln) build. Why are the .NET CLI build steps necessary?

Hi, I guess I could rephrase my question to get at the core of the issue:

A few years back, I believe I tested TeamCity and found that it was able to auto-detect my entire project's build-settings without needing any adjustment or generating redundant steps. 

I'm wondering why, in this case, the TeamCity auto-build-detection seems to be generating extra steps. If the answer is simply that TeamCity tends to duplicate Visual Studio build-steps with .NET CLI steps, that's fine with me; I just want to ensure that I'm not deleting "redundant" build-steps that later turn out to be useful. 

What are the precise conditions for TeamCity to generate .NET CLI build-steps in addition to Visual Studio (sln) build-steps?

Hi Alex,

sorry for the delay. The reason for multiple candidate runners to appear is that the project is compatible with all those multiple build runners, but TeamCity cannot identify a unique one that fits better than the others, so it offers them as a possibility for you to decide. In particular in your scenario, choosing the first will run the "Rebuild" target of the VS solution, the first dotnet will run the "dotnet restore" command, the second the "dotnet build", and the last one the "dotnet test". It's possible that you might want to run one, two, or all of them, and while in your specific scenario it might be irrelevant, in some others it might not, and taking a decision in place of the user at this stage might lead to more work.

In the past, the dotnet runner did not exist, it was created as a side effect of the rise of .net core and more cli-based tooling, so it's likely that the last time you checked out TeamCity it did not exist at all. This should mean that your project is likely to work fine on the Visual Studio runner

Currently there is a wide overlapping in terms of what they can build between the multiple visual studio runners, the msbuild runner and the dotnet runner, and while there are some differences that might make some more comfortable to use than others in specific scenario, we are working on improving clarity and consolidation going forward, but there is no current roadmap for it. If you have any specific comment or suggestion, please don't hesitate to ask

Thank you for the clarification. I thought this would be the answer, but it helps a lot to hear it straight from you.