I'am trying to create a build pipeline in Azure DevOps which contain a "vs test task". Nothing fancy here. I want to get the code coverage to send it to sonaQube. However, after the pipeline went through the task there is not .Coverage file created.
There is some errors that might be the issue but i'm not sure.
there is a big "Data collection : Could not find data collector 'Code Coverage'", This might be related to the fact that my UnitTestProject.dll is built for Framework 4.6.2 and Platform AnyCPU(for this issue I tried to forced: otherConsoleOptions:/Framework:NETFramework,Version=v4.6.2').
My agent is running on Windows server 2012 and Visual Studio Enterprise everything is up to date:
VS version
[command]"C:\Program Files (x86)\Microsoft VisualStudio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" #C:\Agent_AzureDevOps_1_work_temp\22f8bb11-e53e-11e9-95d5-5bdab8c29281.txt
Microsoft (R) Test Execution Command Line Tool Version 15.9.0
My .trx file is created, however, my .coverage file is nowhere to be seen.
I made sure Code Coverage was Enabled.
My package contain those NuGet
NuGet in my package.config
I'am blocked and don't know where to look anymore if you guys have an idea.
Thanks for the time. If you guys want more information don't hesitate to ask.
I do not have enough reputation to add a comment, so I hope this post will not be deleted (although it is not a direct answer, I think). I wanted to suggest you the following:
Do you have an own *.runsettings file (where you might have specified a specific entry? If you do not specify a *.runsettings file by yourself, the Azure DevOps vstest#2 Task will use a "default" runsettings file. At least this is what I could observe in the log (debug=true)
Hope this helps
BR Michael
I have a similar problem. I run this command :
>dotnet test --logger trx "--collect:Code Coverage"
Determining projects to restore...
All projects are up-to-date for restore.
MyAPI -> ...\MyApi\bin\Debug\net47\MyAPI.exe
MyAPI.Tests -> ...\MyAPI.Tests\bin\Debug\net47\MyAPI.Tests.dll
Warning: Update the Microsoft.NET.Test.Sdk package reference to version 15.8.0 or later to collect code coverage.
Test run for ...\MyAPI.Tests\bin\Debug\net47\MyAPI.Tests.dll (.NETFramework,Version=v4.7)
Microsoft (R) Test Execution Command Line Tool Version 16.10.0
Copyright (c) Microsoft Corporation. All rights reserved.
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Data collection : Unable to find a datacollector with friendly name 'Code Coverage'.
Data collection : Could not find data collector 'Code Coverage'
Results File: ...\MyAPI.Tests\TestResults\***_2021-09-03_12_02_21.trx
Passed! - Failed: 0, Passed: 22, Skipped: 0, Total: 22, Duration: 201 ms - MyAPI.Tests.dll (net47)
The .trx is generated, but not the .coverage.
The solution is to add the NuGet package Microsoft.NET.Test.Sdk in the test project.
Related
I've got .NET 7.2 WEB API project, which was build with x64 Visual Studio 2022 v17.2 - v17.4. Now I try to set up CI/CD pipeline, for what I use .yml with following code:
- 'C:\nuget.exe restore server.csproj'
- '& "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\MSBuild" server.csproj'
Constantly getting error:
error NETSDK1064: Package Microsoft.EntityFrameworkCore.Analyzers, version 7.0.2 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
What I've tried is:
I enabled Win32 long paths as it suggested here
I've created new WeatherForecast project and new repo with name tst, so path certainly cannot be shorter
Nothing gives any success
As far as I understand, the problem is that I use x32 NuGet CLI with x64 VS 2022 builder. Bit depth does not match. As far as my project uses .NET 7, I cannot use VS 2019. Also I cannot find x64 NuGet CLI - official site provides only x32 versions
I need some way to restore packages and then build the project from YML file. What surprised me is that I can sequentially run all commands from .yml in cmd.exe and as a result I will get build with no errors. I tried to $ whoami prior to any of .yml command and it gives me that it's SYSTEM user, which by the way got full access to IIS's wwwroot folder, but the error triggers prior deployment step, so I have no clue how it could be related
I'm stuck, got no idea what to do, but guess that solution is quite simple, I'm to blurry now. SOers please help me
Solution
Great thanks to #mu88!
In accordance to his suggestions yml took that form:
- 'dotnet restore service.csproj -v n'
- 'dotnet service.csproj'
And everything works as it supposed to
After some investigation (see the comment section) we found out that using dotnet build instead of msbuild solves the problem.
Hi guys i have a problem with my code coverage of my azure pipeline. When the CI gets trigged for the master branch the agent has a job to test the .net core. When i use this test i have to configure the route and also enable the code coverage. After the CI has been done it ended succesfully and i can download a file with the code coverage. The problem i have is i cant open this file, not with visual studio or anything else. Aynone that knows how i can fix this problem and maby i didnt configure it right?
Picture of my settings:
picture of the file
picture of the error https://i.stack.imgur.com/fxqdI.png
Seems you are using the wrong configuration. I'm afraid --collect"Code coverage" will not work.
You could add a .NET core test task and add /p:CollectCoverage=true argument then use report generate task for adding code coverage reports.
More detail steps, please refer below tutorials:
ASP.NET Core code coverage reports on Azure DevOps
Azure DevOps, unit testing and code coverage with .Net Core
To generate code coverage please follow this steps
Restore nuget packages
Build the app
Run unit tests (You need to add nuegte package to test projects -> coverlet.collector to use 'XPlat Code Coverage')
Install report generator
Run report generator
Publish code coverage
I set up a new TFS Build Server recently and I'm investigating some extended time periods during the build process. One of those periods is the recompiling of our Selenium test .dll. First, the packages are restored via MSBuild, which is fine. Then, the script hangs for about 10 minutes, while the .dll is actually compiled.
This worked fine on our Visual Studio 2017 Build Server, (took a few seconds to compile I believe) but seems problematic with 2019.
Here's the code. Am I missing an MSBuild parameter or two?
$msbuild = """C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\MSBuild.exe"""
# Rebuild the Test source .dll...
Write-Host "********** Running UI Tests **********"
# Restore Selenium packages...
Write-Host "********** Restoring Selenium Packages **********"
&"C:\Nuget.exe\Nuget.exe" restore $source\Development\12.0\Web\MyAppWeb\MyCo.SeleniumUITest\MyCo.SeleniumUITest.sln -DisableParallelProcessing
Write-Host "********** Selenium Packages Restored **********"
# Changes for new MSBuild....
$projfile = "$source\Development\12.0\Web\MyAppWeb\MyCo.SeleniumUITest\MyCo.SeleniumUITest.sln"
try
{
start-process $msbuild -ArgumentList #($projfile,'/t:Rebuild','/p:configuration=Release') -Wait
Write-Host "********** Selenium .dll compiled successfully! **********"
}
catch
{
Write-Host $_.Exception.Message
exit 1
}
Any Help Appreciated! If this should go in the PowerShell forum, let me know. I thought TFS/MSBuild would be the correct place as I'm hoping its just a parameter or call tweak.
MSBuild Running Slow Called from PowerShell Script (Visual Studio 2019)
State:
(It is difficult to give an accurate answer to this question of operating efficiency. There are many reasons for the problem, most of which are related to the environment, making it difficult for us to reproduce it. So we could not give the direct correct answer for this issue, we can only give you some troubleshootings. In order to avoid losing contact in the round-trip comments, I post those troubleshootings as answer instead of comments.)
First, use the script with Azure devops service instead of the TFS Build Server 2019, to check if this issue still occurred on the Azure devops service, if this issue also occurred on the Azure devops service, that mean this issue should not related to the TFS, more related to the MSBuild/environment/powershell scripts.
Second, use the build in task nuget restore and msbuild task instead of the powershell scripts, to check if you have this issue, if also have this issue, this issue should not related to the scripts. If not, this issue should related to the scripts. We need to check if this scripts need to update since we use the different TFS server.
Third, Check the powershell version in the Visual Studio 2017 Build Server and Visual Studio 2019 Build Server, make sure they use the same version.
If you still could not find the reason, you could enable the debug log and share the log about the hangs to us, so that we could get some more info.
Hope this helps.
I moved the MSBuild scripted tasks out to Build Definition tasks to remove the slowness. I did not determine the cause of the hang when MSBuild was called via the PowerShell script.
The later issue of trying to publish via a .proj file was solved when I noticed I was using a Visual Build task instead of the more appropriate MSBuild task.
One thing to note when using the MSBuild step. If pointing to a .proj file and compiling for Any CPU, set it in the Task as AnyCPU with no space in between.
I need to publish my test coverage results into SonarCloud. My current pipeline is this
Update: - In run code analysis step this log can be found. But in SonarCloud coverage result is not displayed.
INFO: Parsing the Visual Studio coverage XML report D:\a\1\.\TestResults\VssAdministrator_fv-az185_2019-11-13_11_15_46\In\fv-az185\VssAdministrator_fv-az185 2019-11-13 11_15_34.coveragexml
INFO: Adding this code coverage report to the cache for later reuse: D:\a\1\.\TestResults\VssAdministrator_fv-az185_2019-11-13_11_15_46\In\fv-az185\VssAdministrator_fv-az185 2019-11-13 11_15_34.coveragexml
INFO: Coverage Report Statistics: 21 files, 20 main files, 20 main files with coverage, 1 test files, 0 project excluded files, 0 other language files.
How to publish azure pipeline test result to SonarCloud
According to the document:
From Team Foundation Server 2015 or Visual Studio Team Services
Optional: To import code coverage into SonarQube, add the Visual Studio Test build task after the build one and tick Code Coverage
Enabled
So, make sure you have checked Code coverage enabled in the VsTest task.
Besides, if you already checked that option, you can check if the version of your SonarQube is 6.5, there is an issue on that version:
SonarQube 6.5 – Code Coverage Result is not displayed
And, if you can get the Code Coverage in Azure devops but not in SonarCloud, check if this thread give any helps.
Hope this helps.
https://medium.com/#chameeradulanga87/running-asp-net-nunit-tests-in-azure-devops-build-pipeline-and-publishing-results-to-sonar-cloud-20d14dccf275
Complete Guide to publishing test results
I am trying to deploy Visual Studio 2012 SSDT project to Sql Server using TeamCity 8 and MSBuild Publish task but the deployment fails.
When I look at TeamCity logs and use /v:diag switch in my build configuration I see that for unknown reason MSBuild searches for MyProject.sqlproj.publish.sql and for MyProject.sqlproj.dacpac files.
The exact error:
[SqlPublishTask] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(1233, 5): File "C:\Program Files\TeamCity\buildAgent\work\abf8bc05a2cfe7f\*MyProject*\bin\Debug\*MyProject*.sqlproj.dacpac" does not exist.
The correct .sql and .dacpac files get generated (without the .sqlproj in the middel) in buildAgent/work/identificator/*MySolution*/MyProject/bin/Debug folder.
My TeamCity build step is configured as follows:
Runner type: MSbuild
Build file path: MyProject/*MyProject*.sqlproj
MSBuild version: 4.5
MsBuild ToolsVersion: 4.0
Run platform: 4.0
Targets: Publish
Command line parameters: /p:SqlPublishProfilePath="Debug.publish.xml" /p:Configuration=Debug
If I execute this from commandline I get no errors.
Any ideas on how can I configure TeamCity to search for correct files or configure my project to generate the files that TeamCity is searching for.
Or is my plan to use MSBuild's Publish task futile and I should utilise sqlpackage.exe instead?
UPDATE
After spending almost three days trying to figure this out I gave up and used sqlpackage.exe which works like a charm.
But I would still be interested in an answer though, passing paths to executables in build servers seems a bit crude way to accomplish things.
I had a similar issue and came to the conclusion that the way TeamCity produces "pseudo-project" files with *.teamcity suffixes is confusing something in the MSBuild/SSDT target chain.
I simply replaced the MSBuild runner build step with a pure Command Line step and the problem went away.
We lose the user friendliness of the TeamCity MSBuild runner configuration, but if it works, it's a compromise I'm willing to make.
Note - we are running TeamCity 7 - I am not sure if this has been addressed in later versions.
I found out you can set a System Property named "system.SqlTargetName" on the build configuration to override the default value.
Setting this to your project name without the ".sqlproj" makes the error go away.