This guide shows you how to build .NET projects with TeamCity, and it is recommended for developers completely new to TeamCity.
We recommend that you have a basic understanding of .NET and the .NET CLI. For more information, see the Getting Started guide in the .NET documentation.
If TeamCity successfully connects to your repository, you will see the following dialog.
In the Create Project From URL dialog you have the option to change the project name and initial build configuration name.
Note: In newer versions of TeamCity you will also see the default branch and branch specification fields, which allow you to specify which branches TeamCity should build. Ignore those for now.
After you click Proceed, TeamCity automatically scans your version control repository for supported technologies, in this case .NET.
If TeamCity detects a solution file (*.sln) in your repository, it will automatically suggest
build steps for your project that involve compiling
your .NET solution with
dotnet build and running all its tests with
Build steps should not be confused with a build configuration. A build configuration can potentially contain many build steps.
Select the .NET build steps checkboxes and click Use selected.
You have now successfully configured your .NET repository with TeamCity:
You can now run your first builds by pressing the Run button on the top-right as shown here:
Note: If you are using TeamCity Cloud, it could take up to a couple of minutes for a build agent to become available. During this time, your build will wait in the queue until it is picked up by an available agent.
If you are using TeamCity On-Premises with local build agents, your build will start immediately.
Once your build starts, you will be redirected to the build’s overview page with the Build Log tab open, which displays real-time data related to your build.
Now that your .NET repository is connected to TeamCity, you can continue to develop and push your code to your repository.
By default, TeamCity will poll the main branch of your VCS repository every 60 seconds for incoming changes and trigger one (combined) build for all detected commits.
If you want to trigger a build for every change to any branch in your repository, not just the main branch, add a wildcard branch specification to your VCS Root settings. Note that VCS settings belong to the TeamCity project, not to a single build configuration. Hence, any changes you make will be applied to all build configurations that use the same VCS root.
Example Branch Specifications:
+:refs/heads/*– TeamCity will check for changes in all the branches of your projects, but it won’t check pull-requests on platforms like GitHub, as they match
+:*– TeamCity will check for any incoming changes on any branch.
TeamCity will now monitor all the branches that conform to your branch specification and are pushed to your repository, checking for incoming changes, and it will run builds accordingly.
If you want TeamCity to automatically build pull requests that are made against your repository, you can add the Pull Request build feature to your build configuration.
Note: The Pull Request build feature transparently expands the branch specification
(see the previous step for more information). For example, in the case of GitHub, the pull
request feature will (invisibly) add
+:refs/pull/* to your branch specification.
We recommend ensuring that pull request branches are not included in your general branch specification when the pull request feature is used, because otherwise pull request-related features will not be available in TeamCity.
TeamCity will now check the external platform for pull requests and trigger a build for those matching your configuration rules.
Note: You should use this feature with caution on public repositories, as anyone could push harmful code to the repository (which you wouldn’t want to build).
When using the pull requests feature in combination with Azure DevOps, Bitbucket Server, GitHub, or GitLab, it also makes sense to use the Commit Status Publisher build feature. This feature will update the pull request’s status on the corresponding platform with the build results.
To set TeamCity up to report build results back to GitHub, you’ll need to follow these steps:
After TeamCity runs a build, you will now easily see if the changes caused a build failure right from the Pull Request tab on GitHub (green check mark).