This document outlines the usage of .NET Core SDK and its tools on the build server. In general, on a CI build server, you want to automate the installation in some way. The automation, ideally, should not require administrative privileges if at all possible.
For SaaS CI solutions, there are several options. This document will cover two very popular ones, TravisCI and AppVeyor. There are, of course, many other services out there, but the installation and usage mechanisms should be similar.
Installation options for CI build servers
Using the native installers
If using installers that require administrative privileges is not something that presents a problem, native installers for each platform can be used to set up the build server. This approach, especially in the case of Linux build servers, has one advantage which is automatic installing of dependencies needed for the SDK to run. The native installers will also install a system-wide version of the SDK, which may be desired; if it's not, you should look into the installer script usage outlined below.
Using this approach is simple. For Linux, there is a choice of using a feed-based package manager, such as
yum for CentOS, or using the packages themselves (that is, DEB or RPM). The former would require setting up the
feed that contains the packages.
For Windows platforms, you can use the MSI.
All of the binaries can be found on the .NET Core installation guide which points to the latest stable releases. If you wish to use newer (and potentially unstable) releases or the latest, you can use the links from the CLI repo.
Using the installer script
Using the installer script allows for non-administrative installation on your build server. It also allows a very easy automation. The script itself will download the ZIP/tarball files needed and will unpack them; it will also add the install location on the local machine to the PATH so that the tools become available for invocation immediately post-install.
The installer script can easily be automated at the start of the build to fetch and install the needed version of the SDK. The "needed version" is whatever version application being built requires. You can choose the installation path so you can install the SDK locally and then clean up after the build completes. This brings additional encapsulation and atomicity to the build process.
The installation script reference can be found in the dotnet-install document.
Dealing with the dependencies
Using the installer script means that the native dependencies are not installed automatically and that you have to install them if the operating system you are installing on already doesn't have them. You can see the list of prerequisites in the CLI repo.
CI services setup examples
The below sections show examples of configurations using the mentioned CI SaaS offerings.
The travis-ci can be configured to install the .NET Core SDK using the
csharp language and the
Travis can run both
osx (OS X 10.11) and
linux ( Ubuntu 14.04 ) job in a build matrix, see example .travis.yml
for more information.
The appveyor.com ci has .NET Core SDK 1.0.1 already installed in the build worker image
Visual Studio 2017.
os: Visual Studio 2017
It's possible to install a specific version of .NET Core SDK, see example appveyor.yml for more info.
In the example, the .NET Core SDK binaries are downloaded, unzipped in a subdirectory and added to
PATH env var.
A build matrix can be added to run integration tests with multiple version of the .NET Core SDK.
environment: matrix: - CLI_VERSION: 1.0.0-preview2-003121 - CLI_VERSION: Latest install: # .NET Core SDK binaries - ps: $url = "https://dotnetcli.blob.core.windows.net/dotnet/preview/Binaries/$($env:CLI_VERSION)/dotnet-dev-win-x64.$($env:CLI_VERSION.ToLower()).zip" # follow normal installation from binaries