diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5d065deb23c8a2c7adf2434d499167150abbe1b4..b8d284532bd7afa780cd988dc9357697238de3cd 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,89 +1,113 @@
-# This file is a template, and might need editing before it works on your project.
 # To contribute improvements to CI/CD templates, please follow the Development guide at:
 # https://docs.gitlab.com/ee/development/cicd/templates.html
 # This specific template is located at:
-# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET.gitlab-ci.yml
+# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET-Core.gitlab-ci.yml
 
-# The following script will work for any project that can be built from command line by msbuild
-# It uses powershell shell executor, so you need to add the following line to your config.toml file
-# (located in gitlab-runner.exe directory):
-#   shell = "powershell"
+# This is a simple example illustrating how to build and test .NET Core project
+# with GitLab Continuous Integration / Continuous Delivery.
 #
-# The script is composed of 3 stages: build, test and deploy.
+# ### Specify the Docker image
 #
-# The build stage restores NuGet packages and uses msbuild to build the exe and msi
-# One major issue you'll find is that you can't build msi projects from command line
-# if you use vdproj.  There are workarounds building msi via devenv, but they rarely work
-# The best solution is migrating your vdproj projects to WiX, as it can be build directly
-# by msbuild.
+# Instead of installing .NET Core SDK manually, a docker image is used
+# with already pre-installed .NET Core SDK.
 #
-# The test stage runs nunit from command line against Test project inside your solution
-# It also saves the resulting TestResult.xml file
+# The 'latest' tag targets the latest available version of .NET Core SDK image.
+# If preferred, you can explicitly specify version of .NET Core (e.g. using '2.2-sdk' tag).
 #
-# The deploy stage copies the exe and msi from build stage to a network drive
-# You need to have the network drive mapped as Local System user for gitlab-runner service to see it
-# The best way to persist the mapping is via a scheduled task
-# running the following batch command: net use P: \\x.x.x.x\Projects /u:your_user your_pass /persistent:yes
+# See other available tags for .NET Core: https://hub.docker.com/_/microsoft-dotnet
+# Learn more about Docker tags: https://docs.docker.com/glossary/?term=tag
+# and the Docker itself: https://opensource.com/resources/what-docker
+image: mcr.microsoft.com/dotnet/sdk:latest
 
-# place project specific paths in variables to make the rest of the script more generic
+# ### Define variables
+#
 variables:
-  EXE_RELEASE_FOLDER: 'YourApp\bin\Release'
-  MSI_RELEASE_FOLDER: 'Setup\bin\Release'
-  TEST_FOLDER: 'Tests\bin\Release'
-  DEPLOY_FOLDER: 'P:\Projects\YourApp\Builds'
-  NUGET_PATH: 'C:\NuGet\nuget.exe'
-  MSBUILD_PATH: 'C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe'
-  NUNIT_PATH: 'C:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe'
+  # 1) Name of directory where restore and build objects are stored.
+  OBJECTS_DIRECTORY: 'obj'
+  # 2) Name of directory used for keeping restored dependencies.
+  NUGET_PACKAGES_DIRECTORY: '.nuget'
+  # 3) A relative path to the source code from project repository root.
+  # NOTE: Please edit this path so it matches the structure of your project!
+  SOURCE_CODE_PATH: '*/*/'
 
-stages:
-  - build
-  - test
-  - deploy
+# ### Define global cache rule
+#
+# Before building the project, all dependencies (e.g. third-party NuGet packages)
+# must be restored. Jobs on GitLab.com's Shared Runners are executed on autoscaled machines.
+#
+# Each machine is used only once (for security reasons) and after that is removed.
+# This means that, before every job, a dependency restore must be performed
+# because restored dependencies are removed along with machines. Fortunately,
+# GitLab provides cache mechanism with the aim of keeping restored dependencies
+# for other jobs.
+#
+# This example shows how to configure cache to pass over restored
+# dependencies for re-use.
+#
+# With global cache rule, cached dependencies will be downloaded before every job
+# and then unpacked to the paths as specified below.
+cache:
+  # Per-stage and per-branch caching.
+  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG"
+  paths:
+    # Specify three paths that should be cached:
+    #
+    # 1) Main JSON file holding information about package dependency tree, packages versions,
+    # frameworks etc. It also holds information where to the dependencies were restored.
+    - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/project.assets.json'
+    # 2) Other NuGet and MSBuild related files. Also needed.
+    - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/*.csproj.nuget.*'
+    # 3) Path to the directory where restored dependencies are kept.
+    - '$NUGET_PACKAGES_DIRECTORY'
+  #
+  # 'pull-push' policy means that latest cache will be downloaded (if it exists)
+  # before executing the job, and a newer version will be uploaded afterwards.
+  # Such a setting saves time when there are no changes in referenced third-party
+  # packages.
+  #
+  # For example, if you run a pipeline with changes in your code,
+  # but with no changes within third-party packages which your project is using,
+  # then project restore will happen quickly as all required dependencies
+  # will already be there — unzipped from cache.
+
+  # 'pull-push' policy is the default cache policy, you do not have to specify it explicitly.
+  policy: pull-push
 
-build_job:
+# ### Restore project dependencies
+#
+# NuGet packages by default are restored to '.nuget/packages' directory
+# in the user's home directory. That directory is out of scope of GitLab caching.
+#
+# To get around this, a custom path can be specified using the '--packages <PATH>' option
+# for 'dotnet restore' command. In this example, a temporary directory is created
+# in the root of project repository, so its content can be cached.
+#
+# Learn more about GitLab cache: https://docs.gitlab.com/ee/ci/caching/index.html
+before_script:
+  - 'dotnet restore --packages $NUGET_PACKAGES_DIRECTORY'
+
+build:
   stage: build
-  only:
-    - tags  # the build process will only be started by git tag commits
+  # ### Build all projects discovered from solution file.
+  #
+  # Note: this will fail if you have any projects in your solution that are not
+  # .NET Core-based projects (e.g. WCF service), which is based on .NET Framework,
+  # not .NET Core. In this scenario, you will need to build every .NET Core-based
+  # project by explicitly specifying a relative path to the directory
+  # where it is located (e.g. 'dotnet build ./src/ConsoleApp').
+  # Only one project path can be passed as a parameter to 'dotnet build' command.
   script:
-    - '& "$env:NUGET_PATH" restore'  # restore Nuget dependencies
-    - '& "$env:MSBUILD_PATH" /p:Configuration=Release'  # build the project
-  artifacts:
-    expire_in: 1 week  # save gitlab server space, we copy the files we need to deploy folder later on
-    paths:
-      - '$env:EXE_RELEASE_FOLDER\YourApp.exe'  # saving exe to copy to deploy folder
-      - '$env:MSI_RELEASE_FOLDER\YourApp Setup.msi'  # saving msi to copy to deploy folder
-      - '$env:TEST_FOLDER\'  # saving entire Test project so NUnit can run tests
+    - 'dotnet build --no-restore'
 
-test_job:
+tests:
   stage: test
-  only:
-    - tags
+  # ### Run the tests
+  #
+  # You can either run tests for all test projects that are defined in your solution
+  # with 'dotnet test' or run tests only for specific project by specifying
+  # a relative path to the directory where it is located (e.g. 'dotnet test ./test/UnitTests').
+  #
+  # You may want to define separate testing jobs for different types of testing
+  # (e.g. integration tests, unit tests etc).
   script:
-    - '& "$env:NUNIT_PATH" ".\$env:TEST_FOLDER\Tests.dll"'  # running NUnit tests
-  artifacts:
-    when: always  # save test results even when the task fails
-    expire_in: 1 week  # save gitlab server space, we copy the files we need to deploy folder later on
-    paths:
-      - '.\TestResult.xml'  # saving NUnit results to copy to deploy folder
-  dependencies:
-    - build_job
-
-deploy_job:
-  stage: deploy
-  only:
-    - tags
-  script:
-    # Compose a folder for each release based on commit tag.
-    # Assuming your tag is Rev1.0.0.1, and your last commit message is 'First commit'
-    # the artifact files will be copied to:
-    # P:\Projects\YourApp\Builds\Rev1.0.0.1 - First commit\
-    - '$commitSubject = git log -1 --pretty=%s'
-    - '$deployFolder = $($env:DEPLOY_FOLDER) + "\" + $($env:CI_BUILD_TAG) + " - " + $commitSubject + "\"'
-
-    # xcopy takes care of recursively creating required folders
-    - 'xcopy /y ".\$env:EXE_RELEASE_FOLDER\YourApp.exe" "$deployFolder"'
-    - 'xcopy /y ".\$env:MSI_RELEASE_FOLDER\YourApp Setup.msi" "$deployFolder"'
-    - 'xcopy /y ".\TestResult.xml" "$deployFolder"'
-  dependencies:
-    - build_job
-    - test_job
+    - 'dotnet test --no-restore'