Build .NET solution using GitLab CI Pipeline

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"

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

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'