TeamCity
Powerful CI/CD for DevOps-centric teams
Build, test and deploy .NET Core projects with TeamCity
The .NET Core development platform is the next wave of .NET ecosystem evolution which brings cross-platform targets for your existing or new products. Microsoft ships .NET Core SDK packages with a runtime for supported platforms and command line tools (.NET CLI) to build, test, and pack such projects.
The .NET Core support plugin for TeamCity aims to bring streamline support for .NET Core CLI by providing .NET Core build steps, CLI detection on the build agents, and auto-discovery of build steps in your repository.
Installation
The plugin is available for download from the TeamCity plugin gallery and can be installed as an additional TeamCity plugin. Next the .NET Core SDK has to be installed on your build agent machines. The plugin uses the PATH
environment variable to determine the .NET CLI tools location, but you can override it by specifying the DOTNET_HOME
environment variable as follows: DOTNET_HOME=C:\Program Files\dotnet\
You can check that plugin has been properly initialized by navigating to the build agent parameters:
Building and testing .NET Core projects
The .NET Core plugin supports auto-discovery of build steps, and usually all you need is to use the Create project from URL wizard:
If you want to tune some parameters in your build steps, the .NET Core plugin provides details about configuration options and hints at their possible values:
Specify project build version
While building and creating project packages, the .NET CLI tools use the version number defined in the project.json file. If you want to provide a custom build number, you can update your project.json by leveraging the File Content Replacer build feature as follows:
Here you need to specify the target project.json files to process, fill in (\{[^{]*\"version\"\s*:\s*\")([^\"]+)(\")
in the Find what and $1%build.number%$3
in the Replace with fields. Then, after executing the vcs checkout, the File Content Replacer will set the version, for instance %build.number%
in the previous example.
Note: Currently .NET CLI tools support projects with project.json-based structure, but the upcoming versions will rely on the new csproj structure.
Testing .NET Core projects
The xUnit framework provide dotnet test runner which report the information about test results on the fly:
The NUnit test runner does not support it out of the box, but you can vote for the following issue. If you need any other test framework support, please leave a comment in the related issue.
Deploying .NET Core projects
.NET Core libraries
Your projects can contain a number of shared libraries which can be reused in dependent project builds. Instead of artifact dependencies, it is recommended that you use the build-in TeamCity NuGet feed. In this the specified build artifacts paths need to include the produced NuGet packages.
Tip: You can use the NuGet Dependency Trigger to start a build when a package has been updated in some nuget feed.
Publishing ASP.NET Core projects
Such projects can be deployed to a wide range of platforms. As a result of executing the dotnet publish
build step, you will receive the published package data in your file system. Then you need to decide how to deploy it to the target system.
For Windows servers, the Web Deploy utility can be used. Alternatively, you can deploy the package with the auto-generated %profile%-publish.ps1
or default-publish.ps1
PowerShell scripts. More details on how to provide proper arguments to these scripts can be found in the Web Publishing documentation.
For other server platforms you can publish package by leveraging TeamCity Deployer build steps like FTP/SSH/SMB.
Feedback
You are welcome to try the plugin for TeamCity, and your feedback will be really appreciated, so please share your thoughts in the comments to this blog post, in the forum or issue tracker.
Happy building modern .NET Core projects!