dotnet list package returns error if solution includes a docker-compose project

[JD-Robertson]

NuGet Product(s) Affected

dotnet.exe

Current Behavior

This is likely related to the behavior change described here: #12479

My organization has a pipeline step that lists vulnerable packages for our ASP.NET Core soutions using:

dotnet list <soution>.sln package --vulnerable --include-transitive

After updating our toolchain from dotnet 6 to dotnet 7, this command now returns a non-zero error code for all of our projects even if no vulnerable packages are found. We get an error message:

The project <path>\docker-compose.dcproj uses package.config for NuGet packages, while the command works only with package reference projects.`

Which seems to be the source of the error.

Desired Behavior

Ideally, there would be some way to tell the tool to ignore the docker-compose.csproj file since it is irrelevant to this scan.

Failing that, treating the incompatible file as a warning and not an error would allow us to detect actual issues with the tool.

Additional Context

I tested using dotnet.exe version 7.0.201

It's very easy to reproduce this without any custom code.

1. In Visual Studio 2022, create a new ASP.NET Core Web API project. Include Docker support.
2. A new solution will be created. Right-click on the WebApplication1 project in Solution Explorer and select Add > Container Orchestrator Support. Choose the Docker Compose option. This will create a new docker-compose.csproj file.
3. Open a PowerShell prompt and run dotnet list <soution>.sln package. No need to even check for vulnerabilities.
4. Check $LASTEXITCODE and see that it is 1.

We have been forced to disable this check due to this behavior. I found an old issue: microsoft/MSBuildSdks#131

Which suggests a possible workaround of defining the RestoreProjectStyle setting in the problem project. But the workaround is not valid for the docker-compose project, which does not have NuGet dependencies.

[ThomasHeijtink]

We use it to track --outdated packages. Which I know doesn't require a build (even though that's what their doc is stating).

The workaround for our pipeline is to only perform a nuget restore and not a build. Then we don't experience this issue. Locally this is still an issue but if I want to test our script. I just delete the docker project file and later in git undo the delete. But this is a problem that should be addressed. Ideally it should just notify that the project is excluded from the scan. Instead of a hard failure.

You can also edit your solution file and move the docker project as the last project. That way it only fails at the end. Which in our cases isn't a problem.

When you indicate the --format to be json. Then it is reported as a problem in the json result. But has not further impact on the rest of results.

[ImrePyhvel]

Just to chime in that the issue is more general and applies to other "unexpected" project types. For example, it fails if sln contains *.sqlproj projects. The same dumb workaround helps - remove from solution, run command, git revert. But this is PITA if you want to automate things.

The list package command should ignore things it does not understand.

[nkolev92]

Potentially related: #12817, #11886

Effectively, they all talk about scenarios where the project is not parsable with the .NET SDK.

[enki42]

I wish there was a way to tell dotnet list to ignore projects that it errors from not being able to work with them instead of returning an error. Its a very useful command to get extra troubeshooting info in a build but don't want to break the build cause a solution contains a project that isn't compatible while others are.

[poganytamas]

Any news / solution on this? This issue is 1 year old :(

[rbell517]

My workaround is to generate a solution with only the .csproj projects from the base solution, and then use the generated solution with dotnet list <sln> package --vulnerable. This is pretty simple with other dotnet cli commands in powershell:

dotnet new sln <sln-base-name>.g
$projects = dotnet sln <sln-base-name>.sln list | Where-Objects {$_.EndsWith('csproj')}
dotnet sln <sln-base-name>.g.sln add $projects
dotnet list <sln-base-name>.g.sln package --vulnerable --include-transitive

This is cumbersome when running locally, but its pretty straight forward to run in a CI pipeline.

If your like me and your main concern is vulnerability checks and you have updated to .NET 8, there is also the option to enable vulnerability checking during package restore at the .csproj level. This avoids the problem and is a more flexible feature overall.
https://learn.microsoft.com/en-us/nuget/concepts/auditing-packages#configuring-nuget-audit