I had previously configured a Test Inclusion path for src/Web/App_Test and now this is the only folder showing up here, despite there being a .csproj that points at this folder.
Sorry, me again. I’ve done a bit more analysis on our side.
It seems like the version upgrade of the SonarCloud extension from 1.5.1 to 1.6.0 is what broke our process. More specifically we expect that it was the upgrade of the MSBuild scanner from version 4.5.0.1761 to 4.6.0.1930.
We can actually see the new versions being downloaded in the build that broke our process.
VSTS extension was indeed updated from 1.5 to 1.6 version, however this should be transparent if no changes were done to the project or analysis configuration. To debug the problem could you attach DEBUG log of analysis (by passing sonar.verbose=true to Prepare analysis on SonarQube step and tell me which files, that you expect to be analyzed do not show up.
This exact same problem happened to us, it started marking all our files as test files rather than actual files to scan, I think it was thinking our project was a test project.
I had to put <SonarQubeTestProject>false</SonarQubeTestProject>
inside our csproj file for it to start scanning normally again…
@StephenLarkin I’ve had a look at the web.csproj you supplied to @budzow, which was one of the projects that changed from being classified as a product project to a test project.
That service tag is used by the Test Explorer in older versions of VS to identify certain types of test project, according to this StackOverflow answer. Scanner ticket #651 included this change so it recognised projects with that service tag as test projects.
That explains why the analysis of your projects changed between v4.5 and v4.6 of the Scanner for MSBuild, and it seems that treating projects with this tag as test projects is the correct thing to do as it is the approach used by VS (strictly speaking, it was the approach used by VS; newer versions of VS/MSBuild use different mechanisms, so use of the service tag is a legacy behaviour).
However, it doesn’t explain why your product project contains the service tag since it isn’t something that would normally be added manually. The only other options I can think of is that the project once did contain tests that have since been removed, or that VS incorrectly applied the service tag to the project.
Either way, the service tag can be safely removed from the product projects, after which the scanner should correctly identify them as product projects.