Migrated from .NET fw to SDK, zero LOC for some projects

[jvisser (John V)]

We just migrated our code base from .NET framework (using msbuild) to .NET 6 and are now using the dotnet tooling to build and run tests. Since the change, a number of our projects show up with zero LOC in SonarCloud, throwing off our coverage stats.

ALM: Bitbucket Cloud
CI: TeamCity, dotnet 6, NUnit, dotCover

Start cmd:

dotnet SonarScanner.MSBuild.dll begin 
/k:{Name} 
/o:{org} 
/d:sonar.host.url=https://sonarcloud.io 
/d:sonar.token={token}
/n:{name}
/v:2.2.0.9 
/d:sonar.branch.name=develop 
/d:sonar.cs.dotcover.reportsPaths=dotCover.html

Build command: dotnet build {SolutionFile}

DotCover Command:

dotCover.exe cover C:\BuildAgent2\temp\agentTmp\1dotCover.xml 
/ReturnTargetExitCode 
/AnalyzeTargetArguments=false
/Output=C:\BuildAgent\temp\agentTmp\1.dcvr

Test Command (from 1dotCover.xml)
dotnet test {SolutionFile} --no-build

I then convert the dcvr file to a dotCover.html report. Is there a better way to be doing this?

[Colin]

Hey there.

Have you tried making sure you have a full rebuild happening? dotnet build --no-incremental

[jvisser (John V)]

Because it’s part of our CI pipeline, the directory is wiped before every build, so I shouldn’t need to do this. But, I will try it and see if it makes a difference.

[jvisser (John V)]

Okay, --no-incremental didn’t change anything.

However, I did find that a number of large xml files are now part of our solution because of how NET SDK style projects include everything in the folder by default. I went through and excluded *.xml from the projects analysis and now the LOC is much more in line with what Visual studio reports.

Still have some of our largest Assemblies that report zero “Lines of Code” in the code view. Which is very strange, since if I drill down the hierarchy, there is clearly code there.

[Colin]

Thanks.

This can happen if some projects are analyzed as test code instead of product code – you can read more about debugging this here.