Q:

Why does TeamCity generate both a Visual Studio (.sln) build-step and several .NET CLI (dotnet) build steps?

I'm trying to set up my solution to build using TeamCity 2019. When I enter the URL of my project's Git repository, TeamCity auto-detects 4 build steps:

Visual Studio (sln) Targets: rebuild  
.NET CLI (dotnet) restore 
.NET CLI (dotnet) build  
.NET CLI (dotnet) test

I'm confused about step 2/3. Why is .NET CLI restoring and building, when a re-build is already performed? Does this imply that something is unusual with my .sln file? 
This solution is a group of Windows desktop C++ projects, if that matters.
The reason I'm so concerned with why these build steps are appearing is that the .NET CLI build step is failing with a mysterious error, discussed on both the TeamCity forum and StackOverflow:
https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360007640660-error-MSB4019-The-imported-project-C-Microsoft-Cpp-Default-props-was-not-found-when-building-via-TeamCity
MSBuild in TeamCity of Visual Studio 2012 solution
I haven't been able to find any good answer for why those build-steps are failing. All of the answers on StackOverflow for that issue are pretty shot-in-the-dark "try this, try that" without a simple explanation of where I went wrong. 

A:

This is list of Build Runners.
In this case you can ignore step 2,3 and 4.
step 1 (first step : Visual Studio (sln) Targets: rebuild) is enough to rebuild your all projects of one .sln.
Teamcity finds all project-point 4 types and display the list with compatible runners, user have to decide which should be compatible with the given project.

