CODEWITHSUNDEEP
visual-studioteamcity
afarley
afarley

Reputation: 815

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:

  1. Visual Studio (sln) Targets: rebuild
  2. .NET CLI (dotnet) restore
  3. .NET CLI (dotnet) build
  4. .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.

Upvotes: 0

Views: 379

Answers (1)

Nirav Mistry
Nirav Mistry

Reputation: 989

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.

Upvotes: 1

Related Questions