NUnit 2.6.4 had a nunit-console-runner.dll file that I could use in my C# app as follows:
string[] my_args = { "/run=SmokeTests.ATest", "Tests.dll" };
NUnit.ConsoleRunner.Runner.Main(my_args);
But I don't see this dll in 3.0. Is there one? If not, how can i use the same command to run NUnit tests programmatically?
Nunit 3 Console Runner can be installed as a reference of the nuget package from - https://www.nuget.org/packages/NUnit.ConsoleRunner/
nunit3-console.exe file will be stored under Project Directory >> Package >> nunit-console runner folder
Further documentation can be found here - https://github.com/nunit/docs/wiki/Console-Runner
Related
have .net core 3.1 Microsoft.net.sdk projects, with lots of async xUnit tests.
tried - adding coverlet.msbuild 2.9.0 to the project, and then running:
dotnet test Common\Common.csproj /p:CollectCoverage=true /
got 100% displayed, but an empty coverage file created
tried - adding coverlet.collector 1.3.0 to the project and then running:
dotnet test Common\Common.csproj --collect:"XPlat Code Coverage"
got a file created in testresults\{guid}\coverage.cobertura.xml - but it just says lines-covered=0
whereas stdout is saying 88 tests run in 4s. What am I doing wrong?
For me coverlet.msbuild works perfect with command:
dotnet test Common\Common.csproj /p:CollectCoverage=true /p:IncludeTestAssembly=true /p:CoverletOutputFormat=cobertura /p:ExcludeByFile=\"**/Microsoft.NET.Test.Sdk.Program.cs\"
So, I guess you missed CoverletOutputFormat here.
I'm pretty new to CI (from a brand new set up point at least). I created a project in Rider, using the default version of NUnit that is provided if you select to 'Create new NUnit Project', and I am now trying to set up an automated build for it using travis-CI.
The target .NET framework version of my project and test projects (confirmed in Project properties in Rider) is 4.5.
The version of Nunit I am using is the default version provided with Rider, 3.5.
Here is my .travis.yml build file:
language: csharp
solution: .sln
install:
- nuget restore FindWordsWithConcatenations.sln
- nuget install NUnit.Runners -Version 3.5.0 -OutputDirectory testrunner
script:
- xbuild /p:Configuration=Debug ./FindWordsWithConcatenations.sln
- mono ./testrunner/NUnit.ConsoleRunner.3.5.0/tools/nunit-agent.exe ./TestFindWordsWithConcatenations/bin/Debug/TestFindWordsWithConcatenations.dll
I confirmed on my own machine by running the nuget command that the test runner path should be correct, when I run the nunit-agent (via agent, agent-x86, or agent-console) I get the following error (locally, and on the server):
Unhandled Exception: System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
at System.Guid..ctor(String g)
at NUnit.Agent.NUnitTestAgent.Main(String[] args)
I've also tried running with no configuration mode specified, and with configuration mode of Debug and Release specified.
Unfortunately, the normal tactic of googling/stack overflow hasn't helped, I've seen this error in a few questions, but the cause never seems related to what I'm experiencing.
The last build of the pipeline is available to view here, all the builds thus far have failed, previous builds can be seen here.
Thanks in advance, I would be very grateful if someone had any idea about the cause of this issue, or how I could tackle the test running in a different way.
Solved it.
Updated the script section of the travis config to:
script:
- xbuild /p:Configuration=Debug ./FindWordsWithConcatenations.sln
- mono ./testrunner/NUnit.ConsoleRunner.3.5.0/tools/nunit3-console.exe ./TestFindWordsWithConcatenations/bin/Debug/TestFindWordsWithConcatenations.dll
So it's now running the correct console application. Also had to modify the test paths a bit for it to run on the server.
I've been working on a C# application and wanted to try the GitLab CI out. All I can see is Ruby and can't find any information on how to build a C# application using it.
When I run the test settings, I make the commit, but I don't have my build.
How should I make a simple build? Which command could I use for that? I don't mind if I get a failed build (but a build).
I just wanted to share my .gitlab-ci.yml complete with unit testing. You will have to adjust your nuget and possibly other paths. This is for a single project in a solution of the same name.
variables:
PROJECT_NAME: "ProjectNameGoesHere"
before_script:
- echo "starting build for %PROJECT_NAME%"
- echo "Restoring NuGet Packages..."
- d:\tools\nuget restore "%PROJECT_NAME%.sln"
stages:
- build
- test
build:
stage: build
script:
- echo "Release build..."
- '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "%PROJECT_NAME%.sln"'
artifacts:
untracked: true
test:
stage: test
script:
- echo "starting tests"
- cd %PROJECT_NAME%Tests/bin/Release
- '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe" /testcontainer:%PROJECT_NAME%Tests.dll'
dependencies:
- build
In order to build a C# application you should have a Windows runner (with shell executor) configured for a project in GitLab CI.
Your .gitlab-ci.yml file should look something like that:
stages:
- build
job:
stage: build
script:
- echo "Restoring NuGet Packages..."
- '"c:\nuget\nuget.exe" restore "MySolution.sln"'
- ''
- echo "Release build..."
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "MySolution.sln"
tags:
except:
- tags
On a Windows machine you need the following tools:
Runner installed
Git, added to PATH
Latest nuget.exe at C:\nuget (or somewhere else. Just make sure you got the path right in the .gitlab-ci.yml file)
The other answers are good. But I'd like to explain how to install a runner in addition. I use my own local system (Windows), so I chose to run shell. But you could use a Docker image if you'd like.
cd C:\Multi-Runner
gitlab-ci-multi-runner register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Please enter the gitlab-ci token for this runner
xxx
Please enter the gitlab-ci description for this runner
my-runner
INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh?
shell
INFO[0037] Runner registered successfully. Feel free to start it, but if it's
running already the config should be automatically reloaded!
Source: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/windows.md
Afterwards, you can use a YAML file a like this:
stages:
- build
job:
stage: build
script: '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" "something.sln"'
Installing the build runner on a Windows machine helps a lot, and #prasanth-louis has a great example on how to do that.
As for the .gitlab-ci.yml file, you can simplify it even more by using Cake Build:
stages:
- build
build:
stage: build
script:
- .\build.ps1 -Target Build
tags:
- windows
And your build.cake file can look like this (based of the example repository):
#tool nuget:?package=NUnit.ConsoleRunner&version=3.4.0
var target = Argument("target", "Default");
var configuration = Argument("configuration", "Release");
var solution = "./example-project.sln";
var buildDir = Directory("./example-project/bin");
Task("Default")
.IsDependentOn("Unit-Tests")
.Does(() =>
{
Information("Running Default task!");
});
Task("Clean")
.Does(() =>
{
CleanDirectory(buildDir);
});
Task("PackageRestore")
.IsDependentOn("Clean")
.Does(() =>
{
Information("Restoring NuGet packages for {0}", solution);
NuGetRestore(solution);
});
Task("Build")
.IsDependentOn("PackageRestore")
.Does(() =>
{
Information("Restoring NuGet packages for {0}", solution);
MSBuild(solution, settings => settings.SetConfiguration(configuration));
});
Task("Unit-Tests")
.IsDependentOn("Build")
.Does(() =>
{
NUnit3("./example-project.Tests/**/bin/" + configuration + "/*.Tests.dll");
});
Task("Publish")
.Does(() =>
{
});
RunTarget(target);
Here my working .gitlab-ci.yml file for c# application with NUnit as unit test framework and mono as basic image.
Not very fancy but working:
image: mono:latest
stages:
- build
- test
variables:
solution: "Project.sln"
test: "Project.Test"
before_script:
- nuget restore
build:
stage: build
script:
- msbuild /p:Configuration=Release $solution
test:
stage: test
script:
- msbuild /p:Configuration=Release $solution
- mono ./packages/NUnit.ConsoleRunner.3.10.0/tools/nunit3-console.exe ./$test/bin/Release/$test.dll
The other answers, while informative, miss a few crucial bits of info:
If you are targetting .net core 3.1, .net 5, .net 6 or any newer version then you can build and run your app on linux
If you are targetting .net framework (4.8 or below) then you have to build and run your code on a windows machine.
Now Gitlab runs build jobs using runners (aka build agents), that in turn use executors to specifiy the environment in which the build process happens. Runners can run on the Gitlab infrastructure (Saas runners), or can be installed on premise. There are several types of executors: docker, shell, custom, ...
Most of the gitlab build scripts that can be found around the internet assume a saas runner with a docker executor running on linux, which is based on a specific docker image. This won't work if you want to build your app on windows. For this, either install your own executor, as several other answers instruct to do, or use a windows saas runner which, although in beta, works fine even for production (we have been doing this for months without trouble). While installing your own runner can be useful, e.g. for debugging purposes, I find this defeats the whole purpose of building your software on a hosted cicd platform (github actions, gitlab ci, ...). For debugging, I prefer to base my build script on shell commands which can be run on your local dev box, which minimizes trial and error and makes installing your own runner superfluous.
To get started with a windows runner, see this exemple script. One or two gotchas that I went through:
You cannot choose the VM image of the build machine, it is managed by Gitlab and its content is not documented. This leaves you vulnerable to breaking changes if they decide to change their image.
Strangely, at the time of writing, the .net framework 4.8 developer pack is not installed on the windows executor image, but luckily chocolatey is, so if you target net48 you must install it in your before_script section.
The provisionning of the build machine is somewhat slower than a linux maching running docker, our builds average 15mn which we find acceptable.
That being said, here is a trimmed example based on our build scripts:
variables:
MSBUILD_EXE: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin\msbuild.exe'
UPDATE_VERSION: '.\path\to\Update-Version.ps1'
APP_FOLDER: '.\path\to\Artifacts\_PublishedWebsites\MyApp\'
.windows_build_base:
tags:
- shared-windows
- windows
- windows-1809
before_script:
- Set-Variable -Name "time" -Value (date -Format "%H:%m")
- echo ${time}
- echo "started by ${GITLAB_USER_NAME}"
- echo ".NET versions already installed"
- Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*", "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
| Where {$_.DisplayName -like '*.NET*' -and $_.DisplayVersion -like '4.*'}
| Select-Object DisplayName, DisplayVersion
- echo "Installing .NET 4.8 Developer Pack"
- choco install netfx-4.8-devpack -y
stages:
- build
- publish
build:
only:
- prod
- test
extends:
- .windows_build_base
stage: build
script:
- nuget restore
- '& "${UPDATE_VERSION}" -srcDir . | Set-Variable -Name VERSION' # capture output of UPDATE_PRODUCTINFO script in variable VERSION
- echo "VERSION=${VERSION}"
- Add-Content -Path app_version.env -Value "VERSION=${VERSION}" # store value of VERSION in dotenv file to be passed to dependent stages, as per this workaround https://gitlab.com/gitlab-org/gitlab/-/issues/212629#note_430278657
- Get-Content app_version.env
- '& "${MSBUILD_EXE}" /t:solution_path\to\MyApp /p:Configuration=Release /clp:Summary /verbosity:Minimal /p:OutDir=.\Artifacts'
artifacts:
expire_in: 1 day
paths:
- '${APP_FOLDER}'
reports:
dotenv: app_version.env
publish:
only:
- prod
- test
image:
name: octopusdeploy/octo
entrypoint: [""]
stage: publish
dependencies:
- build
script:
- echo "VERSION=$VERSION"
- octo pack --id="MyApp" --format="zip" --version="$VERSION" --basePath="path/to/Artifacts/_PublishedWebsites/MyApp" --outFolder="/output/"
- octo push --overwrite-mode="OverwriteExisting" --server="https://mycompany.octopus.app" --space "MyOctoSpace" --package="/output/MyApp.$VERSION.zip"
This script:
Installs .net 4.8 dev pack
Restores nuget packages
Manually updates the software version and passes it between the build and publish stages
Builds the app
Packs and pushes it to octopus deploy
I've been working on a C# application and wanted to try the GitLab CI out. All I can see is Ruby and can't find any information on how to build a C# application using it.
When I run the test settings, I make the commit, but I don't have my build.
How should I make a simple build? Which command could I use for that? I don't mind if I get a failed build (but a build).
I just wanted to share my .gitlab-ci.yml complete with unit testing. You will have to adjust your nuget and possibly other paths. This is for a single project in a solution of the same name.
variables:
PROJECT_NAME: "ProjectNameGoesHere"
before_script:
- echo "starting build for %PROJECT_NAME%"
- echo "Restoring NuGet Packages..."
- d:\tools\nuget restore "%PROJECT_NAME%.sln"
stages:
- build
- test
build:
stage: build
script:
- echo "Release build..."
- '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "%PROJECT_NAME%.sln"'
artifacts:
untracked: true
test:
stage: test
script:
- echo "starting tests"
- cd %PROJECT_NAME%Tests/bin/Release
- '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe" /testcontainer:%PROJECT_NAME%Tests.dll'
dependencies:
- build
In order to build a C# application you should have a Windows runner (with shell executor) configured for a project in GitLab CI.
Your .gitlab-ci.yml file should look something like that:
stages:
- build
job:
stage: build
script:
- echo "Restoring NuGet Packages..."
- '"c:\nuget\nuget.exe" restore "MySolution.sln"'
- ''
- echo "Release build..."
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "MySolution.sln"
tags:
except:
- tags
On a Windows machine you need the following tools:
Runner installed
Git, added to PATH
Latest nuget.exe at C:\nuget (or somewhere else. Just make sure you got the path right in the .gitlab-ci.yml file)
The other answers are good. But I'd like to explain how to install a runner in addition. I use my own local system (Windows), so I chose to run shell. But you could use a Docker image if you'd like.
cd C:\Multi-Runner
gitlab-ci-multi-runner register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Please enter the gitlab-ci token for this runner
xxx
Please enter the gitlab-ci description for this runner
my-runner
INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh?
shell
INFO[0037] Runner registered successfully. Feel free to start it, but if it's
running already the config should be automatically reloaded!
Source: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/windows.md
Afterwards, you can use a YAML file a like this:
stages:
- build
job:
stage: build
script: '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" "something.sln"'
Installing the build runner on a Windows machine helps a lot, and #prasanth-louis has a great example on how to do that.
As for the .gitlab-ci.yml file, you can simplify it even more by using Cake Build:
stages:
- build
build:
stage: build
script:
- .\build.ps1 -Target Build
tags:
- windows
And your build.cake file can look like this (based of the example repository):
#tool nuget:?package=NUnit.ConsoleRunner&version=3.4.0
var target = Argument("target", "Default");
var configuration = Argument("configuration", "Release");
var solution = "./example-project.sln";
var buildDir = Directory("./example-project/bin");
Task("Default")
.IsDependentOn("Unit-Tests")
.Does(() =>
{
Information("Running Default task!");
});
Task("Clean")
.Does(() =>
{
CleanDirectory(buildDir);
});
Task("PackageRestore")
.IsDependentOn("Clean")
.Does(() =>
{
Information("Restoring NuGet packages for {0}", solution);
NuGetRestore(solution);
});
Task("Build")
.IsDependentOn("PackageRestore")
.Does(() =>
{
Information("Restoring NuGet packages for {0}", solution);
MSBuild(solution, settings => settings.SetConfiguration(configuration));
});
Task("Unit-Tests")
.IsDependentOn("Build")
.Does(() =>
{
NUnit3("./example-project.Tests/**/bin/" + configuration + "/*.Tests.dll");
});
Task("Publish")
.Does(() =>
{
});
RunTarget(target);
Here my working .gitlab-ci.yml file for c# application with NUnit as unit test framework and mono as basic image.
Not very fancy but working:
image: mono:latest
stages:
- build
- test
variables:
solution: "Project.sln"
test: "Project.Test"
before_script:
- nuget restore
build:
stage: build
script:
- msbuild /p:Configuration=Release $solution
test:
stage: test
script:
- msbuild /p:Configuration=Release $solution
- mono ./packages/NUnit.ConsoleRunner.3.10.0/tools/nunit3-console.exe ./$test/bin/Release/$test.dll
The other answers, while informative, miss a few crucial bits of info:
If you are targetting .net core 3.1, .net 5, .net 6 or any newer version then you can build and run your app on linux
If you are targetting .net framework (4.8 or below) then you have to build and run your code on a windows machine.
Now Gitlab runs build jobs using runners (aka build agents), that in turn use executors to specifiy the environment in which the build process happens. Runners can run on the Gitlab infrastructure (Saas runners), or can be installed on premise. There are several types of executors: docker, shell, custom, ...
Most of the gitlab build scripts that can be found around the internet assume a saas runner with a docker executor running on linux, which is based on a specific docker image. This won't work if you want to build your app on windows. For this, either install your own executor, as several other answers instruct to do, or use a windows saas runner which, although in beta, works fine even for production (we have been doing this for months without trouble). While installing your own runner can be useful, e.g. for debugging purposes, I find this defeats the whole purpose of building your software on a hosted cicd platform (github actions, gitlab ci, ...). For debugging, I prefer to base my build script on shell commands which can be run on your local dev box, which minimizes trial and error and makes installing your own runner superfluous.
To get started with a windows runner, see this exemple script. One or two gotchas that I went through:
You cannot choose the VM image of the build machine, it is managed by Gitlab and its content is not documented. This leaves you vulnerable to breaking changes if they decide to change their image.
Strangely, at the time of writing, the .net framework 4.8 developer pack is not installed on the windows executor image, but luckily chocolatey is, so if you target net48 you must install it in your before_script section.
The provisionning of the build machine is somewhat slower than a linux maching running docker, our builds average 15mn which we find acceptable.
That being said, here is a trimmed example based on our build scripts:
variables:
MSBUILD_EXE: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin\msbuild.exe'
UPDATE_VERSION: '.\path\to\Update-Version.ps1'
APP_FOLDER: '.\path\to\Artifacts\_PublishedWebsites\MyApp\'
.windows_build_base:
tags:
- shared-windows
- windows
- windows-1809
before_script:
- Set-Variable -Name "time" -Value (date -Format "%H:%m")
- echo ${time}
- echo "started by ${GITLAB_USER_NAME}"
- echo ".NET versions already installed"
- Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*", "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
| Where {$_.DisplayName -like '*.NET*' -and $_.DisplayVersion -like '4.*'}
| Select-Object DisplayName, DisplayVersion
- echo "Installing .NET 4.8 Developer Pack"
- choco install netfx-4.8-devpack -y
stages:
- build
- publish
build:
only:
- prod
- test
extends:
- .windows_build_base
stage: build
script:
- nuget restore
- '& "${UPDATE_VERSION}" -srcDir . | Set-Variable -Name VERSION' # capture output of UPDATE_PRODUCTINFO script in variable VERSION
- echo "VERSION=${VERSION}"
- Add-Content -Path app_version.env -Value "VERSION=${VERSION}" # store value of VERSION in dotenv file to be passed to dependent stages, as per this workaround https://gitlab.com/gitlab-org/gitlab/-/issues/212629#note_430278657
- Get-Content app_version.env
- '& "${MSBUILD_EXE}" /t:solution_path\to\MyApp /p:Configuration=Release /clp:Summary /verbosity:Minimal /p:OutDir=.\Artifacts'
artifacts:
expire_in: 1 day
paths:
- '${APP_FOLDER}'
reports:
dotenv: app_version.env
publish:
only:
- prod
- test
image:
name: octopusdeploy/octo
entrypoint: [""]
stage: publish
dependencies:
- build
script:
- echo "VERSION=$VERSION"
- octo pack --id="MyApp" --format="zip" --version="$VERSION" --basePath="path/to/Artifacts/_PublishedWebsites/MyApp" --outFolder="/output/"
- octo push --overwrite-mode="OverwriteExisting" --server="https://mycompany.octopus.app" --space "MyOctoSpace" --package="/output/MyApp.$VERSION.zip"
This script:
Installs .net 4.8 dev pack
Restores nuget packages
Manually updates the software version and passes it between the build and publish stages
Builds the app
Packs and pushes it to octopus deploy
I have installed the preview version of Microsoft's new code editor "Visual Studio Code". It seems quite a nice tool!
The introduction mentions you can program c# with it, but the setup document does not mention how to actually compile c# files.
You can define "mono" as a type in the "launch.json" file, but that does not do anything yet. Pressing F5 results in: "make sure to select a configuration from the launch dropdown"...
Also, intellisense is not working for c#? How do you set the path to any included frameworks?
Launch.json:
"configurations": [
{
// Name of configuration; appears in the launch configuration drop down menu.
"name": "Cars.exe",
// Type of configuration. Possible values: "node", "mono".
"type": "mono",
// Workspace relative or absolute path to the program.
"program": "cars.exe",
},
{
"type": "mono",
}
Since no one else said it, the short-cut to compile (build) a C# app in Visual Studio Code (VSCode) is SHIFT+CTRL+B.
If you want to see the build errors (because they don't pop-up by default), the shortcut is SHIFT+CTRL+M.
(I know this question was asking for more than just the build shortcut. But I wanted to answer the question in the title, which wasn't directly answered by other answers/comments.)
Intellisense does work for C# 6, and it's great.
For running console apps you should set up some additional tools:
ASP.NET 5; in Powershell: &{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}
Node.js including package manager npm.
The rest of required tools including Yeoman yo: npm install -g yo grunt-cli generator-aspnet bower
You should also invoke .NET Version Manager: c:\Users\Username\.dnx\bin\dnvm.cmd upgrade -u
Then you can use yo as wizard for Console Application: yo aspnet Choose name and project type. After that go to created folder cd ./MyNewConsoleApp/ and run dnu restore
To execute your program just type >run in Command Palette (Ctrl+Shift+P), or execute dnx . run in shell from the directory of your project.
SHIFT+CTRL+B should work
However sometimes an issue can happen in a locked down non-adminstrator evironment:
If you open an existing C# application from the folder you should have a .sln (solution file) etc..
Commonly you can get these message in VS Code
Downloading package 'OmniSharp (.NET 4.6 / x64)' (19343 KB) .................... Done!
Downloading package '.NET Core Debugger (Windows / x64)' (39827 KB) .................... Done!
Installing package 'OmniSharp (.NET 4.6 / x64)'
Installing package '.NET Core Debugger (Windows / x64)'
Finished
Failed to spawn 'dotnet --info' //this is a possible issue
To which then you will be asked to install .NET CLI tools
If impossible to get SDK installed with no admin privilege - then use other solution.
Install the extension "Code Runner". Check if you can compile your program with csc (ex.: csc hello.cs). The command csc is shipped with Mono. Then add this to your VS Code user settings:
"code-runner.executorMap": {
"csharp": "echo '# calling mono\n' && cd $dir && csc /nologo $fileName && mono $dir$fileNameWithoutExt.exe",
// "csharp": "echo '# calling dotnet run\n' && dotnet run"
}
Open your C# file and use the execution key of Code Runner.
Edit: also added dotnet run, so you can choose how you want to execute your program: with Mono, or with dotnet. If you choose dotnet, then first create the project (dotnet new console, dotnet restore).
To Run a C# Project in VS Code Terminal
Install CodeRunner Extension in your VS Code (Extension ID: formulahendry.code-runner)
Go to Settings and open settings.json
Type in code-runner.executorMap
Find "csharp": "scriptcs"
Replace it with this "csharp": "cd $dir && dotnet run $fileName"
Your project should Run in VS Code Terminal once you press the run button or ALT + Shift + N