I'm using OpenCover to generate test coverage reports for my projects, but it's not generating any data. Checking in my logs, it's showing "missing pdb" for the dlls in question, however the pdbs are available in the same directory.
Things I've tried:
I've tried adding the directories with the pdbs in explicitly using the -searchdirs option - makes no difference.
I've checked and it looks like XUnit doesn't do shadow copying of dlls, so they are being accessed from the right directory. The opencover results.xml backs me up on this.
I'm using a command line of
opencover.console -oldstyle -register:user
-target:"C:\Program Files\Dotnet\dotnet.exe"
-targetargs:"test"
-searchdirs:"C:\dev\public\hermes-c#\Hermes.Server\Hermes.AspNetCore.Test\bin\Debug\netcoreapp1.0"
Any and all thoughts appreciated!
.NET Core uses a "Portable PDB" format by default, which OpenCover does not understand yet.
Try the following build options instead:
"buildOptions": {
"debugType": "full"
},
Note: when using full the generated debug symbols are for Windows only...
Update: with MSBuild based projects this becomes:
<PropertyGroup>
<DebugType>full</DebugType>
</PropertyGroup>
And, we're able to build using the /p:DebugType=Full switch too. Thus, the "ordinary" build can use the default debug setting, but a "special" build for coverage analysis can change that to full.
Related
On a Windows machine there is a GitLab-Runner run from a domain user with admin rights. When I log as this user and call dotnet build -c release to build an ASP.NET Core app, the dll has all the information from the AssemblyInfo.cs file. When I do the same as part of a CI job, the produced dll is missing all this information (for example the version number).
The AssemblyInfo.cs file is not part of the repository, instead, it is produced by a prebuild event (using gitWCRev.exe tool). However after running some tests I can see that the AssemblyInfo.cs is actually generated when the job is run by the runner.
Any help as to why the file is ignored and how to overcome this issue would be appreciated.
At first I thought that this might be related to Pre-build task of Visual Studio project fails in GitLab Runner issue, but I don't get any build errors.
On the same machine, I build a .Net Framework app which has the same AssemblyInfo setup, but is compiled using msbuild /property:Configuration=Release by the runner and the produced dll file has all the expected information.
It turns out the problem was partially related to the AssemblyInfo.cs file not being part of the repository.
SDK-style csproj normally don't list the files in the project, but figure them out based on the folder contents. When dotnet build was run, AssemblyInfo.cs wasn't present in the project directory (GitLab-Runner usually clears out files not present in the repository before starting a job/pipeline), so build tools had no idea they needed to load it. It made no difference that the file was being created by the build tools.
The solution proved to be creating an empty AssemblyInfo.cs file before running dotnet build. This way build tools knew they needed to compile it. Actual compilation still happened after prebuild events, so all the needed information was there.
I created the empty AssemblyInfo.cs file using PowerShell:
New-Item -Path "Properties/AssemblyInfo.cs" -ItemType File
Also, checking the build logs helped me finally figure it out. To get the build logs I've called build tools like this:
dotnet build -c release /flp:v=diag
The .Net Framework app didn't have this problem because it wasn't an SDK-style project. All the files needed for compilation were listed in the project file and build tools knew to load them, even if they were created during the prebuild event.
I have a SonarQube installation and am running it against a .Net core application with multiple xUnit projects. The SonarQube picks up the bugs and smells fine but like so many people, I can't get the code coverage to complete.
At present, I am generating cobertura coverage XML files using the following command:
dotnet test --collect:"XPlat Code Coverage"
I then copy these to a centralized directory from each of the test projects and use the following command to run/import the files:
dotnet SonarScanner begin /k:"my-project" /d:sonar.cs.vscoveragexml.reportsPaths=".\TestResults\*.xml"
dotnet build
dotnet SonarScanner end
According to the logs, the files are found but are not ingested.
INFO: Parsing the Visual Studio coverage XML report
C:...\TestResults\5.coverage.cobertura.xml WARN: Could not import
coverage report '..\TestResults\5.coverage.cobertura.xml' because
'Missing root element in
C:...\TestResults\5.coverage.cobertura.xml at line 2'
I've confirmed that the files contain valid XML that looks to be correct, but I'm not even sure that SonarQube is supposed to accept cobertura reports.
Is my approach the way others have gone when trying to get xUnit coverage reports into SonarQube?
Is there a better way? I'm happy to use OpenCover or similar if that is easier.
In case anyone comes across this in the future, I gave up trying to use the built in coverage in VS and used DotCover. Bit of an easier setup and now seem to have it working to a degree.
Download/extract dotCover and add the folder to Path
dotCover.exe --output=AppCoverageReport.html --reportType=HTML dotnet -- test
dotnet SonarScanner begin /k:"my-project" /d:sonar.cs.dotcover.reportsPaths=AppCoverageReport.html
dotnet build
dotnet SonarScanner end
Still having an issue where the test coverage gathering seems to be pulling in too much and as a result is causing an error. Investigating but not related to this question.
Hi Stackoverflow Community,
I am trying to build my Web and WebAPI, console applications with Target Framework - .NET Core 3.0, as per project 'Application' properties, using:
Microsoft Visual Studio Community 2019
Version 16.5.4 on Windows 10 PRO
I am seeing the following errors:
Error MSB3030 Could not copy the file "C:\Users...\WebApi3\obj\Debug\netcoreapp3.0\webapi3.exe" because it was not found
and
Error MSB3030 Could not copy the file "C:\Users...\Web\obj\Debug\netcoreapp3.0\webportal.exe" because it was not found
Hence these projects are not getting built.
Appreciate your time for reading this.
Please advise.
Here is the part of the code where the error points to:
============================================================
_CopyOutOfDateSourceItemsToOutputDirectory
Copy files that have the CopyToOutputDirectory attribute set to 'PreserveNewest'.
============================================================
-->
<Target
Name="_CopyOutOfDateSourceItemsToOutputDirectory"
Condition=" '#(_SourceItemsToCopyToOutputDirectory)' != '' "
Inputs="#(_SourceItemsToCopyToOutputDirectory)"
Outputs="#(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')">
<!--
Not using SkipUnchangedFiles="true" because the application may want to change
one of these files and not have an incremental build replace it.
-->
<Copy
SourceFiles = "#(_SourceItemsToCopyToOutputDirectory)"
DestinationFiles = "#(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
UseSymboliclinksIfPossible="$(CreateSymbolicLinksForAdditionalFilesIfPossible)"
>
<Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
</Copy>
</Target>
I faced the same issue in VS2022(17.0.1) as well. I performed below steps based on a github issue [https://github.com/dotnet/sdk/issues/3122] discussion and my issue got resolved. I believe this works for VS2019 as well.
Step1: Clean Local Nuget Cache
..\projectDir> dotnet nuget locals all --clear
Step2: remove bin and Obj folders
..\projectDir> rd \s \q bin obj
Step3: Clean the solution using Visual studio build menu
Step4: Rebuild Project
Updating Visual Studio to 16.5.5. seems to have solved the issue so far.
I had a similar issue but whilst attempting to publish. The affected .DLL was a nuget package and I noticed I had an update for it.
Updating the affected package, cleaning the solution, rebuilding then re-publishing resolved my issue.
For CoreXT repos by default only outputs under obj for retail builds or objd for debug builds are collected. You seem to be using the retail bridge and using obj(Debug|Release) and bin (the MSBuild non-CoreXT defaults), so those outputs are not being collected.
To remedy this, you can set the -UsePredictedOutputPath QuickBuild flag which will avoid collecting those hard-coded paths and instead ask each project what its $(IntermediateOutputPath) and $(OutputPath) are and use those.
Note that in either case, outputs under output roots (eg /target) are always collected. This flag only affects the project-relative outputs.
I have a web app in dot net along with other projects. when i open the .sln file and publish the web project, it does. But, when I try to publish the web proj using command line and .csproj, it gives an error. "Nothing to do. None of the projects specified contain packages to restore."
I got this after converting my csproj to vs2019 format and running dotnet test. The solution was to ensure i had the right test adapter and framework. My csproj files had both the old Microsoft.VisualStudio.QualityTools.UnitTestFramework reference and the new MSTest.TestAdapter + MSTest.TestFramework + Microsoft.NET.Test.Sdk.
I kept the new ones and my tests were run.
I had this problem in a batch file I use to build a UWP component for release. The build command is
%MSBUILD% CartoType\src\main\single_library\uwp\CartoType\CartoType.sln -p:Configuration=Release;Platform=x64
where %MSBUILD% is the full path to msbuild. I first added an msbuild command with the -t:restore option and got the message reported by the original poster ('Nothing to do. None of the projects specified contain packages to restore').
The solution was to add this command before the command given above:
%MSBUILD% CartoType\src\main\single_library\uwp\CartoType\CartoType.sln -p:RestorePackagesConfig=true -t:restore
Using dotnet build the project will not by recomplied if there are no changes:
Project {project name} was previously compiled. Skipping compilation.
Is it possible to force project to be recompiled? I have looked into command options, but haven't found any related parameters.
You should either switch the incremental compilation off by specifying the --no-incremental option (by default the incremental compilation is on which means that compiler will compile the code if it detects any changes in methods, etc) or clean up the output directory.