Hi,

please add /p:UseSharedCompilation=false to the command line of the dotnet build step.
We are working on changes that means that you don't have to do this yourself, but unfortunately we're not there yet.

Thanks @criemen :-) for Good work you guys are doing.
will wait for the fix and meanwhile will try what you suggested. :-)

Hi @criemen,
I have tried adding /p:UseSharedCompilation=false to the command line of the dotnet build step.
Actually I have CSharp .NET 3.1 tried following documentation in order to publish codeql scan reports in azure devops platform but ended with
Error: No code found during the build. Please see:
https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-code-scanning#no-code-found-during-the-build
Any suggestions on this!

same here, I tried CodeQL CLI on Azure pipelines and the project is built with VS 2022 and the error is "No code found during the build". I do have /p:UseSharedCompilation=false in my build commands. Any suggestions?

same here, I tried CodeQL CLI on Azure pipelines and the project is built with VS 2022 and the error is "No code found during the build". I do have /p:UseSharedCompilation=false in my build commands. Any suggestions?

For Azure Pipelines, could you please try following the example at https://codeql.github.com/docs/codeql-cli/creating-codeql-databases/#example-of-creating-a-codeql-database-using-indirect-build-tracing and let us know if that doesn't work? Azure Pipelines has its own method of setting environment variables for future build steps, which is required to ensure that the CodeQL build instrumentation persists in the environment.

Thanks for replying soon. I am adding CodeQl ( Semmle) ( CSharp) tool to the Azure pipeline tasks which covers all the steps mentioned in your example but it uses CodeQL database trace-command and not indirect build tracing. Is there any tool that I can add to the pipeline tasks that does indirect tracing?
Update: Sorry I wrote the error that I am getting wrongly in my first comment. the error is "No source code was seen and extracted"

Please try using indirect build tracing first; direct use of codeql database trace-command is not likely to work well with the environment variable handling between different steps in Azure Pipelines. If you're still running into trouble, please share your complete Azure Pipelines YAML workflow file with us and we can advise you.

Hi,

please add /p:UseSharedCompilation=false to the command line of the dotnet build step. We are working on changes that means that you don't have to do this yourself, but unfortunately we're not there yet.

@criemen was something already done by codeql to auto-inject -p:UseSharedCompilation=false -p:EmitCompilerGeneratedFiles=true flags on any call to dotnet?

This is probably a new issue, but I noticed that initializing the CodeQL call before our build steps disrupted our dotnet tool run to slngen as these parameters were getting injected and quoted parameters were getting stripped to other arguments we were passing on the commandline. This caused this step to fail which led to a lot of confusion as we never had an issue in our other environment. As soon as I moved the codeql initialization after that step, it worked fine again. (Though it's still not building in that pipeline, need to pull down the log and investigate more, but it's unclear from the other issues if .NET 6/7 is supported yet or not either.)

@michael-hawker Yes, CodeQL automatically injects those flags into specific dotnet build commands. Apologies for the trouble: we have recently fixed (for example github/codeql#13794) some issues where we were injecting into some dotnet commands (such as dotnet tool) where those flags were not necessary or valid; this fix is in CodeQL 2.14.3, available this week.

I am aware of one more issue we are investigating about quoted parameters containing spaces -- if you can share more about that specific problem you are seeing (including the exact command line for your dotnet tool command), that will help us verify whether it is indeed the same problem or something different to investigate.

@adityasharad thank's for the info! This is effectively what we're seeing below (it's a bit complicated as we construct our call to the tool from a PowerShell script which is where I was looking for the problem initially).

Here's the effective command running with CodeQL:

> dotnet -d tool run slngen -o CommunityToolkit.AllComponents.sln --folders true --collapsefolders true --ignoreMainProject -bl:slngen.binlog --consolelogger:"ShowEventId;Summary;Verbosity=Detailed" --platform "Any CPU;x64;x86;ARM64" .\tooling\CommunityToolkit*\*.*proj .\tooling\ProjectHeads\AllComponents\**\*.Uwp.csproj .\tooling\ProjectHeads\AllComponents\**\*.WinAppSdk.csproj .\tooling\ProjectHeads\AllComponents\**\*.Wasm.csproj .\components\**\src\*.csproj .\components\**\samples\*.Samples.csproj .\components\**\tests\*.Tests\*.shproj
Telemetry is: Enabled
Running c:\program files\dotnet\dotnet.exe C:\Users\runneradmin\.nuget\packages\microsoft.visualstudio.slngen.tool\9.5.4\tools/net5.0/any/slngen.dll -o CommunityToolkit.AllComponents.sln --folders true --collapsefolders true --ignoreMainProject -bl:slngen.binlog --consolelogger:ShowEventId;Summary;Verbosity=Detailed -p:UseSharedCompilation=false -p:EmitCompilerGeneratedFiles=true --platform Any CPU;x64;x86;ARM64 .\tooling\CommunityToolkit*\*.*proj .\tooling\ProjectHeads\AllComponents\**\*.Uwp.csproj .\tooling\ProjectHeads\AllComponents\**\*.WinAppSdk.csproj .\tooling\ProjectHeads\AllComponents\**\*.Wasm.csproj .\components\**\src\*.csproj .\components\**\samples\*.Samples.csproj .\components\**\tests\*.Tests\*.shproj
Process ID: 5856
SlnGen version 9.5.4+201237fc89 for .NET Framework

And without:

> dotnet -d tool run slngen -o CommunityToolkit.AllComponents.sln --folders true --collapsefolders true --ignoreMainProject -bl:slngen.binlog --consolelogger:"ShowEventId;Summary;Verbosity=Detailed" --platform "Any CPU;x64;x86;ARM64" .\tooling\CommunityToolkit*\*.*proj .\tooling\ProjectHeads\AllComponents\**\*.WinAppSdk.csproj .\tooling\ProjectHeads\AllComponents\**\*.Wasm.csproj .\components\**\src\*.csproj .\components\**\samples\*.Samples.csproj .\components\**\tests\*.Tests\*.shproj
Telemetry is: Enabled
Running C:\Program Files\dotnet\dotnet.exe C:\Users\runneradmin\.nuget\packages\microsoft.visualstudio.slngen.tool\9.5.4\tools/net5.0/any/slngen.dll -o CommunityToolkit.AllComponents.sln --folders true --collapsefolders true --ignoreMainProject -bl:slngen.binlog --consolelogger:ShowEventId;Summary;Verbosity=Detailed --platform "Any CPU;x64;x86;ARM64" .\tooling\CommunityToolkit*\*.*proj .\tooling\ProjectHeads\AllComponents\**\*.WinAppSdk.csproj .\tooling\ProjectHeads\AllComponents\**\*.Wasm.csproj .\components\**\src\*.csproj .\components\**\samples\*.Samples.csproj .\components\**\tests\*.Tests\*.shproj
Process ID: 6580
SlnGen version 9.5.4+201237fc89 for .NET Framework

And the relevant bits to compare:

CodeQL: --consolelogger:ShowEventId;Summary;Verbosity=Detailed -p:UseSharedCompilation=false -p:EmitCompilerGeneratedFiles=true --platform Any CPU;x64;x86;ARM64
Without: --consolelogger:ShowEventId;Summary;Verbosity=Detailed --platform "Any CPU;x64;x86;ARM64" 

We were seeing the quotes around our platform parameter being stripped out and thus causing our tool to fail due to the space for Any CPU