Build .NET solution using GitLab CI Pipeline

Question

I have a solution with several .NET projects in it. I use GitLab, not self-hosted, for version control and would like to start using their CI tools as well. I have added the following .gitlab-ci.yml file to my root:

stages:
  - build
  - test

build_job:
  stage: build
  script:
  - 'echo building...'
  - 'msbuild.exe Bizio.sln'
  except:
  - tags

test_job:
  stage: test
  script:
  - 'echo: testing...'
  - 'msbuild.exe Bizio.sln'
  - 'dir /s /b *.Tests.dll | findstr /r Tests\\bin\\ > tests_list.txt'
  - 'for /f %%f in (tests_list.txt) do mstest.exe /testcontainer: "%%f"'
  except:
  - tags

The build stage always fails because it doesn't know what msbuild is. The exact error is:

/bin/bash: line 61: msbuild.exe: command not found

After some investigating, I've figured out that I'm using a shared runner. Here is the entire output from the job run:

Running with gitlab-runner 10.6.0-rc1 (0a9d5de9)
  on docker-auto-scale 72989761
Using Docker executor with image ruby:2.5 ...
Pulling docker image ruby:2.5 ...
Using docker image sha256:bae0455cb2b9010f134a2da3a1fba9d217506beec2d41950d151e12a3112c418 for ruby:2.5 ...
Running on runner-72989761-project-1239128-concurrent-0 via runner-72989761-srm-1520985217-1a689f37...
Cloning repository...
Cloning into '/builds/hyjynx-studios/bizio'...
Checking out bc8085a4 as master...
Skipping Git submodules setup
$ echo building...
building...
$ C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Bizio.sln
/bin/bash: line 61: msbuild.exe: command not found
ERROR: Job failed: exit code 1

It looks like the shared runner I have is using a Docker image for Ruby, which seems wrong. I don't know how I can change that or select a different one that can be used for .NET. After some further investigating I'm getting worried that I'll have to jump through a lot of hoops to get what I want, like using an Azure VM to host a GitLab Runner that can build .NET apps.

What do I need to do to use GitLab's CI pipelines to build my .NET solution using a non-self-hosted GitLab instance?

Answer 1

You should be able to setup your own shared runner on a machine with the Framework 4 build tools on it (either using a Docker image, like microsoft/dotnet-framework-build, or just your native machine).

The simplest case to get going is using your own desktop, where you know your solution already builds. (Since using Docker images for the build is absolutely possible, but involves all of the extra steps of making sure you have docker working on your machine).

• Download gitlab-runner on your computer from https://docs.gitlab.com/runner/install/windows.html

  • Create a directory on computer (C:\gitlab-runner)
  • Download the latest binary x86 or x64 to that folder
  • Rename the binary to "gitlab-runner.exe"
• Get a gitlab-ci token for your runner
  • Probably the easiest way to do this is to go to your project in gitlab.com and go to Settings -> CI/CD and expand General Pipeline Settings.
  • In the Runner Token section, click the Reveal Value button to show the token value. You will need this during the runner registration step.
• Register the gitlab runner according to Registering Runners - Windows
  • Open an elevated command prompt (Run as administrator)
  • cd to c:\gitlab-runner
  • type gitlab-runner register
  • The register prompts will take you through the steps to register the runner, but in a nutshell, you will be putting in
  • gitlab.com as your coordinator URL, entering the token from your project
  • giving your runner a name
  • tagging your runner (so that you can associate it with projects that it is capable of building, testing, etc - for simplicity, you can skip tags now)
  • allowing it to run for untagged jobs (again, simplicity, say true)
  • lock runner to current project (simplicity, say true)
  • and choosing the executor (enter shell, which is basically saying use the Windows Command-line)
• Install gitlab-runner as a service, so that it is mostly always checking for work to do
  • In your command prompt, type gitlab-runner install
  • Then type gitlab-runner start
  • (Now, if you go to Services, you will see gitlab-runner listed, and it should be running - Just when when/if the runner crashes, you should go to Services to restart it)

Whew. Now that runner is setup, it should be activated when you push a commit or a merge is requested.

If you are having issues still with the .gitlab-ci.yml file building properly, you can debug it locally (without having to keep triggering it through gitlab.com) by going to your solution folder in the command line and then executing c:\gitlab-runner\gitlab-runner build (To test the build step, for example).

If the build step has problem finding your solution file, you might want to try changing it from 'msbuild.exe Bizio.sln' to 'msbuild.exe .\Bizio.sln'

Answer 2

To complement the answer by reallyrae, the other option for .Net Core apps is to include a call to the container as the first line in your .gitlab-ci.yml file. This will allow the build to happen on a shared GitLab.com runner.

image: microsoft/dotnet

If you are building a traditional .Net application, you can try the mono docker image. If that doesn't work for you, the local runner is, as far as I know, your only option.

image: mono:latest

Answer 3

Or multi stage builds:

stages:
  - build-dotnet
  - test-dotnet
  - build-mono
  - test-mono

build-dotnet:
  stage: build-dotnet
  image: microsoft/dotnet:latest
  before_script:
    - "cd source"
    - "dotnet restore"
    - "cd .."
    - "cd samples"
    - "dotnet restore"
    - "cd .."
  script:
      - "cd source"
      - "dotnet build"
      - "cd .."
      - "cd samples"
      - "dotnet build"
      - "cd .."

build-mono:
  stage: build-mono
  image: mono:latest
  before_script:
  script:
    - nuget restore ./source/Source.sln
    - msbuild 
        /p:Configuration="Release"
        /p:Platform="Any CPU" 
        "./source/Source.sln"