I have an MSTest project that works fine when being executed with:
dotnet test --logger "trx;LogFileName=Result.trx" --settings tests.runsettings
I am also able to build a self-contained app out of it with:
dotnet publish -c Release -f netcoreapp2.1 --force --self-contained --runtime win-x64
But I have no idea how to run the tests from the produced output.
Calling
dotnet test .\ProjectName.dll --logger "trx;LogFileName=Result.trx" --settings tests.runsettings
fails with the message:
error MSB4025: The project file could not be loaded.
Any hints as how to run this self-contaiend MSTest-Project?
dotnet test now (2022) accepts .dll files to perform test execution.
You are using the wrong tool:
➜ ~ dotnet --help
test Runs unit tests using the test runner specified in the project.
vstest Runs Microsoft Test Execution Command Line Tool.
dotnet test is the tool used to run unit tests defined in a given project. If you are trying to run tests out of a published dll, dotnet vstest is the command you should us. You do that like this:
dotnet publish -o outputdir
dotnet vstest outputdir/your.dll
Related
I have two NET5 xUnit tests projects. On the build server I am generating code coverage report using coverlet. These reports are wired-up to SonarQube scanner based on the guidance here
Here are the steps
begin step
dotnet "C:\SonarQubeScanners\sonar-scanner-msbuild-5.1.0.28487-net5.0\SonarScanner.MSBuild.dll" begin /k:"IM" /d:sonar.host.url="http://myhost.com" /d:sonar.login="xxxxxxx" /d:sonar.cs.opencover.reportsPaths="%WORKSPACE%\Tests\MyProject1.UnitTests\TestResults\**\coverage.cobertura.xml,%WORKSPACE%\Tests\MyProject2.UnitTests\TestResults\**\coverage.cobertura.xml"
build solution
dotnet build "%WORKSPACE%\My.sln" -nr:false
run unit tests for two projects and collect data
dotnet test "%WORKSPACE%\Tests\MyProject1.UnitTests\MyProject1.UnitTests.csproj" --collect:"XPlat Code Coverage"
dotnet test "%WORKSPACE%\Tests\MyProject2.UnitTests\MyProject2.UnitTests.csproj" --collect:"XPlat Code Coverage"
end step
dotnet "C:\SonarQubeScanners\sonar-scanner-msbuild-5.1.0.28487-net5.0\SonarScanner.MSBuild.dll" end /d:sonar.login="xxxxxxx"
Question
Each time the unit test runs it create new folder (with Guid Name) under TestResults
How do I tell SonarScanner to use latest report?
Or how do I clean-up TestResult folder before every run, is there a parameter to dotnet test command?
SonarScanner also throws error wile parsing the generated report
Could not import coverage report 'D:\Jenkins\im\workspace\Tests\MyProject1.UnitTests\TestResults\9c4d50ae-4113-4018-97bb-30d919a9b1e7\coverage.cobertura.xml' because 'Missing root element <CoverageSession> in D:\Jenkins\im\workspace\Tests\MyProject1.UnitTests\TestResults\9c4d50ae-4113-4018-97bb-30d919a9b1e7\coverage.cobertura.xml at line 2'
Here are the steps I did doing to get it working
1>First delete the testresult folder before the scanning begins
rmdir /s /q "%WORKSPACE%\Tests\MyProject1.UnitTests\TestResults"
2>Modified --collect parameters as below to generate coverage report in opencover format
dotnet "C:\sonar-scanner-msbuild-5.5.3.43281-net5.0\SonarScanner.MSBuild.dll" begin /k:"IM" /d:sonar.host.url="myhost.com" /d:sonar.login="xxxxxxx" /d:sonar.cs.opencover.reportsPaths="%WORKSPACE%\Tests\**\TestResults\*\coverage.opencover.xml"
dotnet build "%WORKSPACE%\IM.sln" -nr:false
dotnet test --no-build "%WORKSPACE%\Tests\MyProject1.UnitTests\MyProject.UnitTests.csproj" --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=opencover
dotnet "C:\sonar-scanner-msbuild-5.5.3.43281-net5.0\SonarScanner.MSBuild.dll" end /d:sonar.login="xxxxxxx"
I am trying to publish my dotnet project-api from jenkins via powershell. The problem is when I publish it from powershell it's missing around 30 files and I can't reach api. However when I publish it from visual studio manually (or from visual studio package manager console with commands) it works perfectly. What might be causing this issue?
Here are the commands that I am running to publish api ;
dotnet restore
dotnet build --configuration release
dotnet publish -c release --output "path to the publish file"
I have also tried with this to publish command yet it didn'T work;
dotnet publish dotnet publish -c Release --self-contained -r win10-x64
I have been trying to figure this issue for a long time but I couldn't find a way. I would highly appreciate any help. Thanks!!
You should try following 2 Execute Windows batch command
Command
"C:\Program Files\dotnet\dotnet.exe" restore yourProjectSLN file
[E.g:yourProjectSLN = git/FolderName/ProjectName.sln , it should be same as jenkins configuration]
Command
dotnet publish yourProject_csproj_file_location -c:Release
[E.g:yourProject_csproj_file_location = git\FolderName\ProjectName.csproj]
In Azure Devops for a .Net core application.
I have three steps
dotnet restore
dotnet build
dotnet test
But if I simply run dotnet test that forces a restore and build. Is there any reason to have the first two steps?
You can use them as follows:
dotnet restore
dotnet build --no-restore
dotnet test --no-build
In this way, you will speed up your build as it can use result of the previous command.
This is default behavior so you don't need to always run all commands to run dotent test for instance. It is convinient and still possible to opt-out from thah behavior.
I've been working on our build pipeline for AWS Lambdas and wanted to add the ReadyToRun feature to reduce startup times. I noticed that in order to complete the publishing step, I needed to remove the --no-build flag. This rebuild step seems to run fairly quickly, so it's not a problem, but I'm curious as to why exactly it's needed.
This doesn't seem to be documented anywhere, and without it the runtimeconfig.json isn't compatible with a framework-dependent deployment. So basically --no-build is not compatible with --no-self-contained.
For context, we build in a custom Alipne-based container with the latest .net core 3.1 SDK and some other internal tools. The restore/build step runs first so we can then run all the tests and finally zip up the distributable package which is picked up by the rest of the CI pipeline. Everything after that first step carries the --no-build flag, except now for the dotnet publish step.
The commands boil down to basically this:
dotnet build --configuration Release --runtime linux-x64 # also takes care of the restore step
dotnet test --no-build # with some filters and coverage targets
dotnet publish --configuration Release --runtime linux-x64 --no-self-contained --framework "netcoreapp3.1" /p:ReadyToRun=true /p:GenerateRuntimeConfigurationFiles=true
I am struggling to understand the differences between dotnet run and dotnet build commands, in regards to constants defined in the .csproj file
example.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)'=='Test'">
<DefineConstants>$(DefineConstants);INCLUDE_TESTS</DefineConstants>
</PropertyGroup>
</Project>
program.cs
using System;
namespace define_example
{
class Program
{
static void Main(string[] args)
{
#if INCLUDE_TESTS
Console.WriteLine("It worked!");
#endif
Console.WriteLine("Hello World!");
}
}
}
If I run dotnet run -c Test, -> It worked! Hello World!
If I run dotnet build -c Test, then dotnet run {buildpath} -> Hello World!
Why does the defined constant go missing when I run the build command?
dotnet build and dotnet run are both commands that act in relation to a csproj file, not a dll or executable.
dotnet build will call the dotnet restore command and then build the project.
dotnet run will call the dotnet build command (this is important to note with respect to your issue) and then run the resulting dll or exe.
What you're currently telling dotnet to do by calling dotnet build -c Test and dotnet run is:
clean, restore, build (using the "Test" configuration)
clean, restore, build, run (with no configuration specified)
The second clean will cleanup the files produced by the first build and then you will build again as part of the run command, but without the Test configuration specified, causing the observed behaviour.
You could change dotnet run to dotnet run --no-build to tell it to assume a build has already been completed and to just assume that the files that would have been created are present and correct.
Alternatively, given that your project has an OutputType of Exe, you could just invoke the executable that is produced by the build command in the regular way as the second step. i.e. using the command example.exe.
If your OutputType was unspecified, or the default (Library) then this would produce a dll rather than an exe, and you could run it using the dotnet command: dotnet example.dll.
Useful reading on the various commands and also common properties:
dotnet command
dotnet build command
dotnet run command
Common MSBuild project properties