Hello @wfincher
thanks for this report.
Many .Net experts have taken some days off this week, so I’ll try to help with an initial answer.
Two things I’ve spotted from your inputs:
you are using a rather old (and non supported) VS 2019 16.0 version. In particular it does not benefit from this fix. Can you bring your build and analysis to an up-to-date version (e.g. 16.9) and let us know of the outcome?
A rather strange absolute path is listed in your logs: D:\a\1\s\src\https://dnndev.me:44305 Even if this item is not marked for build, there may be something wrong with the .sln file there.
I have other repos/builds that are completing without issue using the same build version and similar project setup. However, I tried updating my pipeline to use the following and I still receive the same error:
Could you please provide as the verbose level logs? To acquire the verbose level logs you can do the following things:
please give us the verbose output of the scanner commands (please run SonarScanner.MSBuild.exe begin /k:“MyProject” /d:sonar.verbose=true as the begin step, and please attach the output of the BEGIN and END steps)
please give the output of running MSBuild in verbose mode (/v:d)
I have attached the full logs as downloaded from Azure DevOps with system.debug and “Enable System Diagnostics” equal to “true”. The pertinent files will be:
The analysis is failing because the AbsolutPath project “{DDF717E3-AC63-40DE-B21D-FFACE761894C}” in the solution is “D:\a\1\s\src\https://dnndev.me:44305”, which cannot be resolved as a valid path. We will investigate further how we can prevent the failure in this case.
Could you please give us some more information on that project, so we can understand why does it have such an AbsolutePath? What kind of project is it or how do you reference it?
To provide some context, our site runs on the DNN framework. Our solutions have a local IIS Express website that runs the main CMS website code (“DNN-Website” in the below image, and hosted locally at https://dnndev.me:44305 in a local path within our repo). Our custom code runs as modules (Web Application Projects) under virtual directories in DNN. We have modified our applicationhost.config to point these virtual directories to the code so Visual Studio knows how to execute/debug them.
The reference to the path https://dnndev.me:44305 is a reference via IIS Express. That path is configured to not build.
See below image for a better idea of what I mean. Here is how our modules are exposed to the main CMS via a virtual directory:
This all seems very strange. We have two other projects in SonarCloud that are setup the same way and they do not experience this issue. I am not seeing a difference in the way the solutions are configured that might lead to this. Besides, the error is shown from our Common.csproj - a Net Standard 2.0 class library. This project does not reference the DNN-Website project at all.
I managed to create a reproducer and opened an issue for it, there you can track the progress for it.
You also mentioned that you have two other projects set up the same way and they are not failing, that is most possibly because they don’t have any project targeting .NET Framework or .NET Core 2.0, as the issue is only reproduced if you have that case.
Thank you for continuing to look at this and opening a ticket @Caba_Sagi!
There may be something more to the issue though. Both my other projects that are setup the same way: they target .NET Framework 4.8 and reference the website in IIS Express. They analyze correctly in SonarCloud. Here’s an excerpt from one of those solution files:
I can reproduce the issue with .NET Framework 4.8 too, and in the same time you are right, there is more to this issue than just the IIS Express website reference and another project targeting .NET Core 2.0 or .NET Framework.
The order of projects inside the SolutionConfiguration also plays a role. The referenced website has to be in front of the other project targeting .NET Core 2.0 or .NET Framework in order to fail. We will fix the issue for the upcoming release of the scanner anyway so this does not happen in the future. Meanwhile you can try to remove the website reference from the solution and add it again, in theory that should move the ProjectConfiguration for it from the first place to the last place in the SolutionConfiguration and that way make the build failure disappear.
